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 our Well Architected Framework video series, we deep dive into the five pillars and explain how to best optimize your serverless app accordingly.
Did you know that using the AWS SDK between Lambda invocations can be a bad idea? Or that your architectural design might be doubling your costs on AWS Lambda?
You can learn more about optimizing Lambda for production here.
This is the Serverless Trilemma. My name is Renato and I welcome you to our Serverless Well Architected series.
Before we dive into it, make sure to subscribe to Dashbird updates so you wouldn’t miss the next videos.
The serverless trilemma framework was developed a couple of years ago by a team of researchers in IBM. It helps us to evaluate architectures and make decisions considering the trade-offs involved.
The framework constraints are:
The Black Box principle indicates that Each function should work independently from the rest of the system and no implementation details should be leaked.
Consider two functions running on AWS Lambda: A and B. Function A uses the AWS SDK to invoke Function B.
But what happens if we need to move Function B code to another infrastructure? The AWS SDK invocation process will not work anymore This type of architecture makes it difficult to introduce changes and increases the likelihood of unintended consequences.
Function B is leaking its implementation details, thus not working as a Black Box. The leakage is having Function A aware that Function B is deployed in AWS Lambda.
To satisfy the Black Box principle, we could create an HTTP API. By routing requests through the API, we can decouple the functions. Later we can just update the API routing to the new infrastructure. This can be extremely valuable as the system and development team grows.
The Double Billing principle is relatively simple: two functions should not run at the same time while one is waiting in an idle state for the other to respond
In Serverless, we pay for the function execution time:
Ideally, we should avoid such situations.
Substitution is about having a composition of functions behaving just like any normal function. What is a composition? Consider a user requests an invoice from a billing system. It may rely on a second function to apply any discounts available. And yet another function is responsible for calculating Sales Tax. All functions are composed to work as a group, hence the name “composition”.
The substitution principle indicates that all three functions together should behave like a function From invocation methods to timeout to dead-letter-queue, everything behaves as if they were a single function.
The requester doesn’t actually know this is a composition of functions. Any developer can rely on this composition without worrying about how it behaves, they just apply everything they already know. This property improves productivity and quality.
Most of the time, it is not possible to have all properties together. Applying the Black box principle is usually easy. When it comes to the other two, there is usually a trade-off. When we prioritize one, such as Substitution, it becomes difficult to apply Double-billing.
This framework helps to make architectural decisions and identify what needs to be prioritized.
The Black Box improves:
Double billing enables:
What should be prioritized will really depend on each case. We’ll dive into more details about this decision-making process in the next videos on this series, so stay tuned!
No results found
End-to-end observability and real-time error tracking for AWS applications.