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
DynamoDB manages throughtput capacity in basically two types of operations: read and write. It can scale up and down to cope with variable read/write demand, and it does so in two different modes. It is up to the developer to choose which capacity mode fits better with the application needs.
This is the easiest to use and most straight-forward, since it abstracts all capacity thinking to the AWS team behind DynamoDB.
When a table is configured as on-demand, the DynamoDB team will allocate a default read/write capacity. Independent tests show around 4,000 request units (RU)[^1]. There is a simple trick to 10X this value:
It will inherit the capacity provisioned (40,000 RU). Do it only if really needed, though, since DynamoDB will scale back down if capacity is not used.
Beware that it’s possible to switch capacity modes only once every 24 hours[^2].
In this mode, it is up to the developers to determine the maximum request units DynamoDB must be able to support at any given time.
The provisioned values don’t have to be rigid, though. Dynamo does offer an auto-scaling feature that developers can enable to scale provisioned capacity up and down, according to demand. Note that the scaling process might not be sufficient for coping with a sudden spike in application traffic.
The main advantage of Provisioned is that each read/write request is cheaper than in On-demand Mode. On the other hand, On-Demand usually scales in a faster and smoother way than Provisioned.
When the demand is highly variable and exhibits sharp spikes, it might be better to switch On-Demand Mode. When application traffic is somewhat predicatable and varies in a smoother way, Provisioned Mode will be a more cost-effective option.
In case too many read or write requests are issued against a table and its Capacity Units are exhausted, DynamoDB will throw a ProvisionedThroughputExceededException[^3].
ProvisionedThroughputExceededException
Even for very small applications, it is important to model the development considering the possibility of having a request being throttled. Especially write requests must have a way to retry to avoid losing information.
The application may retry the request a couple of times following an exponential backoff[^4]. If still unsuccessful, the write request could be queued for example, in order to be retried at a later time.
[^1] Understanding the scaling behaviour of DynamoDB OnDemand tables
[^2] Considerations When Changing Read/Write Capacity Mode
[^3] DynamoDB Programming Errors
[^4] Error Retries and Exponential Backoff
No results found