IN
Serverless applications are the epitome of event-driven software in which tiny functions communicate between each other asynchronously to run a business flow. Event-driven architectures enabled developers to code and ship tiny slices of software with no impact on the rest of the system. It doesn’t take too long to have the headache of troubleshooting such distributed applications because the business logic is spread through many small functions. Application teams needed a different taste of monitoring to track all the async messages traveling between functions. Old school monitoring of the metrics and logs doesn’t help with such distributed systems. We need more high cardinality data in a chronological order showing the behavior of the async architecture. Distributed tracing came to rescue to address this pain of understanding the behavior of modern applications and maintain health.
During my interviews with many Thundra customers and prospects, I came across many different usages of event-driven architectures. My conclusion is that not everyone has this well-distributed architecture in which functions do nearly atomic jobs. Instead, most teams have big Lambda functions that perform multiple tasks and ingest the resulting records to a database. For the sake of better event-driven architectures, such architectures should be composed of smaller functions but not every team is lucky enough with sufficient time for this, especially while migrating to serverless.
For such kind of architectures, distributed tracing can stay short because all the business logic still occurs * in * the function instead of between functions. When anything goes wrong in big Lambda functions, developers are left alone with only the logs. The bad news is that there should be a structured logging mechanism carefully placed in the application to use the logs efficiently in such cases. This requires a ton of manual work and still pollutes the code. A developer can only wish to debug these applications with an IDE-like experience in this doomed situation. In this way, she can walk through the business logic to see what goes unexpected after the code is executed. To address this need, Thundra introduced a new way of debugging serverless functions after they finish the execution with recent offline debugging.
How does it work?
Offline debugging can work in AWS Lambda functions in Node.js, Python and Java runtimes. Enabling offline debugging is pretty easy with no code change. You can understand how your Lambda functions do at each line by setting the environment variable called thundra_agent_lambda_trace_instrument_traceableConfig to the package you want to trace and add [traceLineByLine=true] at the end. The example usage below shows how you can enable the offline debugging for all the methods under a directory named service.
thundra_agent_lambda_trace_instrument_traceableConfig: src/user/service.*[traceLineByLine=true]
After enabling this feature, you can just walk-over the lines of your application. You can see the methods for which the offline debugging is the small bug icon most left of the span line:
Clicking one of these will start an offline debugging experience. Let’s have a closer look at the magic that you want to see with this blog post.
As you can see, Thundra provides an IDE-like view that lets you navigate through the application and see the changes in the local variables. With this view, the black-box nature of the AWS Lambda functions becomes a history. Thundra lets you uncover all the hidden logic happening under the hood!
In order to use our Offline Debugging feature, you'll need to update your Thundra libraries to the newer versions as follow:
- Node.js: 2.8.0, layer 36 or higher
- Python: 2.4.4, layer 19 or higher.
- Java: 2.4.9, layer 39 or higher.
Summary
Serverless applications provide the power of distributed event-driven architectures to the application teams. However, not every team can build such a distributed architecture in which an atomic job is done at each and every function. For the functions that have complicated business logic inside, Thundra provides an unmatched way of debugging the applications with this update. Now, you can see what exactly happened in an AWS Lambda function after its execution is finished.
We offer various debugging solutions for the serverless community with our products. With Thundra's AWS Lambda Debugger, you are able to debug your AWS Lambda functions *during* the execution on your IDE.
The VSCode plugin enables NodeJS and Python users and IntelliJ IDEA plugin enables Java users to debug their Lambda's on the go!
If you haven't started your Thundra adventure yet, you can start from here! Please reach out to us via support@thundra.io or on Twitter.
