SBN

Simplifying Microservices Debugging with Thundra Sidekick

4 minutes read


POSTED Apr, 2021

dot
IN
Debugging

Simplifying Microservices Debugging with Thundra Sidekick

Berkay Mollamustafaoglu

Written by Berkay Mollamustafaoglu

Co-founder and CEO @Thundra


 X

I’m one of the fortunate people who have witnessed the (r)evolution of software development and delivery throughout my career. From programs deployed in local racks to serverless running with the pay-as-you-go paradigm, we’ve seen a breakthrough in computing in a relatively short time.

I’ve been part of the modernization of Operations team members along with the emergence of the DevOps paradigm and “modern” applications. Due to these changes, applications are now much more distributed and increasingly built using services provided by cloud services (DynamoDB, SQS, etc.), other vendors (Twilio, Stripe, etc.), or other teams in the same organization. However, these changes introduced new challenges for developers and many new failures that can be hard to understand and resolve.

For years, the industry has been investing heavily in developing tooling to resolve issues in such complex applications. At my previous startup, OpsGenie, we focused on making the life of on-call folks a little easier. As we start our incident management journey with reactive alerting (and with limited data), we are still seeking to achieve the best level of observability tools that allow us to proactively ask questions about production issues and thus avoid them altogether when possible. However, there are two problems with these shiny new tools. First, there’s a learning curve, combined with the added pressure of learning a new paradigm and discovering how new tools work⁠—which isn’t ideal for developers who need to respond to issues quickly. Second, observability tools are too focused on post-production issues, which means they usually miss the pre-production phase where most incidents are rooted.

Introducing Thundra Sidekick

Throughout their journey with Thundra, the team has shared the insights they gathered from the market with me. Increasingly, the feedback from our customers and the overall market implied that they have limited visibility in pre-production. Due to this issue, we have seen a unique usage of different tools and various workarounds so developers could gain a sufficient level of visibility in pre-production, and hopefully resolve issues before they occur.

Some of our customers have used Thundra to understand failures in staging environments and/or CI pipelines. Others were suffering from incomplete visibility between several microservices since the only data they had available was via logs. Developers have been facing significant difficulty since they don’t have the ability to replicate remote environments on their local environment and, due to limited data, have not been able to resolve issues.

After I became Thundra’s CEO, I decided it was time to address the problems voiced by our users — and we’re starting with a solution that helps application teams debug their remote applications in a non-intrusive way. We have been tailoring our existing capabilities—automated instrumentation, distributed tracing, time-travel debugging, live debugging, etc. — to help developers cope with the overall visibility problems in remote environments, especially in pre-production.

We wanted to call our new product “Thundra Sidekick” since we believe that we are building an aide-de-camp for developers who deliver millions of lines of code every day. With our new product, we aim to be the “sidekick” of developer superheroes by helping them quickly and easily debug their code.

Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application. We introduced Thundra Sidekick as an IntelliJ IDEA Plugin last month and have received highly positive feedback. Today, we are thrilled to introduce the Thundra Sidekick web application, which can be used for any applications hosted remotely — no matter where they’re located.

Currently, the Thundra Sidekick web application lets developers debug Java, Kotlin, and Scala applications. Our Python support will be ready and available in the following weeks, and we are looking forward to meeting with Python communities to introduce this exciting new feature. The setup is pretty straightforward, and it takes less than five minutes to begin understanding and resolving complex issues with Thundra Sidekick.

Let’s take a look at how it works:

  • Instrument your applications

To gather information during execution, you need to install Thundra Sidekick to your application. You can follow the installation instructions here for Java, Scala, and Kotlin.

  • Import your source code

The next step is to bring your source code to Thundra Sidekick so that you can set tracepoints. Thundra Sidekick is integrated with GitHub to retrieve your code in any branch or any commit. When you provide access to your GitHub repository, we retrieve the code with read-only access and keep it in your client application; it’s never brought onto our servers, ensuring your privacy remains intact. More integrations with other source code management tools, such as GitLab and BitBucket, are on our roadmap to improving Thundra Sidekick.

  • Set tracepoints

