Running any application in production assumes reliable monitoring to be in place and serverless applications are no exception. As modern cloud applications get more and more distributed and complex, the challenge of monitoring availability, performance, and cost get increasingly difficult. Unfortunately there isn’t much offered right out of the box from cloud providers.

In this article you’ll find out how to 10x your development speed with local serverless debugging. Questions such as “what happens when you scale your application into millions of requests?”, “what to expect when going serverless?”, “how does it look like?”, or “how is it to build applications on serverless and work locally?” will be addressed.

As everything good in life, serverless also comes with its downsides. One of them is the infamous “cold start”. In this article, we’ll cover what they are, what influences serverless startup latency, and how to mitigate its impacts in our applications.

Serverless lets you deploy applications far away in a data center of a cloud provider. This relieves you of the lion’s share of operational burdens. The more you buy into your cloud provider’s ecosystem, the less you have to do yourself: no more OS updates or database bugfix installations. But you still need to do some operation-related work on your own. For instance, monitoring your application to know what’s going on in that far away data center.

A deep dive into boto3 and how AWS built it. AWS defines boto3 as a Python Software Development Kit to create, configure, and manage AWS services. In this article, we’ll look at how boto3 works and how it can help us interact with various AWS services.

Serverless applications, more often than not, have logic distributed over multiple functions and services, which with growth and agents and wrappers attached, can get more complex and costly. This is where Serverless monitoring comes in to help. But what is Serverless monitoring? Serverless monitoring allows developers to gain important insight on what happens during each execution and event, errors become more easily visible, and measuring resource consumption for each invocation is possible.

Another generic error message from our favorite FaaS provider AWS Lambda. And again, there are multiple reasons why this issue could arise. Let’s first look at the basics of AWS Lambda to get a better intuition for when things go wrong later. Lambda is an asynchronous event-based service at heart.

We’ve been monitoring 100,000’s of serverless backend components for 3+ years at Dashbird. In our experience, Serverless infrastructure failures boil down to: These isolated faults become causes of failure due to dependencies in our cloud architectures (ref. Difference of Fault vs. Failure). If a serverless Lambda function relies on a database that is under stress, the entire API may start returning 5XX errors.