Wavefront is releasing a new way to instrument serverless functions, so you can monitor serverless applications with much-improved monitoring performance and cost savings, all with a very powerful yet simple Wavefront SDK and a few lines of wrapper code. I’m one of the engineers who developed this new capability, and in this first of a two-part blog series, I will introduce the concept of serverless computing (i.e. functions as a service), highlight the offerings of leading cloud provider platforms such as AWS and VMware, then show how to monitor your serverless functions, and more specifically with Wavefront.
Serverless Computing is Here
Serverless computing is a cloud-computing execution model in which the cloud provider platform dynamically manages the allocation of machine resources via functions. Functions execute application logic but do not store data. It’s a form of utility computing.
Think of this as “Functions as a Service” (FaaS); just upload your function (code) and the rest is taken care of by the cloud provider. Pricing is based on the actual amount of resources used by an application, not as pre-purchased units of capacity. Serverless computing still requires servers, hence it’s a misnomer. The name “serverless computing” is used because the server management and capacity planning decisions are completely abstracted (hidden) from the developer.
See table below which compares serverless functions to other cloud computing models.
(what all you need to worry about)
|1. Application Code
2. Runtime environment
|1. Application Code
2. Runtime environment
|1. Application code
2. Runtime environment
|1. Application code
(no need to provision, manage servers)
(how long it takes to get your code up and running)
|Cost||Buy/Rent Servers||Pay per VM||Pay per container||Pay only when your code is running|
(subject to approval)
(event-driven, scale up/down)
Serverless computing is gaining a lot of traction and all the popular cloud provider platforms now have first-class support for it. Amazon offers AWS Lambda service with support for Python, Node.js, Go, Java, C#, etc. Google Cloud Platform offers Google Cloud Functions, supporting Node.js. IBM published IBM OpenWhisk which is an open-source serverless platform and includes native support for Node.js, Python, Java, Swift, etc., and runtimes via Docker containers. Microsoft Azure offers Azure Functions and nuclio. VMware offers Dispatch which is built on Kubernetes and provides tools and services to deploy and manage production-ready, function-based serverless applications.
AWS Lambda in the Spotlight
Diagram above sourced from: https://aws.amazon.com/lambda/.
AWS Lambda, introduced by Amazon in 2014, was the first public cloud vendor offering of a functions-based, serverless computing service. AWS Lambda empowers developers by letting them run code in production without provisioning or managing servers. You pay only for the compute time you consume; there is no charge when your code is not running. With AWS Lambda, you can run functions (code) for virtually any type of application or backend service, all with zero administration. Just upload your functions and Lambda takes care of everything required to run it. AWS Lambda scales your code (up and down) with high availability.
You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app. AWS Lambda is completely event-driven (function only runs when invoked). This is ideal for applications exhibiting idle periods followed by peaks in traffic. AWS deploys your code in a container. The container is created, deployed and managed by AWS, completely abstracted and hidden from the developer.
1. Cost Savings
Serverless is more cost-effective than renting or purchasing a fixed quantity of servers, which generally involves significant periods of underutilization or idle time. It can even be more cost-effective than provisioning an auto-scaling group, due to more efficient bin-packing of the underlying machine resources. This can be described as true pay-as-you-go computing.
2. Sub-second Metering
With AWS Lambda, you’re charged for every 100ms your code executes and the number of times your code is triggered. You don’t pay anything when your code isn’t running. There are no fees for idle time.
3. No Servers to Manage
AWS Lambda automatically runs your code without requiring you to provision or manage servers. Just write the code and upload it to Lambda. The immediate cost benefits are related to the lack of operating systems costs, including licenses, installation, dependencies, maintenance, support, and patching.
4. Continuous Scaling
AWS Lambda automatically scales your application by running code in response to each trigger. Your code runs in parallel and processes each trigger individually, scaling precisely with the size of the workload.
Real World Applications
Serverless Computing is not a mere theoretical exercise. Microservice architectures allow you to easily integrate with AWS Lambda. At the same time, many legacy applications are being re-written from the ground up to embrace serverless computing. As the leader in cloud computing services, AWS is at the forefront of this revolution with Lambda.
For example, using AWS Lambda, Coca-Cola has built a serverless solution for publishing nutrition information to their food service partners. They have also built a prototype application using AWS Lambda to analyze a stream of photos from Instagram and extract trends in tastes and flavors.
Applications Aligning with Serverless
Some types of applications are a better fit for serverless computing than others. Such good fits include applications that are:
1. Triggered by a request/event.
……a. Example: “Thumbnail service”.
………….i. Images land in S3 buckets.
………….ii. S3 object event notification.
………….iii. Invoke Lambda function to generate a thumbnail.
……b. Example: “AWS CloudTrail analyzer”.
………….i. Look for specific event type or log entry as they occur and take some action.
2. Triggered by state change. Example: write Triggers (custom actions) for your Amazon DynamoDB table based on changes to your database table.
3. Periodic jobs.
……a. Schedule Using Rate: “Invoke Lambda function every minute”.
……b. Schedule Using Cron: “Invoke a Lambda function at 10:00 AM (UTC) every day and repeat for next 2 hours every 5 min”.
How to Monitor Serverless Applications
As a developer, if you’re using AWS Lambda, your job is to write the function: write and forget! Well not quite. As a developer, you also need to think about your monitoring strategy for your functions running on AWS Lambda. After all, a function is nothing but the code written by the developer which runs on AWS infrastructure automatically. But just like any other piece of code, it’s the responsibility of that developer to monitor those functions for performance and reliability.
AWS Lambda performs some automatic monitoring of Lambda functions on your behalf, reporting metrics through Amazon CloudWatch. To help you monitor your code as it executes, Lambda can automatically track:
- Number of requests
- Latency per request
- Number of requests resulting in an error
AWS Lambda publishes these associated metrics to Amazon CloudWatch. Using the Wavefront Amazon CloudWatch integration, you can retrieve all those metrics into Wavefront. Once the integration is set up and metrics are flowing to Wavefront, you can run analytics to create charts, dashboards, and alerts. But the question you might ask is: “Why pay Amazon to store and export metrics from CloudWatch?“, and as well, “Why add a visualization lag by extending your metric pipeline using CloudWatch? Instead of setting up the CloudWatch integration and exporting AWS Lambda metrics from CloudWatch to Wavefront, what if your functions can send the metrics directly to Wavefront with minimal network overhead, very little additional code, and lower overall cost.
Wavefront’s Lambda SDK
The Wavefront Lambda SDK (Python, Go, Node.js) provides first-class integration with AWS Lambda. We’ll monitor your Lambda functions for you and send the standard Lambda metrics (listed below) + custom metrics for those functions directly to Wavefront. There is no need to pay AWS CloudWatch for storing and exporting those metrics to Wavefront. Also, since the metrics are coming directly from your Lambda function, they become available on Wavefront in real-time as opposed to polling them from CloudWatch, say every 5 minutes. Also, our Lambda SDK makes it is incredibly easy to send custom metrics (e.g. business metrics) from your Lambda functions.
|1||aws.lambda.wf.invocations.count||Count of number of Lambda function invocations aggregated at the server.|
|3||aws.lambda.wf.errors.count||Count of number of errors aggregated at the server.|
|5||aws.lambda.wf.coldstarts.count||Count of number of cold starts aggregated at the server.|
|7||aws.lambda.wf.duration.value||Execution time of the Lambda handler function in milliseconds.|
The Wavefront Lambda SDK also adds following point tags to all the above metrics.
|1||LambdaArn||ARN (Amazon Resource Name) of the Lambda function.|
|2||Region||AWS Region of the Lambda function.|
|3||accountId||AWS Account ID from which the Lambda function was invoked.|
|4||ExecutedVersion||The version of Lambda function.|
|5||FunctionName||The name of Lambda function.|
|6||Resource||The name and version/alias of Lambda function. (Ex: DemoLambdaFunc:aliasProd).|
|7||EventSourceMappings||AWS Event source mapping Id (Set in case of Lambda invocation by AWS Poll-Based Services).|
As an application developer if you’re developing your Lambda function in say Python, all you have to do is to decorate your AWS Lambda handler function with @wavefront_lambda.wrapper, and voila, you get all the standard Lambda metrics with the point tags sent directly to Wavefront.
import wavefront_lambda @wavefront_lambda.wrapper def handler(event, context): # your code
I’ll dive deeper into this in part 2 of this blog series, but if you want to explore more details now, visit https://github.com/wavefrontHQ/wavefront-lambda-python
We’ve included an integration tile in Wavefront to give you easy access to out-of-the-box Wavefront AWS Lambda dashboards. See below a couple of example dashboards:
Note that you can also monitor your custom metrics that are sent directly to Wavefront using these dashboards. The recommended approach is to clone one of these new Lambda dashboards and then add new charts to the clone, or you can just as well create a new dashboard from scratch.
Monitor Serverless Better with Wavefront
Monitoring applications on serverless architectures require a different school of thought. Using our Wavefront Lambda SDK, you get all the standard Lambda metrics out-of-the-box sent directly from your Lambda functions to the Wavefront platform. And as an application developer, you only need to focus on writing your Lambda function and write very little additional code to monitor those functions in Wavefront. There is no need to invest time and money to setup Wavefront’s AWS CloudWatch integration in order to monitor your Lambda function. Along with the standard metrics, it is also possible to send custom business metrics directly from your Lambda function to Wavefront.
In the next blog post of this two-part series, we’ll discuss how you can send those custom business metrics to Wavefront using Delta Counters, an important new metric type ideally suited for serverless applications that are naturally stateless. Stay tuned!
Until then, give Wavefront a try today with a free 30-day trial. Wavefront will also be exhibiting at Serverlessconf in San Francisco on July 31 – August 1. Stop by our table to learn more and see a demo of our new serverless application monitoring and Lambda SDK.
Click here to read Part 2 of this blog.Get Started with Wavefront Follow @sushantdewan Follow @WavefrontHQ