For those of you unfamiliar with Thundra, we use the term “tracepoint” to refer to a non-breaking breakpoint integrated with Thundra’s distributed technology. We use the term “tracepoints” rather than “breakpoints” because we integrate them with our distributed tracing technology. To define conditions for tracepoints, developers can use variables to filter only necessary information while defining the tracepoint. For example, you can create a configuration to only take snapshots when a specific condition occurs.

  • Take the snapshot

When the code execution hits the tracepoint, Thundra Sidekick takes a snapshot of variables and the call stack. It’s as if the code pauses in the tracepoint — but it actually doesn’t. All valuable data is retrieved with negligible (less than 1ms) performance overhead. You can navigate to the distributed tracing of these tracepoints with just one click to see a holistic view of encapsulating transactions.

Wrapping Up

Remote debugging in distributed environments is a daunting process with many limitations and obstacles. We are very excited to enable application teams to debug their remote applications with an easy-to-install, zero-overhead solution by Thundra Sidekick. We plan to increase our debugging capabilities by supporting new runtimes such as Python, new IDEs such as VSCode, and new capabilities such as simulating hotfixes. Our existing Thundra users can use their credentials to start using Sidekick right away. If you have yet to take your first step into the world of Thundra, you can begin your journey here


×

SUBSCRIBE TO OUR BLOG

Get our new blogs delivered straight to your inbox.

 

THANKS FOR SIGNING UP!

We’ll make sure to share the best materials crafted for you!

4 minutes read


POSTED Apr, 2021

dot
IN
Debugging

Simplifying Microservices Debugging with Thundra Sidekick

Berkay Mollamustafaoglu

Written by Berkay Mollamustafaoglu

Co-founder and CEO @Thundra


 X

I’m one of the fortunate people who have witnessed the (r)evolution of software development and delivery throughout my career. From programs deployed in local racks to serverless running with the pay-as-you-go paradigm, we’ve seen a breakthrough in computing in a relatively short time.

I’ve been part of the modernization of Operations team members along with the emergence of the DevOps paradigm and “modern” applications. Due to these changes, applications are now much more distributed and increasingly built using services provided by cloud services (DynamoDB, SQS, etc.), other vendors (Twilio, Stripe, etc.), or other teams in the same organization. However, these changes introduced new challenges for developers and many new failures that can be hard to understand and resolve.

For years, the industry has been investing heavily in developing tooling to resolve issues in such complex applications. At my previous startup, OpsGenie, we focused on making the life of on-call folks a little easier. As we start our incident management journey with reactive alerting (and with limited data), we are still seeking to achieve the best level of observability tools that allow us to proactively ask questions about production issues and thus avoid them altogether when possible. However, there are two problems with these shiny new tools. First, there’s a learning curve, combined with the added pressure of learning a new paradigm and discovering how new tools work⁠—which isn’t ideal for developers who need to respond to issues quickly. Second, observability tools are too focused on post-production issues, which means they usually miss the pre-production phase where most incidents are rooted.

Introducing Thundra Sidekick

Throughout their journey with Thundra, the team has shared the insights they gathered from the market with me. Increasingly, the feedback from our customers and the overall market implied that they have limited visibility in pre-production. Due to this issue, we have seen a unique usage of different tools and various workarounds so developers could gain a sufficient level of visibility in pre-production, and hopefully resolve issues before they occur.

Some of our customers have used Thundra to understand failures in staging environments and/or CI pipelines. Others were suffering from incomplete visibility between several microservices since the only data they had available was via logs. Developers have been facing significant difficulty since they don’t have the ability to replicate remote environments on their local environment and, due to limited data, have not been able to resolve issues.

After I became Thundra’s CEO, I decided it was time to address the problems voiced by our users — and we’re starting with a solution that helps application teams debug their remote applications in a non-intrusive way. We have been tailoring our existing capabilities—automated instrumentation, distributed tracing, time-travel debugging, live debugging, etc. — to help developers cope with the overall visibility problems in remote environments, especially in pre-production.

We wanted to call our new product “Thundra Sidekick” since we believe that we are building an aide-de-camp for developers who deliver millions of lines of code every day. With our new product, we aim to be the “sidekick” of developer superheroes by helping them quickly and easily debug their code.

Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application. We introduced Thundra Sidekick as an IntelliJ IDEA Plugin last month and have received highly positive feedback. Today, we are thrilled to introduce the Thundra Sidekick web application, which can be used for any applications hosted remotely — no matter where they’re located.

