IN
Almost every company today wants and needs an online presence, even if it’s only a simple static web page. Alternatively, a company’s only product might be software. Whatever the case, cloud computing is on the rise; with this rise come issues of scale, and with a larger scale come issues of cloud infrastructure availability and cost.
It is possible to reduce infrastructure cost, but how will you make sure that your online business never goes down? For that you’ll need to monitor your infrastructure continuously. This is difficult when you have multiple servers, but in most cases, a very simple solution is to go serverless.
What is Serverless?
Serverless is a cloud execution model in which you have server containers instead of servers. These containers are run (or provisioned) on demand, meaning that when there is nothing happening in your cloud service, all your serverless modules, or functions, are down. Nothing is running. But as soon as there is a trigger, an instance of the function is run and the trigger is handled.
Once the processing is complete, the function waits for some time (usually a few minutes) to handle another trigger if one comes in. If not, the instance is taken down. The next time there’s a trigger the instance is started again, and this is known as a cold start. The biggest advantage of going serverless is that you don’t have to worry about availability and scaling, and you pay only for what you use, unlike with traditional servers.
What is AWS Lambda?
Amazon Web Services (AWS) is the leading cloud infrastructure and services provider today, and Lambda is its serverless container service. Each such container is called a Lambda function. You can write small programs in any supported language that perform a particular function and deploy them as Lambda functions.
But the grass is not always greener on the other side. There are some problems you’ll face when you go serverless. For example, how will you monitor your Lambda functions? Sure, there are monitoring features provided by all serverless container providers but in most cases, they’re not really sufficient. Also, there are cases when you’d want to be alerted, for example, if your Lambda function got stopped before it could complete the processing. And this could happen for a variety of reasons.
AWS, for example, has two major limitations for Lambda functions. Your functions cannot be running for more than 15 minutes per invocation, and they can’t take up more than 3 GB of RAM. These are some hard limitations. But AWS alerts are limited in what they can tell you, and how.
As Martin Fowler himself says in a post on serverless architectures, “Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.” So how do you make monitoring and alerting easier?
Introducing Thundra
This is where Thundra comes in. Thundra is a one-stop solution to debug, monitor, troubleshoot, alert, and secure your Lambda functions. Using Thundra, you can easily monitor all your Lambda functions, even visualize the complete cloud-native architecture that you’ve built, and set up custom alerts.
The tool also helps you keep an eye on your infrastructure costs, Lambda function cold starts, number of errors, and much more. Having all this information right in your dashboard makes system monitoring very convenient, as you can see from the screenshot below of the stats for a sample test setup.
Figure 1: Lambda function statistics in Thundra dashboard
You’ll find much more information at a glance in other sections of Thundra.
Getting Started with Thundra
Create a free account and connect your Lambda functions and VMs with Thundra to get started monitoring. Thundra’s free account lets you monitor up to 1 million invocations per month with a 2 GB data allotment.
You can even have unlimited users, which means your whole team can be on Thundra for no additional charge. But if you use more than 2 GB of data per month or if you want to retain monitoring data in Thundra for more than a week, you’d do better to upgrade to one of the paid plans. To get more information about pricing, click here.
The Hello World Example Using Thundra
Once you sign up for a free account, you can start with Thundra’s Hello World example. Select any programming language. Thundra provides a very easy-to-understand guide to help you set up your first Lambda function using Thundra’s layer so you can see all the data in the Thundra dashboard.
The Thundra Dashboard
Log in to your Thundra dashboard after you deploy and test the Lambda function you’ve just set up. You’ll see various charts that provide all the information you need in one page. You can test these charts by invoking your Lambda function a number of times to see the data change.
Note that the dashboard has a section called “Alerts & Insights” for all the alerts you set up.
Creating Alerts
Alerts are a major part of Thundra and could become your primary reason for using it. You can set up alerts for four different types of metrics: functions, invocations, operations, and traces. The best part is that anybody with a little knowledge of SQL queries can create alerts.
To start exploring this, select a function you’d like to monitor and use the Query Helper interface to create a simple query, as shown in the screenshot below:
Figure 2: Creating a query using the Query Helper
Once you run this query, you’ll get the option to save it as an alert policy so that it can be run at any interval specified, as you can see from the screenshot below:
Figure 3: Saving query as an alert policy
Once you’ve saved it as an alert policy, this query will be run on the specified schedule and alert you if there are any results. Similarly, you can create custom alerts for invocations, traces, and operations. With this level of fine control, you can easily get alerted if there’s anything wrong with your system. Try providing a wrong set of inputs to your test functions and wait a couple of minutes for the query to be triggered. You’ll get an email similar to the following:
Figure 4: Example email alert from Thundra
You can also integrate third-party services such as Slack and custom webhooks to send alerts to any device or platform on which you’re active.
Taking Alerts to the Next Level with Amazon EventBridge
Thundra was one of the first Amazon EventBridge partners, so you can create your custom logic using EventBridge to handle all of Thundra’s alerts. EventBridge helps teams build services that can be invoked when there is an event from a partner service, in this case, Thundra. When Thundra triggers an alert you can write a custom logic, based on the type of alert, which performs certain actions—either to take care of the issue or to improve the system and prevent the issue from recurring. This lets you minimize manual interventions when alerts are triggered and concentrate on getting work done instead of fighting fires.
The Beauty of Serverless
Whenever you’re going serverless with AWS Lambda, remember that you can add a Thundra layer to your Lambda functions and configure any kind of alert you want—via email, Slack, or any other service that works on webhooks. By using Amazon’s EventBridge, you can handle these alerts automatically, without manual intervention.
