When we first started Thundra three years ago, our intention was to help the serverless community with monitoring. Serverless had and still has its unique challenges and we enjoyed overcoming them by providing very lightweight agents that add negligible overhead to the function execution. Throughout the time we spent, we developed line-by-line time travel debugging, distributed tracing, live debugging, and more. Every technology we have worked on enabled developers to troubleshoot the issues in serverless environments, and later on, non-serverless microservices as well. Our talks with our customers and the community revealed that troubleshooting production issues were just the tip of the iceberg of developers’ pains.
The pain of developer in modern applications
In today's era, applications are increasingly built using services provided by others, cloud services (DynamoDB, SQS, etc.), services provided by other vendors (Twilio, Stripe, etc.), and services provided by other teams in the same organization. While the complexity of the applications increases, developers are expected to manage that complexity before and after the application is pushed to production. Although there are best practices and multiple tools for managing the complexity and resolving the issues after the code is in production, pre-production complexity for modern applications is, unfortunately, underserved.
Developers are accustomed to developing on their personal computers/local environments and mock the 3rd parties and cloud dependencies. On the downside, it’s hard to create development environments that mimic production environments closely when developing distributed microservices and cloud apps. For this reason, application teams adopt remote development in companies like Slack. In this case, however, debugging applications in remote environments becomes painful, as you can’t set breakpoints to remote applications as you would do in your local environment. The lack of tooling around debugging for remote development on distributed environments made us realize that we can actually solve this issue with our technology on debugging and distributed tracing. The decision we were about to make was how to modify our technology to best fit the pre-production needs of developers working on microservices.
Crossing the Rubicon: Thundra Sidekick
We, as developers of Thundra, believe that developers are superheroes delivering fast, reliable, robust applications in many industries for the good of all. With our new product, we will be the sidekick of superheroes while helping them debug their code a lot easier. That’s why our new product is appropriately named Thundra Sidekick.
Thundra Sidekick is a remote debugger that lets you debug your distributed applications from your IDE. Thundra Sidekick makes the start with IntelliJ IDEA with our free, forever free plugin. Thundra Sidekick removes the debugging burdens and enables developers to put tracepoints to the code which don’t break the execution but take snapshots. Then takes it to the next level by displaying the distributed trace. In the very near future, developers will be able to make hotfixes and reload without having to redeploy.
Thundra Sidekick is helpful when developers work on remote environments and debug their code while they build. Troubleshooting issues before production is always better as it keeps the stress of production issues away. The first version of Thundra Sidekick works for Java runtime and on IntelliJ IDE. The setup requires the installation of our SDK to your application and the installation of our IntelliJ IDEA Plugin.
Let’s take a look at how it works:
- Set tracepoints
Tracepoint is a non-breaking breakpoint integrated with Thundra's distributed technology. We call it tracepoints instead of breakpoints as we integrate them with our distributed tracing technology. Developers can define conditions for tracepoints using the variables around tracepoints and filter the only necessary information while defining the tracepoint. For example; you can configure it to take snapshots only when a specific condition occurs.
- Take the snapshot
When the code execution hits the tracepoint, Thundra Sidekick takes a snapshot of the variables and the call stack. It’s like the code pauses in the breakpoint but it actually doesn't. All valuable data is retrieved with negligible(less than 1ms) performance overhead.
- Connect Dots with distributed tracing
Thundra Sidekick connects the several tracepoints in the same distributed transaction. Developers can navigate between the snapshots of the same transaction and achieve end-to-end visibility for debugging.
- Fix & Reload
This comes with a “Coming Soon” tag. Thundra Sidekick will allow developers to reload the code in remote environments without re-deploying the application. We already saved lots of hours with this and very excited about how it could help other developers.
In this video, we are debugging the Pet Clinic App by Spring to demonstrate Thundra Sidekick’s capabilities.
2021 and Thundra Sidekick
It’s good to start the new year with a new product launch that will help developers - a.k.a. Superheroes.
Our roadmap looks great with new features for Thundra Sidekick including fast reloads without redeploying, more IDE support, and the debugger on the web for those who don’t use any IDE that we support.
To note, our existing product will be called Thundra APM, we’ll continue to support developers to solve post-production issues with it.
We’ll use our experience and technology gained by Thundra APM to make Thundra Sidekick the perfect partner/sidekick!
You can signup for Thundra Sidekick’s public beta v1 from here.