A Fast Way to Debug Remote Applications
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
A Fast Way to Debug Remote Applications
Written by Ismail Egilmez
Business Development Manager @Thundra
Today’s applications are more distributed, and today’s world is more remote, than ever. But developers just don’t have the same freedom and comfort that they’ve become accustomed to when developing in remote environments. One of the biggest challenges of remote environments is having the ability to debug applications. Let’s talk about why the classical methods of debugging applications in their remote environments no longer work well, and investigate what could be a revolutionary solution.
The Current State
Applications are becoming distributed and event-driven rather than monolithic, and organizations are adopting methodologies such as DevOps and Agile. As a natural result, developers are increasingly responsible to do more than just focus on coding. Developers’ responsibilities have grown so much that the lines between development, operations, security, and quality assurance have begun to fade away. Today, developers are not only responsible for delivering code—they also own the applications they build, from the “cradle to the grave.” This is called YBIYRI. Developers write their own tests for the code pieces they own, operate the services and applications, and take responsibility for security requirements of the applications they build.
The reactive Ops teams have fallen behind the current times. The always-on culture requires keeping the status page as green as possible, and maintaining SLA’s with as many 9’s as possible. Developers are now expected to own the issues that their customer-facing applications might have, both in production and pre-production.
Cloud vendors manage infrastructure and give freedom to applications teams to use many options as a service. Since the traditional lift-and-shift approach doesn’t perform well in today’s era, applications are moving to the cloud in a different shape than they used to. There is a huge shift emerging from monolith to microservices; modern cloud applications are made of tiny pieces of compute and non-compute resources. They are distributed and interact with each other using asynchronous communication methods, such as queues, pub-subs, event streams, and so on.
Unique Challenges of Application Debugging
As applications move to the cloud, their complexity is increasing. Even if you design the simplest system architecture, your application relies on services provided by other sources—cloud services (databases, queues, etc.), services provided by other vendors (Twilio, Stream, etc.), and even services provided by other teams in the same organization.
Needless to say, it’s crucial to determine the root cause of an issue ASAP when your customer-facing service is corrupted. You have to understand your application’s behavior in all cases. In other words, developers have to ensure that they use external services in a resilient way. When an issue arises in your application, the initial step of troubleshooting is to determine which component is causing the problem. Is it your code, or the result of some other service?
Developers need to not only to find where the problem is occurring, but also what the nature of the problem is to quickly enact a solution . The interactions among all the components might be the cause of reliability problems, not just bugs in the application.
Handicaps of Today’s Remote Debugging
Software teams work and collaborate on remote cloud environments, and generally, they are sick and tired of the current remote debugging solutions. The traditional remote debuggers run ad-hoc your application. They can enable you to explore the current state of the application, but only by looking at one breakpoint at a time. And, as the name implies, breakpoints stop the running service. The same issue occurs with local debugging, with the only change being a remote connection to your application hosted on the cloud.
Also, it’s very easy to create a hole in the security wall because most remote debuggers don’t have authorization or authentication schemes. On top of that, using remote debuggers is a very anti-collaborative, single-person process. Let’s say it’s your lucky day and you found the bug in your code: you still need to be patient enough to make the needed change, create a build, deploy it to the cloud, and verify the chance.
As you can see, there are some issues with using classical remote debuggers—which we’ve summarized below:
- Classical/old ways of debugging can’t cope with today’s need for speed, with the core reason being the lack of customers’ patience and the difficulty of leaving. When you have a single red dot on your status page, you run the risk of losing several customers as a result.
- Good-old remote debugging stops your application’s execution! Even in pre-production, this is serious because you may be blocking one of your colleagues from performing their own tasks.
- You can create security holes in your systems while using classical remote debuggers. A TCP port is used to establish the connection between the client tool, such as an IDE, and the agent of the remote debugger. Additionally, most of them don’t have authorization or authentication schemes.
Developers’ Best Friend: Sidekick
It’s surprisingly fast to debug applications, wherever they’re hosted, with Thundra Sidekick. When we say “anywhere,” we literally mean anywhere; your applications can live on containers, virtual machines, any kind of cloud environment, at the servers in your office building, or even in your homelab! All you have to do is instrument your applications with Thundra’s agents and add Thundra SDK to your application.
Thundra Sidekick eases the pain of debugging and enables developers to put breakpoints to the application code, which won’t break execution but take snapshots of activity instead. The snapshots of the same distributed trace events are correlated and visually displayed to help developers understand not only where the problem is, but also what the problem is. You can see how Thundra Sidekick works in this short video.
Debugging code is about fixing issues, but the typical cycle to fix an issue in cloud applications is a lot different than doing so in a local environment. It consists of several steps, such as creating a new build, deploying it to the cloud, and verifying the accuracy of the fix that has been instigated. This can be a very time-consuming and daunting process. Thundra Sidekick lets developers reload small code changes (null checks, wrong logical operators/comparisons, etc.) without re-deploying them. In this way, developers can gain time and productivity. Sign up with Thundra Sidekick and start debugging your remote applications faster than ever. It’s forever free!
SHARE
×
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
A Fast Way to Debug Remote Applications
Written by Ismail Egilmez
Business Development Manager @Thundra
Today’s applications are more distributed, and today’s world is more remote, than ever. But developers just don’t have the same freedom and comfort that they’ve become accustomed to when developing in remote environments. One of the biggest challenges of remote environments is having the ability to debug applications. Let’s talk about why the classical methods of debugging applications in their remote environments no longer work well, and investigate what could be a revolutionary solution.
The Current State
Applications are becoming distributed and event-driven rather than monolithic, and organizations are adopting methodologies such as DevOps and Agile. As a natural result, developers are increasingly responsible to do more than just focus on coding. Developers’ responsibilities have grown so much that the lines between development, operations, security, and quality assurance have begun to fade away. Today, developers are not only responsible for delivering code—they also own the applications they build, from the “cradle to the grave.” This is called YBIYRI. Developers write their own tests for the code pieces they own, operate the services and applications, and take responsibility for security requirements of the applications they build.
The reactive Ops teams have fallen behind the current times. The always-on culture requires keeping the status page as green as possible, and maintaining SLA’s with as many 9’s as possible. Developers are now expected to own the issues that their customer-facing applications might have, both in production and pre-production.
Cloud vendors manage infrastructure and give freedom to applications teams to use many options as a service. Since the traditional lift-and-shift approach doesn’t perform well in today’s era, applications are moving to the cloud in a different shape than they used to. There is a huge shift emerging from monolith to microservices; modern cloud applications are made of tiny pieces of compute and non-compute resources. They are distributed and interact with each other using asynchronous communication methods, such as queues, pub-subs, event streams, and so on.
Unique Challenges of Application Debugging
As applications move to the cloud, their complexity is increasing. Even if you design the simplest system architecture, your application relies on services provided by other sources—cloud services (databases, queues, etc.), services provided by other vendors (Twilio, Stream, etc.), and even services provided by other teams in the same organization.
Needless to say, it’s crucial to determine the root cause of an issue ASAP when your customer-facing service is corrupted. You have to understand your application’s behavior in all cases. In other words, developers have to ensure that they use external services in a resilient way. When an issue arises in your application, the initial step of troubleshooting is to determine which component is causing the problem. Is it your code, or the result of some other service?
Developers need to not only to find where the problem is occurring, but also what the nature of the problem is to quickly enact a solution . The interactions among all the components might be the cause of reliability problems, not just bugs in the application.
Handicaps of Today’s Remote Debugging
Software teams work and collaborate on remote cloud environments, and generally, they are sick and tired of the current remote debugging solutions. The traditional remote debuggers run ad-hoc your application. They can enable you to explore the current state of the application, but only by looking at one breakpoint at a time. And, as the name implies, breakpoints stop the running service. The same issue occurs with local debugging, with the only change being a remote connection to your application hosted on the cloud.
Also, it’s very easy to create a hole in the security wall because most remote debuggers don’t have authorization or authentication schemes. On top of that, using remote debuggers is a very anti-collaborative, single-person process. Let’s say it’s your lucky day and you found the bug in your code: you still need to be patient enough to make the needed change, create a build, deploy it to the cloud, and verify the chance.
As you can see, there are some issues with using classical remote debuggers—which we’ve summarized below:
- Classical/old ways of debugging can’t cope with today’s need for speed, with the core reason being the lack of customers’ patience and the difficulty of leaving. When you have a single red dot on your status page, you run the risk of losing several customers as a result.
- Good-old remote debugging stops your application’s execution! Even in pre-production, this is serious because you may be blocking one of your colleagues from performing their own tasks.
- You can create security holes in your systems while using classical remote debuggers. A TCP port is used to establish the connection between the client tool, such as an IDE, and the agent of the remote debugger. Additionally, most of them don’t have authorization or authentication schemes.
Developers’ Best Friend: Sidekick
It’s surprisingly fast to debug applications, wherever they’re hosted, with Thundra Sidekick. When we say “anywhere,” we literally mean anywhere; your applications can live on containers, virtual machines, any kind of cloud environment, at the servers in your office building, or even in your homelab! All you have to do is instrument your applications with Thundra’s agents and add Thundra SDK to your application.
Thundra Sidekick eases the pain of debugging and enables developers to put breakpoints to the application code, which won’t break execution but take snapshots of activity instead. The snapshots of the same distributed trace events are correlated and visually displayed to help developers understand not only where the problem is, but also what the problem is. You can see how Thundra Sidekick works in this short video.
Debugging code is about fixing issues, but the typical cycle to fix an issue in cloud applications is a lot different than doing so in a local environment. It consists of several steps, such as creating a new build, deploying it to the cloud, and verifying the accuracy of the fix that has been instigated. This can be a very time-consuming and daunting process. Thundra Sidekick lets developers reload small code changes (null checks, wrong logical operators/comparisons, etc.) without re-deploying them. In this way, developers can gain time and productivity. Sign up with Thundra Sidekick and start debugging your remote applications faster than ever. It’s forever free!
SHARE
Today’s applications are more distributed, and today’s world is more remote, than ever. But developers just don’t have the same freedom and comfort that they’ve become accustomed to when developing in remote environments. One of the biggest challenges of remote environments is having the ability to debug applications. Let’s talk about why the classical methods of debugging applications in their remote environments no longer work well, and investigate what could be a revolutionary solution.
The Current State
Applications are becoming distributed and event-driven rather than monolithic, and organizations are adopting methodologies such as DevOps and Agile. As a natural result, developers are increasingly responsible to do more than just focus on coding. Developers’ responsibilities have grown so much that the lines between development, operations, security, and quality assurance have begun to fade away. Today, developers are not only responsible for delivering code—they also own the applications they build, from the “cradle to the grave.” This is called YBIYRI. Developers write their own tests for the code pieces they own, operate the services and applications, and take responsibility for security requirements of the applications they build.
The reactive Ops teams have fallen behind the current times. The always-on culture requires keeping the status page as green as possible, and maintaining SLA’s with as many 9’s as possible. Developers are now expected to own the issues that their customer-facing applications might have, both in production and pre-production.
Cloud vendors manage infrastructure and give freedom to applications teams to use many options as a service. Since the traditional lift-and-shift approach doesn’t perform well in today’s era, applications are moving to the cloud in a different shape than they used to. There is a huge shift emerging from monolith to microservices; modern cloud applications are made of tiny pieces of compute and non-compute resources. They are distributed and interact with each other using asynchronous communication methods, such as queues, pub-subs, event streams, and so on.
Unique Challenges of Application Debugging
As applications move to the cloud, their complexity is increasing. Even if you design the simplest system architecture, your application relies on services provided by other sources—cloud services (databases, queues, etc.), services provided by other vendors (Twilio, Stream, etc.), and even services provided by other teams in the same organization.
Needless to say, it’s crucial to determine the root cause of an issue ASAP when your customer-facing service is corrupted. You have to understand your application’s behavior in all cases. In other words, developers have to ensure that they use external services in a resilient way. When an issue arises in your application, the initial step of troubleshooting is to determine which component is causing the problem. Is it your code, or the result of some other service?
Developers need to not only to find where the problem is occurring, but also what the nature of the problem is to quickly enact a solution . The interactions among all the components might be the cause of reliability problems, not just bugs in the application.
Handicaps of Today’s Remote Debugging
Software teams work and collaborate on remote cloud environments, and generally, they are sick and tired of the current remote debugging solutions. The traditional remote debuggers run ad-hoc your application. They can enable you to explore the current state of the application, but only by looking at one breakpoint at a time. And, as the name implies, breakpoints stop the running service. The same issue occurs with local debugging, with the only change being a remote connection to your application hosted on the cloud.
Also, it’s very easy to create a hole in the security wall because most remote debuggers don’t have authorization or authentication schemes. On top of that, using remote debuggers is a very anti-collaborative, single-person process. Let’s say it’s your lucky day and you found the bug in your code: you still need to be patient enough to make the needed change, create a build, deploy it to the cloud, and verify the chance.
As you can see, there are some issues with using classical remote debuggers—which we’ve summarized below:
- Classical/old ways of debugging can’t cope with today’s need for speed, with the core reason being the lack of customers’ patience and the difficulty of leaving. When you have a single red dot on your status page, you run the risk of losing several customers as a result.
- Good-old remote debugging stops your application’s execution! Even in pre-production, this is serious because you may be blocking one of your colleagues from performing their own tasks.
- You can create security holes in your systems while using classical remote debuggers. A TCP port is used to establish the connection between the client tool, such as an IDE, and the agent of the remote debugger. Additionally, most of them don’t have authorization or authentication schemes.
Developers’ Best Friend: Sidekick
It’s surprisingly fast to debug applications, wherever they’re hosted, with Thundra Sidekick. When we say “anywhere,” we literally mean anywhere; your applications can live on containers, virtual machines, any kind of cloud environment, at the servers in your office building, or even in your homelab! All you have to do is instrument your applications with Thundra’s agents and add Thundra SDK to your application.
Thundra Sidekick eases the pain of debugging and enables developers to put breakpoints to the application code, which won’t break execution but take snapshots of activity instead. The snapshots of the same distributed trace events are correlated and visually displayed to help developers understand not only where the problem is, but also what the problem is. You can see how Thundra Sidekick works in this short video.
Debugging code is about fixing issues, but the typical cycle to fix an issue in cloud applications is a lot different than doing so in a local environment. It consists of several steps, such as creating a new build, deploying it to the cloud, and verifying the accuracy of the fix that has been instigated. This can be a very time-consuming and daunting process. Thundra Sidekick lets developers reload small code changes (null checks, wrong logical operators/comparisons, etc.) without re-deploying them. In this way, developers can gain time and productivity. Sign up with Thundra Sidekick and start debugging your remote applications faster than ever. It’s forever free!
Today’s applications are more distributed, and today’s world is more remote, than ever. But developers just don’t have the same freedom and comfort that they’ve become accustomed to when developing in remote environments. One of the biggest challenges of remote environments is having the ability to debug applications. Let’s talk about why the classical methods of debugging applications in their remote environments no longer work well, and investigate what could be a revolutionary solution.
The Current State
Applications are becoming distributed and event-driven rather than monolithic, and organizations are adopting methodologies such as DevOps and Agile. As a natural result, developers are increasingly responsible to do more than just focus on coding. Developers’ responsibilities have grown so much that the lines between development, operations, security, and quality assurance have begun to fade away. Today, developers are not only responsible for delivering code—they also own the applications they build, from the “cradle to the grave.” This is called YBIYRI. Developers write their own tests for the code pieces they own, operate the services and applications, and take responsibility for security requirements of the applications they build.
The reactive Ops teams have fallen behind the current times. The always-on culture requires keeping the status page as green as possible, and maintaining SLA’s with as many 9’s as possible. Developers are now expected to own the issues that their customer-facing applications might have, both in production and pre-production.
Cloud vendors manage infrastructure and give freedom to applications teams to use many options as a service. Since the traditional lift-and-shift approach doesn’t perform well in today’s era, applications are moving to the cloud in a different shape than they used to. There is a huge shift emerging from monolith to microservices; modern cloud applications are made of tiny pieces of compute and non-compute resources. They are distributed and interact with each other using asynchronous communication methods, such as queues, pub-subs, event streams, and so on.
Unique Challenges of Application Debugging
As applications move to the cloud, their complexity is increasing. Even if you design the simplest system architecture, your application relies on services provided by other sources—cloud services (databases, queues, etc.), services provided by other vendors (Twilio, Stream, etc.), and even services provided by other teams in the same organization.
Needless to say, it’s crucial to determine the root cause of an issue ASAP when your customer-facing service is corrupted. You have to understand your application’s behavior in all cases. In other words, developers have to ensure that they use external services in a resilient way. When an issue arises in your application, the initial step of troubleshooting is to determine which component is causing the problem. Is it your code, or the result of some other service?
Developers need to not only to find where the problem is occurring, but also what the nature of the problem is to quickly enact a solution . The interactions among all the components might be the cause of reliability problems, not just bugs in the application.
Handicaps of Today’s Remote Debugging
Software teams work and collaborate on remote cloud environments, and generally, they are sick and tired of the current remote debugging solutions. The traditional remote debuggers run ad-hoc your application. They can enable you to explore the current state of the application, but only by looking at one breakpoint at a time. And, as the name implies, breakpoints stop the running service. The same issue occurs with local debugging, with the only change being a remote connection to your application hosted on the cloud.
Also, it’s very easy to create a hole in the security wall because most remote debuggers don’t have authorization or authentication schemes. On top of that, using remote debuggers is a very anti-collaborative, single-person process. Let’s say it’s your lucky day and you found the bug in your code: you still need to be patient enough to make the needed change, create a build, deploy it to the cloud, and verify the chance.
As you can see, there are some issues with using classical remote debuggers—which we’ve summarized below:
- Classical/old ways of debugging can’t cope with today’s need for speed, with the core reason being the lack of customers’ patience and the difficulty of leaving. When you have a single red dot on your status page, you run the risk of losing several customers as a result.
- Good-old remote debugging stops your application’s execution! Even in pre-production, this is serious because you may be blocking one of your colleagues from performing their own tasks.
- You can create security holes in your systems while using classical remote debuggers. A TCP port is used to establish the connection between the client tool, such as an IDE, and the agent of the remote debugger. Additionally, most of them don’t have authorization or authentication schemes.
Developers’ Best Friend: Sidekick
It’s surprisingly fast to debug applications, wherever they’re hosted, with Thundra Sidekick. When we say “anywhere,” we literally mean anywhere; your applications can live on containers, virtual machines, any kind of cloud environment, at the servers in your office building, or even in your homelab! All you have to do is instrument your applications with Thundra’s agents and add Thundra SDK to your application.
Thundra Sidekick eases the pain of debugging and enables developers to put breakpoints to the application code, which won’t break execution but take snapshots of activity instead. The snapshots of the same distributed trace events are correlated and visually displayed to help developers understand not only where the problem is, but also what the problem is. You can see how Thundra Sidekick works in this short video.
Debugging code is about fixing issues, but the typical cycle to fix an issue in cloud applications is a lot different than doing so in a local environment. It consists of several steps, such as creating a new build, deploying it to the cloud, and verifying the accuracy of the fix that has been instigated. This can be a very time-consuming and daunting process. Thundra Sidekick lets developers reload small code changes (null checks, wrong logical operators/comparisons, etc.) without re-deploying them. In this way, developers can gain time and productivity. Sign up with Thundra Sidekick and start debugging your remote applications faster than ever. It’s forever free!
*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Ismail Egilmez. Read the original post at: https://blog.thundra.io/a-fast-way-to-debug-remote-applications
