When you make the move to serverless, one motivating factor is cost. Serverless can reduce your overall operational expenses, but to achieve the maximum amount of savings you need good observability.
A common problem companies face when moving to serverless is not understanding the downstream costs of supporting services that your cloud functions interact with. For example, if your application is operating with consistent traffic at scale, then the cost of your cloud functions, even though they are pay-per-use, could end up costing more than a traditional virtual machine running 24/7.
However, to be confident that serverless will help reduce your cloud expenses you need to look deeper into your application and it’s actual requirements.
A major reason behind inflated serverless costs is due to the lack of optimization. Fine tuning your cloud functions and optimizing supporting cloud resources is key to maintaining optimal performance and simultaneously keeps the cost to a minimum while building with serverless. The ability to know what needs to be tuned and optimized comes from regular observability and monitoring and that’s where monitoring services such as Thundra come in.
Observability is crucial, especially for serverless architectures because when you’re working with serverless you’re typically working with a lot of supporting fully managed services (also known as “service-ful”). Dealing with this increase in services can be a challenge to correlate and understand.
Thundra helps with these kinds of problems by making it easy to analyze performance metrics, detect anomalies, and automate compliance and security checks.
In this article we are going to explore how we can leverage Thundra to optimize part of our serverless cost.
Getting to know Thundra
As soon as you sign up with Thundra, their onboarding process takes over and guides you through the setup. There are two options: Thundra Debugger (debug functions locally from your IDE); Thundra Console. Let’s take the Thundra console route.
A Cloudformation stack sets up your Thundra dashboard in minutes.
After the stack has launched, the console will guide you through the interface step-by-step so everything is clear from the get go.
Ways to effectively manage your functions on Thundra:
- Tagging comes handy when you want to filter out Lambda functions belonging to the tag names you specify. Thundra allows tagging in two ways, Invocation tags and Application tags. Invocation tags are applied inside the function, and Application tags are applied to the Lambda function itself via their environment variables. Refer doc to know more.
Filtering based on Application tags
- Projects are a great way to group functions and view their cost, request count and other metrics as a whole. You create new projects by navigating from the left pane. Every project comes with an API key. It’s when you attach this key to your functions they become a part of that project.
Project creation view
Viewing metrics by project name
- Thundra has a concept called Uniques traces which show executions that deviate from a historically repeated execution flow. For example, a Lambda function sending out an SNS notification is a unique trace (one execution flow), but if that function fails to send out the SNS notification and instead performs another operation, then that again is another unique trace Thundra will record for you. It’s a great way of analysing the flow of your application. To deep dive on unique tracing visit this article.
- Architecture gives you a full view on how all functions and other resources of a particular project come together for an application.
- Alerts by Thundra notify you when certain conditions are met. The queries you type in at the dashboard for filtering in functions can be converted into alerts which automatically send out notifications via the channels you specify. This method is of great use when you wish to be notified about certain conditions without manually having to monitor them through filtering.
Creating alert policies from functions dashboard
Above were some key areas that developers can use to gain insights into their serverless applications with Thundra.
What Thundra monitoring can do for your bottom line?
Now that we have talked about a few tools Thundra offers, let’s breakdown how you can use these insights to save money.
Let’s assume a function is configured with 3008MB of memory but only utilizes 1024MB on average.
This would mean we’ve over-provisioned our cloud function and if we lower the amount of configured memory we will see real cost savings.
However, before reducing your function’s memory, an aspect to check is the average consumed memory of the function.
If the average memory across a large set of invocations is 50% or lower than what you’ve configured, then you should have some room to lower the memory and reduce costs.
On the flip side, if the average memory of a large set of invocations is above 50%, then you may want to hold off on reducing the memory to avoid out of memory errors or slow invocations.
If you do adjust the memory of your functions, make sure to test afterwards and see how the changes affected the invocation duration. As a slower duration can have the inverse effect, increasing your costs.
The following are some more insights into how monitoring can lead to further reductions of your overall costs.
- When it comes to monitoring invocations, Thundra provides a heat map showing the duration and number of times a function was invoked. With this heat map you can pinpoint where the majority of your Lambda cost is coming from.
- Less function duration = less cost. Your function may have dependencies that add onto the time it takes for its execution. This is particularly the case when that function is interacting with third party services. Thundra gives those details so you know where you should focus when optimizing those services.
- Thundra’s tracing mechanism is built on the OpenTracing API and has Distributed tracing, as well Local tracing for functions. With a micro service architecture that interacts with several cloud services, distributed tracing allows you to zero in on the exact point of failure so you know exactly what needs fixing. Local tracing is within the function itself to analyze slow/buggy code and improve its performance.
It’s clear that monitoring and observability for serverless applications are an absolute requirement for performance enhancement and cost savings. To reassert the points we discussed:
- Thundra’s console is setup for efficient monitoring along with the tools they provide and how effectively you can leverage them.
- Monitoring can help achieve optimal performance and minimize cost for your applications.
Here are some articles by us that reinforce the ideas we talked about:
- Tips for cost control - https://blog.thundra.io/three-tips-to-control-the-cost-of-aws-lambda
- Metrics tracking with unique tracing - https://blog.thundra.io/tracking-the-kpis-of-unique-traces
You can’t figure out the pain points of the application if you don’t know where to look. Thundra does just that by showing you actionable insights and inferences on the service flow of your functions.