Operations | Monitoring | ITSM | DevOps | Cloud

What are the crucial AWS Lambda metrics you should definitely be monitoring? Your application does not need to be “huge” for it to have enough functions and abstraction to get lost in it. As a DevOps engineer, you can’t cover every single factor. Showing relevant facts and asking the right questions is crucial! So when there’s a fire, you can troubleshoot in no time. Every organization is unique, and every workload has its own utility.

Auto-instrumenting Lambda Monitoring didn’t originate through a focus group or business plan. It started as a hackathon project in which our growth team used Cloudwatch to build a prototype that could instrument Lambda functions with Sentry. We did this by using Cloudformation’s stack to automatically create resources in a customer environment while streaming CloudWatch Logs to Sentry through the Kinesis Firehose.

Lambda not logging to CloudWatch? It’s actually one of the most common issues that come up. Let’s briefly go over why this problem needs to be solved. CloudWatch is the central logging and monitoring service of the AWS cloud platform. It gives you insights into all the AWS services. Even if you can’t deploy and test serverless systems locally, CloudWatch tells you what’s happening to them.

AWS announced AWS Lambda Extensions back in October 2020 and I wrote extensively about it at the time – what it is, how it works, and why you should care. In short, Lambda Extensions allow operational tools to integrate with your Lambda functions and run either in-process alongside your code or in a separate process. To better understand the problems they solve and their use cases, please read my previous article.

Designing and running workloads in the cloud is complex. Many services need to fit together in just the right way for optimal performance. The opportunity for error lurks around every corner. This is a high-stakes game with a huge premium on getting things right from the beginning. Even small mistakes can snowball. To help, AWS studied the architectures of thousands of its customers and supplemented that learning with insights from experts.

Google Cloud Platform is growing quickly, providing solutions for everything from cloud storage to managed Kubernetes to serverless computing. Since Google App Engine launched in 2008, Google’s suite of serverless products has expanded to help enterprises accelerate application development without having to manage or scale their own infrastructure.

A while ago, a merry bunch on Reddit at the subreddit r/WallStreetsBets (WSB) took on Wall Street. Ironically, through an app called Robinhood. As Alanis Morisette would say, “A little too ironic, don’t ya think?” You had to be in there and in the know at the right time to benefit from the situation. That’s why we built a serverless API to keep track of all the hot and trending stock chats on WSB, that will notify you when the next GME is about to blow up.

Securing AWS Fargate serverless workloads can be tricky as AWS does not provide much detail about the internal workings. After all… it’s not your business, AWS manages the scaling of underlying resources for you. :) While the security and stability of Fargate’s system is an inherent feature, Fargate follows a shared responsibility model, where you still have to take care of securing those parts specific to your application..