Currently, the Thundra Sidekick web application lets developers debug Java, Kotlin, and Scala applications. Our Python support will be ready and available in the following weeks, and we are looking forward to meeting with Python communities to introduce this exciting new feature. The setup is pretty straightforward, and it takes less than five minutes to begin understanding and resolving complex issues with Thundra Sidekick.

Let’s take a look at how it works:

  • Instrument your applications

To gather information during execution, you need to install Thundra Sidekick to your application. You can follow the installation instructions here for Java, Scala, and Kotlin.

  • Import your source code

The next step is to bring your source code to Thundra Sidekick so that you can set tracepoints. Thundra Sidekick is integrated with GitHub to retrieve your code in any branch or any commit. When you provide access to your GitHub repository, we retrieve the code with read-only access and keep it in your client application; it’s never brought onto our servers, ensuring your privacy remains intact. More integrations with other source code management tools, such as GitLab and BitBucket, are on our roadmap to improving Thundra Sidekick.

  • Set tracepoints

For those of you unfamiliar with Thundra, we use the term “tracepoint” to refer to a non-breaking breakpoint integrated with Thundra’s distributed technology. We use the term “tracepoints” rather than “breakpoints” because we integrate them with our distributed tracing technology. To define conditions for tracepoints, developers can use variables to filter only necessary information while defining the tracepoint. For example, you can create a configuration to only take snapshots when a specific condition occurs.

  • Take the snapshot

When the code execution hits the tracepoint, Thundra Sidekick takes a snapshot of variables and the call stack. It’s as if the code pauses in the tracepoint — but it actually doesn’t. All valuable data is retrieved with negligible (less than 1ms) performance overhead. You can navigate to the distributed tracing of these tracepoints with just one click to see a holistic view of encapsulating transactions.

Wrapping Up

Remote debugging in distributed environments is a daunting process with many limitations and obstacles. We are very excited to enable application teams to debug their remote applications with an easy-to-install, zero-overhead solution by Thundra Sidekick. We plan to increase our debugging capabilities by supporting new runtimes such as Python, new IDEs such as VSCode, and new capabilities such as simulating hotfixes. Our existing Thundra users can use their credentials to start using Sidekick right away. If you have yet to take your first step into the world of Thundra, you can begin your journey here

I’m one of the fortunate people who have witnessed the (r)evolution of software development and delivery throughout my career. From programs deployed in local racks to serverless running with the pay-as-you-go paradigm, we’ve seen a breakthrough in computing in a relatively short time.

I’ve been part of the modernization of Operations team members along with the emergence of the DevOps paradigm and “modern” applications. Due to these changes, applications are now much more distributed and increasingly built using services provided by cloud services (DynamoDB, SQS, etc.), other vendors (Twilio, Stripe, etc.), or other teams in the same organization. However, these changes introduced new challenges for developers and many new failures that can be hard to understand and resolve.

For years, the industry has been investing heavily in developing tooling to resolve issues in such complex applications. At my previous startup, OpsGenie, we focused on making the life of on-call folks a little easier. As we start our incident management journey with reactive alerting (and with limited data), we are still seeking to achieve the best level of observability tools that allow us to proactively ask questions about production issues and thus avoid them altogether when possible. However, there are two problems with these shiny new tools. First, there’s a learning curve, combined with the added pressure of learning a new paradigm and discovering how new tools work⁠—which isn’t ideal for developers who need to respond to issues quickly. Second, observability tools are too focused on post-production issues, which means they usually miss the pre-production phase where most incidents are rooted.

Introducing Thundra Sidekick

Throughout their journey with Thundra, the team has shared the insights they gathered from the market with me. Increasingly, the feedback from our customers and the overall market implied that they have limited visibility in pre-production. Due to this issue, we have seen a unique usage of different tools and various workarounds so developers could gain a sufficient level of visibility in pre-production, and hopefully resolve issues before they occur.

Some of our customers have used Thundra to understand failures in staging environments and/or CI pipelines. Others were suffering from incomplete visibility between several microservices since the only data they had available was via logs. Developers have been facing significant difficulty since they don’t have the ability to replicate remote environments on their local environment and, due to limited data, have not been able to resolve issues.

