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.

#aws #aws-lambda #serverless #debugging