Serverless Stonks checker app for Wall Street Bets: week 3 activity report
Tags: aws, serverless, devops, sre
Published: 2021-05-28 10:41:04

A few weeks ago we posted the "[How we built a serverless Stonks checker API for Wall Street Bets](https://dashbird.io/blog/serverless-hot-stock-checker/)" 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](https://lh6.googleusercontent.com/9UkqyIBl8R843ufyUMv-4rbuqj2s6-HktwRMICqph1D2JBMTmPE2KaLw6CUDLugn3fJR_6Wi7vtUSWj1bXD5t1_JdELNM_sc8IsZU-JoY7MyQZhbSMUlJt5T_u1is40To0lbs8LU)

Dashbird Findings
-----------------

The **Hot Stock Checker** (HSC) has run for a month now and got used quite a bit. We added the [Dashbird](https://dashbird.io/) 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](https://lh3.googleusercontent.com/ZMj2ev5sFhPQcblgs4M6FYaoUzKswvVEwKiZB_k-r1-M1Ek4IBODvjx3HVEdo12nivE3A7BgKqbIwh-H22J8niEaAesjYvYahfNhP7PVOR89-h1pQ937Xf9S444_Ut6TYCZXRqTN)

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](https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/).

![dashbird observability
](https://lh3.googleusercontent.com/nPuALfiXOSdCldNmLnqrfZRbyy6IqdP2XcdqzY7UVhm_ZNxJ-BcKSEluzyhtVXVcugLsXdgi9kYjPKtgEEWkC4VhGLFCqmS9jKIv1hbYrx_fcWxNMowueyH8Mdf4MHZZyB1nF4Yd)

Over half of these invocations were **[cold-starts](https://dashbird.io/blog/can-we-solve-serverless-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](https://aws.amazon.com/about-aws/whats-new/2019/12/aws-lambda-announces-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
](https://lh4.googleusercontent.com/8vBnBgFKcjvMP3FCrlROdaIhbeaPcZ_LKr3A1xt9B6VFSx0c8mLb6xItxo-uEPoGcZkmG7ocz-4-mR-RimFjmnSXj9cl21P7Kp573WGQuWU9dFdk7Udmhhv0CO_guNRrbc7-1ckR)

The next point is [memory usage](https://dashbird.io/blog/lower-aws-lambda-bill-increasing-memory/). 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](https://lh3.googleusercontent.com/KkP9L2Cvt5bQcjCiTZvBCAP3KiFtkq3SbeFQ7PVVd6CI1VCobmqRGJjowLBzDjp-3N7TmH8im5IADPmyYzoWNIpbR5tEnE6z9fmzsdyX-myTjx8BtOZBqt621mg-Hgt2HmzTk4Ss)

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](https://dashbird.io/) 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](https://dashbird.io/serverless-well-architected-reports/)**, based on the [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)'s set of whitepapers containing best practices for building software on AWS infrastructure.

![well architected framework
](https://lh5.googleusercontent.com/SuaDAlbdtT0-i8pQzgDrOo6FNZhRNZHiHpG3ahZfURD0zzqLyh8LTNR7fIDrZh99SVwbzWE0-nsQOyKXBPHPwTNEJne1xF9DgVuJRfIpdDs3qZH7ihYShix77I7wiyff62V-B70Z)

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](https://dashbird.io/event-library/). It doesn't just come with insights for Lambda, but also API Gateway, DynamoDB, and even Kinesis.

[![](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2020/07/observability-1024x190.png)](https://dashbird.io/serverless-observability/)

* * * * *

Further reading:

[Introducing Dashbird's automated Well-Architected Reports](https://dashbird.io/blog/introducing-well-architected-insights/)

[AWS CloudWatch vs Dashbird observability](https://dashbird.io/blog/cloudwatch-vs-dashbird/)

[Log-based monitoring for AWS Lambda](https://dashbird.io/blog/log-based-monitoring-for-aws-lambda/)