We all know that debugging serverless is time-consuming and hard and that AWS Console doesn’t make it much easier. 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 . Across the AWS console, different types of monitoring data like logs, metrics, and traces are , adding tons of friction to debugging and troubleshooting efforts. CloudWatch Lambda function invocations scattered in silos With CloudWatch, you have to when your latency metric spiked and that’s the case for debugging a Lambda function alone. look into multiple places to find out what executions happened Things get even messier if your transaction spans functions and a bunch of other managed services like or . And then there are different regions and AWS accounts. multiple Lambda DynamoDB SQS All this disconnect makes debugging serverless applications a real pain. Here’s a typical case scenario of . 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. 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. starting out with serverless Then things go wrong 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. But what you want is to keep that speed of delivery and for this, Let’s face it, very often, . you have to know what’s going on. CloudWatch just isn’t enough Here’s why you should stop digging around in AWS Console In the last years, many serverless advocates sold you this new paradigm with (FaaS) solutions like AWS Lambda, and while it’s pretty awesome to be able to get a small part of code running in the cloud, without managing servers or containers, . function as a service FaaS is just the catalyst of serverless You should , using managed services like AppSync, S3, and Cognito, whenever possible and only fall back to Lambda when things simply won’t support your use-case. think of serverless more like functionality as a service The problem is that most monitoring solutions go the same route as the serverless advocate went, and focus on Lambda. ; you can either get full insights in your system but you have to build most of it with custom Lambda functions or you get the full power of serverless with managed services, but ; which leads us back to the loss of trust from the beginning. This leads to a dissonance debugging them will be a pain gives you for all your AWS related monitoring needs. You’ll find metrics, logs, and tracing in one place, which makes correlating cause and effect much simpler. Dashbird one source of truth Dashbird tries to home in on managed AWS services so you don’t get lost in throwing buckets of hand-tailored code at your projects. SQS, DynamoDB, Step Functions, API Gateway, all these services that lower your time to market feel snug as a bug in the Dashbird monitoring platform. Grouping Resources by Project Instead of Type Just Makes Sense Dashbird groups all your resources by service, like you are used to from the AWS console, but also . Projects group services that are related to each other in a , but not in a technical sense. For example, a project can consist of API Gateway, Lambda, and DynamoDB. allows grouping by project logical sense When you get an error it is usually related to a request that went through your pipeline of services. To find an error you have to follow the request through all these services. With the AWS console, which groups services by technology, . In a project all this is consolidated, so you can find all the services the request hit in one place. you would have to navigate multiple pages to find your error Find Errors Before they Happen Naturally, you always want to . Dashbird alarms and insights, which are based on the and Dashbirds know-how of monitoring years of serverless production-ready systems, help you to do just that. keep the time from finding a bug to fixing it as low as possible AWS Well-Architected Framework Dashbird’s insights if something fails, isn’t configured right or if metrics go in a dangerous range well before they can lead to an error. This way you can continuously your architecture and . immediately notify you improve prevent errors from happening With a rather young technology like serverless, it’s always a pain to figure out best practices. If it’s used right, you get an advantage over all competitors that do it the old way; if it’s used wrong, you might be worse off than them. So getting this knowledge, not just from a generic article on the internet, but . tailored to your specific system will save you valuable time and dollars off your Cloud bill Conclusion If you encounter problems within your serverless systems, it’s crucial to . Clicking around in umpteen different places around the AWS Console to correlate your errors with the requests that caused them isn’t your best way of action here. Sure, all data is there, but often there is than you need and combing through it takes time too. find out what caused it in the shortest amount of time possible much more data Third-party monitoring services like help you cut through the noise and . Dashbird consolidates all the log, metric, and tracing data into one place so you can query them as needed. With projects you can group serverless resources logically, which cuts down on log-lines again. Dashbird dramatically reduce the time to debug and troubleshoot Finally, there are the Dashbird metrics based on the and Dashbird’s experience in monitoring serverless systems in production for years. These metrics can . AWS Well-Architected Framework find errors for you before they even happen Many problematic configurations can be surfaced to you in the Dashbird console before the first customer even uses your system. While a happy user is good, this feature can help especially with security related problems, which are a huge liability in the long run. Also published at https://dashbird.io/blog/aws-console-serverless-debugging/

Amazon

BUNCH

How to Deploy AWS Lambda with Docker Containers

An Introduction to Microservices and Serverless

Serverless af

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Serverless

Nominated for 2022 - HackerNoon Contributor of the Year - Aws

Too Long; Didn't Read

Make resilience your competitive advantage

Why the AWS Console Isn’t the Best for Serverless Debugging

Why the AWS Console Isn’t the Best for Serverless Debugging

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Things in Engineering We Don't Spend Enough Time On

The Noonification: How Amazon Treats Warehouse Workers Who Contracted COVID (11/30/2022)

10 Free Ways to Promote Your Amazon Products

10 Failed Startup Product Examples by Google, Microsoft and Amazon

10 Best Infographics Of 2018

10 Things in Engineering We Don't Spend Enough Time On

The Noonification: How Amazon Treats Warehouse Workers Who Contracted COVID (11/30/2022)

10 Free Ways to Promote Your Amazon Products

10 Failed Startup Product Examples by Google, Microsoft and Amazon

10 Best Infographics Of 2018

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps