When you build your application on top of Lambda, AWS automatically scales the number of “workers” (think containers) running your code based on traffic. And by default, your functions are deployed to three Availability Zones (AZs). This gives you a lot of scalability and redundancy out of the box. When it comes to API functions, every user request is processed by a separate worker. So the API-level concurrency is now handled by the platform.
A key metric for measuring how well you handle system outages is the Mean Time To Recovery or MTTR. It’s basically the time it takes you to restore the system to working conditions. The shorter the MTTR, the faster problems are resolved and the less impact your users would experience and hopefully the more likely they will continue to use your product! And the first step to resolve any problem is to know that you have a problem.
Some time ago, an ex-colleague of mine at DAZN received an alert through PagerDuty. There was a spike in error rate for one of the Lambda functions his team looks after. He jumped onto the AWS console right away and confirmed that there was indeed a problem. The next logical step was to check the logs to see what the problem was. But he found nothing. And so began an hour-long ghost hunt to find clues as to what was failing and why there were no error messages.
At Lumigo, we recently ran into some issues with a service we built on top of our Nodejs AWS Lambda handler. These issues were the result of lambda execution leaks from within our serverless code. In this article, I’ll explain about node.js lambda execution leaks and how to avoid them.
Ten years ago, Amazon found that every 100ms of latency would cost them roughly 1% in sales. This is a pretty clear statement on the importance of user experience! It’s especially true in today’s ultra-competitive market where the cost of switching (to another provider) for consumers is lower than ever. And one of the most common performance issues in serverless architectures is related to elevated latencies from services we depend on.
We’re thrilled to announce that Gartner has named Lumigo a cool vendor in its recent Cool Vendors in Performance Analysis for Cloud-Native Architectures report by Padraig Byrne, Josh Chessman, Federico De Silva, Pankaj Prasad, Charley Rich, published May 18, 2020. The report explains something we at Lumigo heartily agree with: in a cloud-first world, the lines between development and operations are blurring.
Today, the AWS Lambda platform has added a new arrow to its quiver – the ability to integrate with Amazon Elastic File System (EFS) natively. Until now, a Lambda function was limited to 512MB of /tmp directory storage. While this is sufficient for most use cases, it’s often prohibitive for use cases such as Machine Learning, as Tensorflow models are often GBs in size and cannot fit into the limited /tmp storage.
We added out of the box alerts for irregular behaviors. Lumigo Insights will trigger an alert the second it detects an irregularity with your functions ensuring you’ll know the second things start to go sideways.
One of the great things about Lumigo is that it records a lot of context about each Lambda invocation. This includes the invocation event and its return value, as well as the environment variables that were in use at the time. I find this super helpful because it gives me all the relevant information about an invocation in one place. I don’t have to jump between different screens to find the relevant information and then piece the clues together in my head.
Lumigo’s System Map is a real-time visualization of your entire application. A bird’s eye view of the whole stack with filters that allow you to drill down into a subset of your infrastructure. Our systems have grown exponentially both in scale and complexity. AWS takes care of scaling automatically, ensuring your application will scale gracefully regardless of the programming language, load, or location.