After I became Thundra’s CEO, I decided it was time to address the problems voiced by our users — and we’re starting with a solution that helps application teams debug their remote applications in a non-intrusive way. We have been tailoring our existing capabilities—automated instrumentation, distributed tracing, time-travel debugging, live debugging, etc. — to help developers cope with the overall visibility problems in remote environments, especially in pre-production.

We wanted to call our new product “Thundra Sidekick” since we believe that we are building an aide-de-camp for developers who deliver millions of lines of code every day. With our new product, we aim to be the “sidekick” of developer superheroes by helping them quickly and easily debug their code.

Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application. We introduced Thundra Sidekick as an IntelliJ IDEA Plugin last month and have received highly positive feedback. Today, we are thrilled to introduce the Thundra Sidekick web application, which can be used for any applications hosted remotely — no matter where they’re located.

Currently, the Thundra Sidekick web application lets developers debug Java, Kotlin, and Scala applications. Our Python support will be ready and available in the following weeks, and we are looking forward to meeting with Python communities to introduce this exciting new feature. The setup is pretty straightforward, and it takes less than five minutes to begin understanding and resolving complex issues with Thundra Sidekick.

Let’s take a look at how it works:

  • Instrument your applications

To gather information during execution, you need to install Thundra Sidekick to your application. You can follow the installation instructions here for Java, Scala, and Kotlin.

  • Import your source code

The next step is to bring your source code to Thundra Sidekick so that you can set tracepoints. Thundra Sidekick is integrated with GitHub to retrieve your code in any branch or any commit. When you provide access to your GitHub repository, we retrieve the code with read-only access and keep it in your client application; it’s never brought onto our servers, ensuring your privacy remains intact. More integrations with other source code management tools, such as GitLab and BitBucket, are on our roadmap to improving Thundra Sidekick.

  • Set tracepoints

For those of you unfamiliar with Thundra, we use the term “tracepoint” to refer to a non-breaking breakpoint integrated with Thundra’s distributed technology. We use the term “tracepoints” rather than “breakpoints” because we integrate them with our distributed tracing technology. To define conditions for tracepoints, developers can use variables to filter only necessary information while defining the tracepoint. For example, you can create a configuration to only take snapshots when a specific condition occurs.

  • Take the snapshot

When the code execution hits the tracepoint, Thundra Sidekick takes a snapshot of variables and the call stack. It’s as if the code pauses in the tracepoint — but it actually doesn’t. All valuable data is retrieved with negligible (less than 1ms) performance overhead. You can navigate to the distributed tracing of these tracepoints with just one click to see a holistic view of encapsulating transactions.

Wrapping Up

Remote debugging in distributed environments is a daunting process with many limitations and obstacles. We are very excited to enable application teams to debug their remote applications with an easy-to-install, zero-overhead solution by Thundra Sidekick. We plan to increase our debugging capabilities by supporting new runtimes such as Python, new IDEs such as VSCode, and new capabilities such as simulating hotfixes. Our existing Thundra users can use their credentials to start using Sidekick right away. If you have yet to take your first step into the world of Thundra, you can begin your journey here

I’m one of the fortunate people who have witnessed the (r)evolution of software development and delivery throughout my career. From programs deployed in local racks to serverless running with the pay-as-you-go paradigm, we’ve seen a breakthrough in computing in a relatively short time.

I’ve been part of the modernization of Operations team members along with the emergence of the DevOps paradigm and “modern” applications. Due to these changes, applications are now much more distributed and increasingly built using services provided by cloud services (DynamoDB, SQS, etc.), other vendors (Twilio, Stripe, etc.), or other teams in the same organization. However, these changes introduced new challenges for developers and many new failures that can be hard to understand and resolve.

For years, the industry has been investing heavily in developing tooling to resolve issues in such complex applications. At my previous startup, OpsGenie, we focused on making the life of on-call folks a little easier. As we start our incident management journey with reactive alerting (and with limited data), we are still seeking to achieve the best level of observability tools that allow us to proactively ask questions about production issues and thus avoid them altogether when possible. However, there are two problems with these shiny new tools. First, there’s a learning curve, combined with the added pressure of learning a new paradigm and discovering how new tools work⁠—which isn’t ideal for developers who need to respond to issues quickly. Second, observability tools are too focused on post-production issues, which means they usually miss the pre-production phase where most incidents are rooted.

