All-in-one serverless DevOps platform.
Full-stack visibility across the entire stack.
Detect and resolve incidents 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
AWS SQS – stands for Simple Queue Service – is a managed service by AWS to handle message queueing.
In a queue, one service sends messages, and other services consume those messages. It can be used for a variety of purposes.
As a managed service, SQS releases developers from the worries of setting up and maintaining a queue system. The service will provide everything needed out of the box and seamlessly scale to accommodate the demand.
This can be a perfect fit for projects running on a tight schedule, as well as for small & medium-sized serverless development teams.
SQS is frequently used to decouple distributed backend services. Instead of having one service directly interacting with another, a queue could intermediate the communication.
Another common usage for queues is to accommodate mismatches in service scalability. When a service relies on another one that can’t scale to the same level or as quickly as the first, bottlenecks can become a problem. In these cases, having a queue between A and B is beneficial, because the queue can absorb peak demand from A, and transmit messages at a slower pace that B can cope with.
We have already covered the broad mechanism of message queues in another article. SQS builds on these concepts and provides an API that developers can use to communicate with the service.
The main actions in high-level are:
SQS does not work as a database and the consumer can’t determine which message to receive from the queue. It can, though, specify how many messages it wants to receive at each time.
After a message is received, SQS will remove it temporarily from the queue. This is to avoid it being consumed twice (although it still might happen on some occasions – see topic below). During a certain time, the message will be hidden and the consumer has the chance to process it and later delete it from the queue.
If the message is not deleted after the visibility timeout period, it will go back to the queue and will be received in future requests. The visibility timeout period can be customized.
There are two different types of queues in SQS: FIFO and Standard.
In the Standard queue, SQS will deliver messages out of order. It means that a message received later can be delivered first to a consumer. It may also deliver the same message more than once on some occasions. This type of queue leverages the advantages of distributed systems with low consistency, which drives down costs. As a result, this is the cheapest option in SQS.
The FIFO type follows a First-in, First-out model. It delivers messages in the exact same order they were received, and each message is delivered only once. Despite being 25% more expensive than Standard queues, FIFO is sometimes necessary for projects that require precision and high consistency properties for its queues.
Another difference between the two types of queues is scalability capabilities. Standard queues support an unlimited amount of transactions per second, which FIFO will handle up to 3,000 messages per second, although this limit can be increased by requesting AWS support.
No results found