It has been 2 weeks after Re:Invent 2018 and the excitement that the serverless announcements created still remains high. Among the many announcements, the most exciting one for me was the launch of AWS Lambda Layers. Thundra was one of the launch partners for this announcement, which was a thrilling moment for us. But, in addition, I believe Lambda Layers is an extremely powerful feature, especially when packaged with an AWS Lambda Runtime API.
For those of you who aren’t familiar with AWS Lambda’s newest features, Lambda Layers allows AWS Lambda users to quickly and efficiently deploy, manage, and configure common elements not natively provided in AWS Lambda within their serverless applications and even across multiple AWS Lambda functions or accounts. The Lambda Layer is a modular package of commonly used code that you deploy separately from your own application, which will probably experience frequent updates. A Lambda Layer is commonly packaged with data, a custom runtime, and/or libraries, depending on the use case.
There are already numerous, very interesting, examples of Lambda Layers and Runtime APIs. Some of the examples are, The Serverless Open Runtime by The Serverless Framework, Serverless COBOL by Blu Age (my personal favorite custom runtime), PHP Layer by Stackery, and our own Thundra Java and Node.js Layers.
For Java and Node.js, we provide Layer support with both Custom Runtimes, and libraries, for both languages. The Java Custom Runtime improves the performance of your Java applications by reducing the cold start count and cold start duration. When you add our Thundra Java Layer, you have the option of choosing our Java Custom Runtime or AWS’s provided Java runtime for your Java Lambda function. Remember, that because you are deploying this Layer separately from the business logic of your application, your own Java function can occupy a minimal footprint.
For Node.js, our Custom Runtime included with our Node.js Layer allows you to add monitoring to your Node.js functions without needing to manually wrap your handler. You also have the option to use one of AWS’s Node.js runtimes. But, in this case, you will need to wrap your handler with Thundra manually in order to obtain monitoring data.
Now Announcing: The Thundra Python Layer
Today, we are happy to announce expanded support for Thundra Layers to a third layer, this time for Python. Python is known to be very easy to gather monitoring data from, which means there was no need for us to provide a special runtime to automate instrumentation.
Our brand new Python Layer comes with advanced tracing capabilities. Immediately after you add the Thundra Python Layer to your application, Thundra will automatically start tracing your functions. With our updated Python library included in new Python Layer, Thundra will, by default, collect detailed tracing data on the following operations:
AWS SDK Operations, which includes calls to:
HTTP calls, which enable you to trace third-party APIs like Stripe, Auth0, etc.
Relational database activities, including:
If you’d like to collect less data, you can disable any of those tracing capabilities by configuring annotations (see an example here). You can also add annotations on your functions to gather additional data for additional context (remember, full context includes data from all “three pillars” of observability!), including trace method arguments, return values, and errors. Note that even when gathering additional data, you don’t need to make changes to any of your business logic. All you need to do is configure your tracing by using the `@thundra` annotation.
Adding the Thundra Python Layer: A Walkthrough
Let’s walk through the steps of adding the Thundra Python Layer to your serverless application. You can configure Lambda Layers using AWS CLI, AWS SAM, Serverless Framework, or AWS Console. We will walk through the AWS Console way in our example. First, you will need to go to your AWS Lambda Function Page and click `Layers` in the Designers tab.
Then click `Add Layer` and add the Thundra Python Layer with the following ARN:
Note that the region part of the ARN is dynamic, so you need to change it according to the region where you deploy your function. In this example, let’s say that you deploy your Lambda function to Oregon (`us-west-2`) region. Therefore, the layer ARN will be:
Lastly, set the Thundra handler as your handler. Then, you need to first tell us your handler and enter your Thundra API key with an environment variable. Enter your environment variables as shown below:
You’re all set!
Thundra will automatically start to gather data from your functions without you needing to re-deploy your application. Simply push the button `Test` at the top-right of AWS Console, and you will be able to how your Python function is performing in the Thundra Web Console.
Want to see what your data might look like? Check out our interactive demo environment to see the data being gathered from our example Python function. You can also see the resulting trace chart as follows:
An Advanced Technology Partner of AWS, Thundra is dedicated to giving AWS Lambda users the ability to gather deeply insightful observability and monitoring with minimal effort.
We hope that Python developers using AWS Lambda find our Python agent capabilities and Python Lambda Layer easy to use and valuable. Thundra APM can be used no matter if you are early in development or monitoring your Python, functions in production. See Thundra APM's documentation for Python workloads.
Thundra is free to use and set up takes only a few minutes. Get your account and start using Thundra today.