Serverless Stonks checker for Wall Street Bets: week 3 activity report insights

A few weeks ago we posted the “How we built a serverless Stonks checker API for Wall Street Bets” article. And ever since, we’ve seen quite a lot of volume in the Stonks checker app. In this follow-up article, we will show you some interesting findings around the API.

Last Two Weeks Summary

Over the past three weeks, we have seen a good amount of usage of the API we set up. You can see that there was a nice spike soon after the story broke. To note is that we have HTML caching setup in the returned value from the Lambda function. So you can see that about half the time, a Lambda is not called, and the results are a cached HTML version.

api summary

Dashbird Findings

The Hot Stock Checker (HSC) has run for a month now and got used quite a bit. We added the Dashbird integration to the AWS account that hosted the HSC infrastructure and looked at the past three weeks.

So, let’s jump right in and look at the Dashbird metrics of the Lambda function.

dashbird aws monitoring

In the three weeks of running the HSC, we got the most invocations at the launch, which is obvious. But Dashbird also shows other interesting findings.

The best insight here is, it didn’t cost us any money to run this application. The usage was so low that we never left the free tier of AWS Lambda

You can learn more about saving money on your Lambdas in this article about 6 cost optimization strategies that actually work.

dashbird observability

Over half of these invocations were cold-starts. In this specific application, it’s to be expected since it doesn’t have enough invocations per second to keep around a warm Lambda function. Still, if this was a production application that has to deliver on SLOs, it could be a good idea to use provisioned concurrency for the Lambda function to get rid of these cold-starts. This would also lower the average duration of our function.

lambda provisioned concurrency

The next point is memory usage. The Lambda function is configured with 256 MB of memory but only uses 28% of it. This is a bit tricky to optimize. In a low memory config like that, it’s not advisable to lower the memory consumption because memory config implicitly configures CPU performance.

So, if we lower the memory config, things would get cheaper but also slower. In the case of a Lambda function connected to an API Gateway, this could lead to higher latency and, in turn, a worse user experience. If it’s just about saving costs, and we would leave the free tier with our Lambda function, we could set the memory to 128 MB and save some money.

lambda error

We can also see the last invocation, the last error, and an insight.

We can use the last invocation to get details about that specific invocation, which isn’t very interesting in this project. So let’s move to the last error

The last error was 4 months ago, but Dashbird was integrated with that AWS account much later. This illustrates how Dashbird works under the hood. It reads data from CloudWatch Logs, which get written right when a Lambda function was deployed. So the data is already here before a potential customer decides to use Dashbird. This enables Dashbird to show us data from before its integration.

The way Dashbird uses already existing logging data especially shines with the Dashbird Well-Architected Lens. It is built around the automated AWS Well-Architected Reports, based on the AWS Well-Architected Framework‘s set of whitepapers containing best practices for building software on AWS infrastructure.

well architected framework

The old logs aren’t very interesting on their own. After all, we could open up CloudWatch ourselves and look for four months old errors. But with the Dashbird Well-Architected Lens, we can get higher-level insights about our infrastructure, like Lambda functions that aren’t used anymore or, like shown in the screenshot above, an upgradable Lambda runtime

You can check out the insights Dashbird provides to you on top of CloudWatch logs in our event library. It doesn’t just come with insights for Lambda, but also API Gateway, DynamoDB, and even Kinesis.

Further reading:

Introducing Dashbird’s automated Well-Architected Reports

AWS CloudWatch vs Dashbird observability

Log-based monitoring for AWS Lambda

Read our blog

AWS Lambda Cost Optimization Strategies That Work

From caching Lambda responses to building smaller functions to choosing the right memory configs. In this article, we’re exploring six specific steps you can take to optimize your AWS Lambda costs.

Serverless observability and real-time debugging with Dashbird

Learn how Dashbird helps to significantly improve observability and debugging real-time Lambda-based serverless architectures.

Challenges and Opportunities of Going Serverless in 2021

There are many obvious benefits of going serverless but also an equal amount of challenges you need to overcome to reap the fruits and really make serverless work for you. Here’s list of the challenges and advice on how to overcome each.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.