Serverless eased the job of delivering software faster but the developers lost the ability to debug applications as they could do for monolithic applications. The comfort of debugging monolithic applications is behind and serverless developers left only with the logs that provide a limited post-debugging experience. You can debug your serverless application if you’re prepared enough for logging the required information. Most of the time, developers forget to put a sufficient amount of log statements and stay clueless about understanding the application behavior.
There are some efforts making the local debugging of serverless computing possible but serverless apps can’t be considered solely from compute resources perspective. There are also many other managed services such as DynamoDB, S3, Kinesis that are either not possible to install or simulate in the local environment. There are some solutions to addressing this problem that simulates the cloud compute environment in the computer of the developer. For example;
sam local invoke locally invokes the function using the local credentials to reach the cloud resources. Localstack is another tool that sets up the AWS components in the local of the developer and mocking the data coming in and out of the resources.
All of these lack either one of these below:
- Production behavior of the AWS Lambda functions in terms of security
- The authenticity of the event data flowing between resources
The cure to these problems is actually just going back to roots. The serverless community needs the invent the wheel again, and get their native debugging experience back as they could do in monolithic applications. We stepped forward for this cause and proudly introducing the most native debugging experience ever. With this solution, you will be able to debug AWS Lambda functions as they run in their native cloud environment. You can track all the changes in local variables, update them on the fly and see the effect as you could do while debugging non-serverless apps.
How does it work?
When we are debugging applications whose code is hosted on our PC, applications run in listen mode and wait for debugging process to attach itself into the normal execution of the code. However, this method cannot be applied to the AWS Lambda environment directly because incoming requests are not allowed to the AWS Lambda environment. Moreover, Lambda applications can share the same IP address or have multiple IP addresses at a given time as they are managed dynamically by AWS. This is another reason that makes it impossible to have a direct connection with the AWS environment from an IDE. Classical debugging is not applicable. Inspired by the previous efforts on this topic, we invented a new secure way of debugging AWS Lambda applications as they run on the AWS cloud.
To overcome these challenges and make debugging possible on the AWS Lambda environment, Thundra provides a proxy-based solution that sets up a secure bridge between AWS Lambda environment and your debugger on IDE with web socket communication. In this way, you can debug your applications like you could debug any code that you host on your computer with native debug action. We are calling this bridge as “broker” which is basically a proxy for the communication between your AWS Lambda function and your IDE.
The overall architecture looks like this:
Setting up Thundra debugger is pretty straightforward. We provide plugins for the most popular IDEs like VSCode and IntelliJ IDEA to give you traditional debugging experience even on AWS Lambda platform. Here is an example flow of debugging a Node.js Lambda function:
- Get your authentication token from Thundra console (Two possible ways)
- You can do this while you’re signing up to Thundra.
- Or from the “Settings” page later (for ex. if you are already a Thundra user)
- Add Thundra Node.js agent (as NPM dependency or Lambda layer) and set your debugging authentication token through environment variables:
- Install Thundra VS Code plugin from the Microsoft Visual Studio Marketplace: https://marketplace.visualstudio.com/items?itemName=thundra.thundra-debugger
- And enjoy live debugging by putting your breakpoints:
What should you do to start this experience?
In order to start the online debugging experience, you need to get an authentication key by navigating to the “Debugger” page under the settings page.
Then, you need to plug Thundra libraries to your Lambda functions for Node.js, Python, and Java. We have native debugging integration with Microsoft VSCode and IntelliJ IDEA. You can still use Thundra debugger with other IDEs using Thundra client.
You need to update your Thundra libraries to the newer versions as follows:
- Node.js: 2.9.1, layer 42 or higher
- Python: 2.4.5, layer 20 or higher.
- Java: 2.5.2, layer 42 or higher.
Debugging serverless applications has been the biggest concern for the companies at every scale. Today, we are happy to unlock the ability to debug AWS Lambda functions with ease. This perfectly matches our vision of enabling any application team to achieve with serverless. Our debugging solution comes as free for everyone. In the following days, we are planning to come up with a broker version that can be installed at your own AWS account. This will keep all the debugging data traveling between your AWS account and your IDE without coming to our servers.You can start your native debugging experience by signing up for Thundra for free directly or from AWS Marketplace. Start following us on Twitter to catch up with our latest announcements.