Serverless has been gaining more and more traction over the last few years. The global serverless architecture market was estimated at $3.01 billion in 2017 and is expected to hit $21.99 billion by 2025. The number is reflected in the increasing amount of enterprises starting to look for ways of decoupling their current monolithic architectures and migrating their stack to serverless. Read more about the popular enterprise use cases for AWS Lambda.

Monitoring vs observability – is there even a difference and is your monitoring system observable? Observability has gained a lot of popularity in recent years. Modern DevOps paradigms encourage building robust applications by incorporating automation, Infrastructure as Code, and agile development. To assess the health and “robustness” of IT systems, engineering teams typically use logs, metrics, and traces, which are used by various developer tools to facilitate observability.

In this handbook, we’ll explain the AWS Step Functions Input and Output manipulation. There’s plenty to talk about AWS Step Functions. There are numerous articles available online talking about AWS Step Functions ever since Step Functions were introduced in 2016. Most of these articles might make you think that Step Functions are actually an extension of the Lambda function, allowing you to combine several Lambda functions to call each other.

Although AWS Lambda is a blessing from the infrastructure perspective, while using it, we still have to face perhaps the least-wanted part of software development: debugging. In order to fix issues, we need to know what is causing them. In AWS Lambda that can be a curse. But we have a solution that could save you dozens of hours of time. TL;DR: Dashbird offers a shortcut to everything presented in this article.

Recently, I saw a video from a really great developer and YouTuber, Ben Awad, where he discussed Serverless not make any sense. Even though I really enjoyed the video, I am not sure if the author’s points about serverless are entirely valid, and I want to discuss them in this article.

At first glance, all serverless monitoring services seem similar and aim to solve the same problems. However, in Dashbird, we have made decisions that fundamentally differentiate us from our competitors since day one. Over time, those differences have magnified and we have found increasing confirmation and confidence in our approach. Dashbird product strategy is based on three core pillars.

One problem that pops up quite frequently when people try to build serverless applications with AWS API Gateway and AWS Lambda is Execution failed due to configuration error: Malformed Lambda proxy response. There is nothing worse than generic error messages that don’t tell you anything you need to fix the problem, right? And AWS isn’t particularly known for its error message design, if you can even call it that, let alone for giving you the means of fixing the problem.

In this article, we’ll be discussing everything you need to know about the basics of AWS Lambda error handling and some popular methods using StepFunctions and X-Ray. Regardless if you’re an AWS Lambda expert or if you’re a new Lambda user, there’s always something new to learn.

Among all the new features and services that AWS announced during the re:Invent 2020, my favorites were definitely the AWS Lambda updates. And there were many! For example, your code execution is no longer rounded up to the nearest 100ms of duration for billing — you are now billed on a per millisecond. On top of that, AWS increased the Lambda’s memory capacity to 10 GB, and correspondingly the CPU capacity up to 6 vCPUs.

We all know that debugging serverless is time-consuming and hard and that AWS Console doesn’t make it much easier. CloudWatch isn’t quite known for its ease of use. Why? Well to start with, it has suboptimal search features, logs scattered across multiple buckets and groups, little visualization capability, and no structure of Lambda function invocations.