Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
Dashbird continuously monitors and analyses your serverless applications to ensure reliability, cost and performance optimisation and alignment with the Well Architected Framework.
What defines a serverless system, main characteristics and how it operates
What are the types of serverless systems for computing, storage, queue processing, etc.
What are the challenges of serverless infrastructures and how to overcome them?
How systems can be reliable and the importance to cloud applications
What is a scalable system and how to handle increasing loads
Making systems easy to operate, manage and evolve
Learn the three basic concepts to build scalable and maintainable applications on serverless backends
The pros and cons of each architecture and insights to choose the best option for your projects
Battle-tested serverless patterns to make sure your cloud architecture is ready to production use
Strategies to compose functions into flexible, scalable and maintainable systems
Achieving loosely-coupled architectures with the asynchronous messaging pattern
Using message queues to manage task processing asynchronously
Asynchronous message and task processing with Pub/Sub
A software pattern to control workflows and state transitions on complex processes
The strategy and practical considerations about AWS physical infrastructure
How cloud resources are identified across the AWS stack
What makes up a Lambda function?
What is AWS Lambda and how it works
Suitable use cases and advantages of using AWS Lambda
How much AWS Lambda costs, pricing model structure and how to save money on Lambda workloads
Learn the main pros/cons of AWS Lambda, and how to solve the FaaS development challenges
Main aspects of the Lambda architecture that impact application development
Quick guide for Lambda applications in Nodejs, Python, Ruby, Java, Go, C# / .NET
Different ways of invoking a Lambda function and integrating to other services
Building fault-tolerant serverless functions with AWS Lambda
Understand how Lambda scales and deals with concurrency
How to use Provisioned Concurrency to reduce function latency and improve overall performance
What are Lambda Layers and how to use them
What are cold starts, why they happen and what to do about them
Understand the Lambda retry mechanism and how functions should be designed
Managing AWS Lambda versions and aliases
How to best allocate resources and improve Lambda performance
What is DynamoDB, how it works and the main concepts of its data model
How much DynamoDB costs and its different pricing models
Query and Scan operations and how to access data on DynamoDB
Alternative indexing methods for flexible data access patterns
How to organize information and leverage DynamoDB features for advanced ways of accessing data
Different models for throughput capacity allocation and optimization in DynamoDB
Comparing NoSQL databases: DynamoDB and Mongo
Comparing managed database services: DynamoDB vs. Mongo Atlas
How does an API gateway work and what are some of the most common usecases
Learn what are the benefits or drawbacks of using APIGateway
Picking the correct one API Gateway service provider can be difficult
Types of possible errors in an AWS Lambda function and how to handle them
Best practices for what to log in an AWS Lambda function
How to log objects and classes from the Lambda application code
Program a proactive alerting system to stay on top of the serverless stack
Serverless is a cloud architectural model that abstracts away from developers the need to handle server provisioning and maintenance.
It is commonly associated with Functions-as-a-Service (Faas), a form of computing service that was the pioneer of all serverless systems. FaaS executes self-contained code on-demand. It is stateless, not keeping any data persisted after an execution.
Most types of traditional cloud services have a serverless version available nowadays: database, queue buffer, pub/sub, stream processing, etc. It is possible to build an entire application in the cloud relying solely on serverless platforms.
A serverless system abstracts away the need to provision and manage servers or virtual machines.
As mentioned above, a good example is Function-as-a-Service (FaaS), such as AWS Lambda. It allows us to run code written in virtually any programming language without having to provision an EC2 server, for example. Behind the scenes, Lambda will create an ephemeral microcontainer, run our code and return the results. There’s no need to manage the infrastructure. Developers only have to deploy the code and run it.
Some argue that serverless is a misnomer because everything still must run in a server anyway. What is really relevant is that, from the developer perspective, there is no server handling involved. The developer experience is serverless, not the service provider.
Traditionally, a server-based system bills for the availability of a resource over a given period of time (e.g. EC2 servers are charged by the hour).
On the other hand, serverless charges actual usage. The availability of a serverless system is not charged, it is available all time at zero cost1. The user only pays when it actually uses the system.
Following the FaaS example above (AWS Lambda), we only pay when the code gets executed. If we deploy our code and never run it, there’s nothing to be paid, even though the function remains available and will respond to execution requests at any time.
In a comprehensive analysis, prices are low in serverless, especially when accounting for the hidden costs of traditional architectures.
Lambda charges only $0.20 for 1 million executions of a function, or $0.0000002 per request. Depending on how much memory (RAM) the function requires the it will charge extra.
This pricing model is especially advantageous for startups and small/medium applications, since it reduces financial risks by converting fixed costs into variable ones.
Applications with highly variable demand can also benefit from serverless. Sudden and sharp demand peaks usually leads to over-provisioning in a traditional infrastructure. In serverless, there’s no extra cost for idle resources.
Developers have no responsibility for the serverless underlying infra: load balancer, auto-scaling, operational system and patches, server security, etc.
Many common operational puzzles are also inexistent. Should it scale vertically or horizontally? How many servers are needed for high availability? How long does it take to spin up new servers in the cluster? What level of IOPS capacity is needed? All asbtracted away to best-in-cloud DevOps teams.
In a serverless database – such as DynamoDB -, planning for master/read replicas, backup, scaling up/down partitions, managing indexes, etc. is not an issue for the user to take care of.
How many concurrent code executions (or database queries) a server can handle? In traditional infrastructure, the answer requires extensive load testing. In serverless, it’s a transparent contractual SLA.
AWS Lambda, for instance, supports up to 1,000 concurrent executions by default. DynamoDB on-demand tables support 40,000 read and 40,000 write capacity units per second. All serverless systems will have an SLA for their performance thresholds.
Default limits can accomodate a vast majority of use cases, and they can be increased if needed. A large pool of resources is maintained by the cloud and shared among multiple users. This enables efficient usage, allowing for greater capability and lower costs.
It is essential to understand the serverless thresholds. It is common for newcomers to assume they’ll be able to use the service at any concurrency level, for example, which is an unrealistic expectation.
Most serverless platforms can scale up and down to accomodate variable demand transparently to the development team.
If an application experiences a momentaneous peak, suddenly going from one to a thousand concurrent requests, a serverless system should have no problem to cope with. That level of scalability comes with zero additional cost to each execution.
In a traditional server architecture, this would require a very well crafted auto-scaling system and some level of upfront overprovisioning. Instantiating new servers in a cluster takes time, from few seconds to minutes, depending on the case. If the demand grows faster than the scaling process, the application can experience downtime.
Footnotes
No results found