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
In a previous topic we covered the Asynchronous Messaging architectural pattern, its advantages and some high-level examples.
Message Queue is one way of implementating this type of architecture, and now we are going to cover it more in depth.
The Message Queue model has four basic components:
Message Queues are perhaps the easiest way to implement and maintain an asynchronous architecture. Below are some of the advantages for choosing a message queue:
A Message Queue has a “multi-to-one” model: multiple producers and one single consumer of messages1. This architecture simplifies the implementation, management, testing and debuging of asynchronous systems.
Since there is only one place where messages get processed (single-consumer), testing and debuging usually poses less complexity in comparison to other asynchronous messaging models.
The Message Queue model still allows, though, for multiple services to produce messages for a single queue. This flexibility further enhances the possibilities to build a loosely-coupled architecture and also allows for reusability of components.
Consider Service A produces messages for Service B. If either of the services goes offline, the other can continue publishing or consuming messages from the queue.
In case of a queue failure, there could be back-up or dead-letter queues to capture messages not queued during the downtime.
A third service would be responsible for moving messages from the backup/dead-letter ones into the main queue once it’s back online. Both Service A and Service B would remain online during the queue failure.
Modifying, extending or entirely swaping services (both producers or consumer) is much easier in a Message Queue implementation. When services aren’t tied together, changes to one service cannot impact directly the other components of the system.
While a consumer is replaced, for example, producers can continue producing and submitting messages seamlessly. Even if the new consumer version results in issues, messages pulled from the queue would fail to be processed and go back to the queue again. Later, when a fix is deployed to the consumer service, messages can resume being processed normally.
Most – if not all – cloud services will provide a managed or serverless message queue option ready to integrate in any project. Arguably one of the most well-known and widely used is AWS SQS.
These services are usually charged on a per-request-basis, can scale very rapidly to accomodate fluctuating demands and provide easy to consume metrics and insights to manage the queue status.
This is the least-effort path to implement any asynchronous messaging queue pattern in software projects.
There are literally dozens, if not hundreds of open source projects available for speeding up a custom implementation. Some of them are very well known and reported to have been battle tested in production by many companies.
Below is a list, in no particular order preference:
This is mostly recommended for large-enough teams that have access to the right DevOps skills, time and financial resources to handle its own implementation.
For small teams working on a tight schedule and budget, a managed/serverless option in many cases will be a better option to start with.
When implementing a Message Queue system (or using a managed/serverless one), architects and developers will have to make a few decisions with regards to how the queue should work.
Below we present the main properties most commonly open for configuration in Message Queue systems.
Push vs. pull
In a push model, the queue will proactively notify the consumer when there are messages available for processing.
The pull model, on the other hand, depends on the consumer to frequently query the queue in order to check for pending messages.
Some queue systems will allow to schedule a specific date and time for message delivery. The producer is usually responsible for setting the schedule. The message is immediately received by the queue, but is kept away from the consumer until the scheduled time comes.
When publishing a message, the Producer can choose to delay the delivery to the consumer by a certain time span (e.g. 10 minutes or 2 hours).
Urgent and important messages can be flagged for priority delivery by the queue to the consumer, in detriment to other less important messages already queued before.
At least once vs. Exactly once
To reach maximum scalability and reliability, most Message Queue systems will run on a distributed environment across a cluster of servers. Even managed/serverless services will have this characteristic behind the scenes.
The easiest queue implementation is “at least once delivery”. It means that, sometimes, the same message might be delivered to the consumer more than once. If that is not a problem, this implementation can be cheaper and easier to scale.
“Exactly once” delivery is also usually available for contexts where a duplicated message could become a problem for the overall system. It ensures strong consistency in message reception and delivery. In order to do so, it usually sacrifices a bit in terms of scalability and/or costs.
FIFO vs. Unordered
In case the order of messages received and processed do not matter, an “unordered” model will probably be cheaper and more scalable.
There are situations, though, where messages must be consumed and processed in the exact same order they’ve been produced. The FIFO (First In, First Out) model will meet this requirement.
Scaling Microservices with Message Queues to Handle Data Bursts, by Songtham Tung
Event-Driven Architecture – Software Architecture Patterns, by Mark Richards
Microservice Architecture Best Practices: Messaging Queues, by Ranga Karanam
No results found
End-to-end observability and real-time error tracking for AWS applications.