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.
One of the benefits of Serverless architectures is the possibility of scaling applications without worrying about load balancers and clusters of servers. While services like AWS Lambda hold their promises on this area, there are usually misconceptions about how they work.
It is common for developers to assume that Lambda functions can scale infinitely, at any speed, in any circumstances. Reality is quite different from that. Lambda has limitations in both maximum concurrency and how fast it can scale up. Similar limitations are applicable to other services, such as DynamoDB tables or S3 buckets.
Understanding how these services scale is essential to build resilient and well-architected applications on top of them. This will lead to more stable software and services to your end-users, potentially translating into greater customer satisfaction and increased revenue.
The issue with scalability is that each service will scale in different ways. If they are tightly coupled, the application as a whole will be limited to its weakest node.
Consider a Lambda function that relies on DynamoDB to store information, for example. The DDB table might not be able to cope with the Lambda’s rapid upscaling. Depending on how we architect that dependency, the service will start returning error messages to its clients.
Having the two services decoupled will make it easier to buffer peak requests from Lambda and process on a pace that fits DynamoDB scalability speed.
Another benefit of decoupling, in this case, is making the architecture more flexible for future changes. Consider your team decided to migrate from DynamoDB to another database service, for whatever reason. If you have hundreds of Lambda functions tightly wired to the DDB tables, you’ll have to change the code for every single one of them, which may prove to be cumbersome and risky to run such migration in production.
Just as in code architecture we look for ways to reduce dependency among components, it’s important to decouple cloud resources as well. And API Gateway is a good ally for this task.
The main reasons are:
Instead of connecting a Lambda function directly to a DynamoDB table or to an S3 bucket, for example, we could create API endpoints mapping the DB operations (read, write, delete, etc).
To make the DB service even more of a black-box, the API could even embed a higher-level abstraction.
Initially, the Lambda function would have to build a DynamoDB query to write information on the table, for example. This would defeat part of the decoupling benefits: being able to migrate to another database without having to change the Lambda function code.
Instead, we can have Lambda sending requests in an agnostic format. As an example, in order to write a new user to the DB table, it could send:
{ "operation": "store-new-user", "data": { "id": "ABC123", "first_name": "John", "last_name": "Doe", "email": "john@doe.com" } }
The API Gateway would be responsible for mapping this request to a query that is compatible with the DynamoDB write operation API.
With this architecture, the client (Lambda) doesn’t even have to know where the data will be stored. The development team can have its own internal query standards that are decoupled from DynamoDB ones. Especially for large applications, this has the benefit of allowing multiple teams to collaborate with a reduced risk of having developers stepping on each other’s toes.
One team could take care of the data model and share it with several other teams taking care of different services. As long as the internal API contracts are followed, any changes to the data model or the application side can be introduced smoothly, without interfering with other team members.
Although they greatly contribute to higher scalability and resilience, decoupled architectures are not silver bullets. As we know well, bad things can still happen and affect our systems and the service provided to the end-users. In case you are looking for a cloud monitoring partner that is deeply integrated with these architectural patterns, you will want to check out Dashbird. It’s free and doesn’t require a credit card or code changes to set up your account.
In this guide, we’ll talk about common problems developers face with serverless applications on AWS and share some practical strategies to help you monitor and manage your applications more effectively.
Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.