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
When a function invocation fails for some reason, Lambda may retry multiple times until the execution is successful. A retry is simply invoking the same function again with the same event payload.
This retry behavior makes it easier for developers to account for transient errors and network issues, for example. When the error persists for too many retry requests, Lambda will give up retrying and may send the failed invocation to a Dead Letter Queue1 (if enabled).
Consider a function that processes checkout sales in an e-commerce website. Depending on how the function code is implemented, if something goes wrong and the request gets retried, it’s possible that the customer’s credit card will be charged more than once.
This issue might happen to hundreds or perhaps thousands of customers before getting fixed. It can easily become a nightmare for the customer support, financial department, and obviously to the development team behind the badly architected application.
Every code implemented in Lambda must follow a principle called Idempotence. Wikipedia defines it as a “property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application“.2.
In other words: when something goes wrong in an e-commerce website, the application makes sure a credit card will never be charged more than once for the same order.
A good practice to combine with idempotency is the separation of concerns3. Apart from being a good practice, it will help in the idempotence implementation. One of the reasons is that idempotency needs to be analyzed from the perspective of the operation. Having each operation properly isolated simplifies the process.
Read operations usually do not produce any side effects and are idempotent by nature. Checking if an item is available in stock, for example. This operation can be repeated multiple times without violating idempotence. Implement this type of operation as a dedicated Lambda function and eliminate them from the idempotence analysis.
Insert and delete aren’t idempotent operations by nature, but they can be with a unique identifier (UID) for the resource. In e-commerce, the order could have a UID. The storing operation can be performed multiple times without creating multiple different order placements. All Lambda retries will have the same order UID.
The order UID could be, for example, a hash of the customer email or username, the purchase timestamp, and a list of items purchased. These variables would be sent as a parameter to the API when the site receives the order request. The UID can be easily re-generated by retry invocations based on the same parameters.
Applications that rely on write-enabled third-party APIs can be tricky to ensure idempotency.
Some services will provide idempotency features by default. This will be the case of a credit card processing platform. Stripe4, for example, provides an idempotency key5 that enables safe retries.
In other cases, it might be necessary to run all operations internally first, validate the success, and then interact with the external API. This wouldn’t be the ideal implementation but could be as good as one can get in some circumstances.
AWS Lambda and CloudWatch Logs will not highlight retry requests, nor link them to the original invocation request by default. Some professional serverless monitoring services – such as Dashbird – will link all invocations and retries automatically, allowing easy navigation across the stack of requests.
No results found