Why AWS Console isn’t the best for serverless debugging? We all know that debugging serverless is time-consuming and hard and that AWS Console doesn’t make it much easier. Across the AWS console, and adding tons of friction to debugging and troubleshooting efforts.
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. Across the AWS console, different types of monitoring data like logs, metrics, and traces are scattered in silos, adding tons of friction to debugging and troubleshooting efforts.
With CloudWatch, you have to look into multiple places to find out what executions happened when your latency metric spiked and that’s the case for debugging a Lambda function alone.
Things get even messier if your transaction spans multiple Lambda functions and a bunch of other managed services like DynamoDB or SQS. And then there are different regions and AWS accounts.
All this disconnect makes debugging serverless applications a real pain.
Here’s a typical case scenario of starting out with serverless. You start building your serverless application and you’re blown away by the development speed, you build many features in such a small amount of time, and naturally, you fall in love with serverless technology really quick. Then things go wrong because, well, that’s the nature of software development. Some misconfigured service, or some bug in a Lambda function you wrote, and now it’s time to debug. You’re forced to dig deep into CloudWatch, X-Ray, and whatnot, just to find out where your error is located.
Every error event that goes in that weakens your confidence in your stack a bit more and in the end, you get wary about moving fast and serverless becomes as slow and brittle as all other paradigms before it.
In this blog post, we are going to discuss how to Debugging AWS Lambda Functions with AWS X-Ray. By instrumenting our Lambda function and its related services with AWS X-Ray, we improve our ability to solve issues with our functions.
Serverless Express enables you to easily host Express.js APIs on AWS Lambda and AWS HTTP API. Here is how to get started and deliver a Serverless Express.js based API with a custom domain, free SSL certificate and much more!
Adding Code to AWS Lambda, Lambda Layers, and Lambda Extensions Using Docker. With Docker, we have three ways to add code to Lambda that isn’t directly part of our Lambda function. Try to AWS Lambda, Lambda Layers, and Lambda Extensions Using Docker.
Debugging with Dashbird: Lambda Configuration Error. The “Lambda configuration error” is as generic as it gets but at the end of the day, it’s a pathing issue. There are dozens of configuration attributes you can set for your Lambda function.
Serverless Proxy with AWS API Gateway and AWS Lambda. We can communicate between Public and Private instance via a Serverless Proxy thanks to AWS Api Gateway and AWS Lambda. Github Webhook calls a Public API Gateway, API Gateway triggers a Lambda attached to VPC.