Introducing Thundra Sidekick

Throughout their journey with Thundra, the team has shared the insights they gathered from the market with me. Increasingly, the feedback from our customers and the overall market implied that they have limited visibility in pre-production. Due to this issue, we have seen a unique usage of different tools and various workarounds so developers could gain a sufficient level of visibility in pre-production, and hopefully resolve issues before they occur.

Some of our customers have used Thundra to understand failures in staging environments and/or CI pipelines. Others were suffering from incomplete visibility between several microservices since the only data they had available was via logs. Developers have been facing significant difficulty since they don’t have the ability to replicate remote environments on their local environment and, due to limited data, have not been able to resolve issues.

After I became Thundra’s CEO, I decided it was time to address the problems voiced by our users — and we’re starting with a solution that helps application teams debug their remote applications in a non-intrusive way. We have been tailoring our existing capabilities—automated instrumentation, distributed tracing, time-travel debugging, live debugging, etc. — to help developers cope with the overall visibility problems in remote environments, especially in pre-production.

We wanted to call our new product “Thundra Sidekick” since we believe that we are building an aide-de-camp for developers who deliver millions of lines of code every day. With our new product, we aim to be the “sidekick” of developer superheroes by helping them quickly and easily debug their code.

Thundra Sidekick is a remote debugger that lets you debug your distributed applications with snapshots taken during invocation rather than with intrusive breakpoints that pause your application. We introduced Thundra Sidekick as an IntelliJ IDEA Plugin last month and have received highly positive feedback. Today, we are thrilled to introduce the Thundra Sidekick web application, which can be used for any applications hosted remotely — no matter where they’re located.

Currently, the Thundra Sidekick web application lets developers debug Java, Kotlin, and Scala applications. Our Python support will be ready and available in the following weeks, and we are looking forward to meeting with Python communities to introduce this exciting new feature. The setup is pretty straightforward, and it takes less than five minutes to begin understanding and resolving complex issues with Thundra Sidekick.

Let’s take a look at how it works:

  • Instrument your applications

To gather information during execution, you need to install Thundra Sidekick to your application. You can follow the installation instructions here for Java, Scala, and Kotlin.

  • Import your source code

The next step is to bring your source code to Thundra Sidekick so that you can set tracepoints. Thundra Sidekick is integrated with GitHub to retrieve your code in any branch or any commit. When you provide access to your GitHub repository, we retrieve the code with read-only access and keep it in your client application; it’s never brought onto our servers, ensuring your privacy remains intact. More integrations with other source code management tools, such as GitLab and BitBucket, are on our roadmap to improving Thundra Sidekick.

  • Set tracepoints

For those of you unfamiliar with Thundra, we use the term “tracepoint” to refer to a non-breaking breakpoint integrated with Thundra’s distributed technology. We use the term “tracepoints” rather than “breakpoints” because we integrate them with our distributed tracing technology. To define conditions for tracepoints, developers can use variables to filter only necessary information while defining the tracepoint. For example, you can create a configuration to only take snapshots when a specific condition occurs.

  • Take the snapshot

When the code execution hits the tracepoint, Thundra Sidekick takes a snapshot of variables and the call stack. It’s as if the code pauses in the tracepoint — but it actually doesn’t. All valuable data is retrieved with negligible (less than 1ms) performance overhead. You can navigate to the distributed tracing of these tracepoints with just one click to see a holistic view of encapsulating transactions.

Wrapping Up

Remote debugging in distributed environments is a daunting process with many limitations and obstacles. We are very excited to enable application teams to debug their remote applications with an easy-to-install, zero-overhead solution by Thundra Sidekick. We plan to increase our debugging capabilities by supporting new runtimes such as Python, new IDEs such as VSCode, and new capabilities such as simulating hotfixes. Our existing Thundra users can use their credentials to start using Sidekick right away. If you have yet to take your first step into the world of Thundra, you can begin your journey here

*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Berkay Mollamustafaoglu. Read the original post at: https://blog.thundra.io/simplifying-microservices-debugging-with-thundra-sidekick