Nowadays, the term ‘remote debugging’ instills fear into even the bravest of dev hearts. Palms sweaty, knees weak, and arms ready (to code) they dive into what they’re sure will end in much pain and possibly a few broken pieces of code. This scenario and these feelings are common to devs everywhere, where many opt to take the trusted path of debugging on their *own* machines. While this may be a tried and true method, the future of debugging is here and, you’ve guessed correctly, it comes in a remote form (cue heart palpitations).
Service architecture has become increasingly complex and the old days of monolithic applications are behind us (well, not entirely, but that’s another discussion for another time). With the rise of new software techniques such as microservices or serverless, not only has the way we write code changed, but also the way we debug it. This change necessitates taking a leap of faith to try and adopt new means to work the bugs out of the system. Enter remote debugging.
In simple terms, remote debugging is debugging an application that runs in a place other than your local environment. This is usually done by connecting the remotely running application with your development environment. Intrigued but also a little terrified? We get it, but don’t run just yet.
When Should You Use Remote Debugging?
If you are a developer or an executive (or both), you know that debugging is crucial. Even more, you understand that while classic debugging might be yielding results now, remote debugging - when done right- can save you a significant amount of headache and time. Remote debugging becomes crucial at some point for you, whether it’s because of difficulties you’ve encountered with classic debugging or the simple fact that the classic debugging method has become near impossible to use.
Believe it or not, there are high chances that at one point you used the technique of remote debugging without even realizing it. Crazy? Not so much.
For a deeper understanding, let’s look at the problem with the old way of troubleshooting the code for modern software architecture. Let’s take a look at microservices, given that this method has been used by developers for a longer time than the serverless approach.
As we know, microservices came into place as a solution, as well as a substitute for monolithic applications. At its core, this technique is defined by the following principle: divide a big application into smaller parts that are easier to manage, and distribute the workload among developers.
As you can see in the below scenario, the application is distributed, thus making it much more difficult to reproduce a bug, due to the simple fact that it’s difficult to trace it back to the source. On top of this, logging is decentralized and harder to analyze.
If you are going to attempt production debugging of such an architecture, you will have to access and sift through many log files, and to write often necessary additional logs, after which you’d need to redeploy and restart your application, just to get additional data. This process is not only time consuming but it also requires more practice and patience. So yes, we understand why you try to avoid debugging microservices like the plague.
What About a Serverless Application?
Serverless, comparatively to microservices, is a much more distributed architecture. The underlying premise of serverless is that it works by default abstraction of underlying infrastructure and abilities related to it. Thus meaning, we decouple our application at function level. Function levels are single-purpose, programmatic functions that are hosted on managed infrastructure.
The downside in microservices is that developers who are working in normal conditions aren’t able to run their processes and can’t debug their serverless applications on their IDE or local environment.
A 2018 community survey of the biggest serverless challenges showed that the most notable one to be debugging. This with the addition of monitoring and testing clearly points back to a lack of proper tooling.
These examples represent situations where remote debugging can bring surprising value, making the process simpler and faster, most significantly in cases where regular debugging is impossible.
A more classic case where this can be seen is with a web application that has a problem on mobile phones. In this situation, remote debugging with the help of different tools made available by modern browsers is the only solution.
How To Go About Remote Debugging Properly
As wise men have taught through the ages (well, the debugging ages at least), debugging is 99% about collecting data about your application until you reach the point where you figure out what is causing the problem.
Remote debugging is the same, but because the application runs on a different host than yours, collecting data from it can be really problematic and can have a lot of caveats in terms of performance.
Luckily enough, nowadays we have a powerful suite of tools that allow you to debug defective code running on a different host as if it were your local code. Yes, you read that right: remote debugging can be done so that it’s basically like classic debugging. To learn more about modern approaches in remote debugging, feel free to check out Rookout.
