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
A system is said to be reliable when it is:
It doesn’t mean the system is capable of standing any and all kinds of issues. A meteor striking Earth and wiping out everything is a situation where no system can stay reliable.
When one or a few components of a system start failing or deviating from what’s expected, we have a fault. When the entire system stops delivering, there is a failure.
It is impossible to reduce the likelihood of failures to zero. Even faults are impossible to prevent no matter what. The idea is accounting for faults and working ways to prevent them from escalating into failures.
Building reliable systems means predicting faults and having safeguards and alternatives that are built-in the system. In the event of faults, it should be able to quickly adapt itself and continue operating with minimal or zero disruption.
There was a time when internet users would accept service disruption patiently. Mission-critical services were not heavily reliant on cloud applications. Those days are gone.
We are starting to see a growing pressure over the IT sector to deliver the same predictability, quality and performance as other industries. Automobile manufacturing, airline service, medical care. They all must meet the highest standards. So does software applications.
Building a system to be reliable means the application is prepared to win trust. It allows the company to face competition in a much better shape. Chances of success are much higher.
Configuration errors by system admins are known to be the leading cause of internet services downtime1. Humans are prone to failing and are unreliable. Although there is no easy way to fix that, there are strategies to work around it.
Abstractions, APIs, interfaces. They can work as digital fences to avoid humans from making mistakes.
One of the fastest growing trends in cloud computing nowadays is the serverless paradigm. It implements all those three solutions.
A serverless service, such as AWS Lambda, abstracts away infrastructure provisioning and management, exposes the service through secure and well-designed APIs, and provide a battle-tested interface for developers to build upon.
Some good practices are also key:
This type of fault usually leads to systematic issues. An unknown bug only manifests itself when given a particular type of input, for example. This can easily be overlooked in the best testing and deployment setups.
Or it could be a service that the application relies on. When it slows down or starts behaving in an unexpected way, the system must be able to adapt itself appropriatelly.
An new version of a certain system component creates a conflict with another library that was difficult to anticipate in a testing environment.
Software code always makes assumptions about the environment in which it’s running, the inputs and data-points it will be working with. For a long time, reality might meet those assumptions, but when it doesn’t, the system can derail quickly.
Allowing processes to restart quickly in the event of a crash, isolating components, monitoring carefully thought metrics, automated issue alerting. These are all methods to avoid or at least deal with software errors in a better way.
Hardware faults are usually isolated events that have a relatively lower potential of causing systematic issues. Nevertheless, they can as well escalate to failures and must be accounted for.
A hardware fault can involve a CPU, RAM, local or external network, the power supply system, cooling systems in a data center, etc. By using a cloud service such as AWS, developer already abstract away the need to account for many of those issues in the development process2.
Managed services, such as AWS EC2 and RDS abstracts machine administration by providing virtual instances that can run anywhere. Serverless services such as AWS Lambda and DynamoDB go one step further: they entirely abstract away the need to provision and manage infrastructure.
AWS employs advanced and sophisticated redundancy strategies to ensure reliability and high levels of availability to its systems. When developers build upon them, it can speed up an application development cycle by a great deal. This can be an important competitive advantage, especially to startups and SMEs.
This article was heavily inspired by the Designing Data-Intensive Aplications book, by Martin Kleppmann. The book itself is a compilation of a multitude of sources, some of which we link below in the footnotes.
No results found