Debugging Apps Made Easy: Remote Debugging with AWS

Software development on the cloud has changed many things. Modern applications are now composed of distributed microservices with managed services maintained by cloud vendors. There are tons of good resources available on how to build robust, reliable fast architectures using serverless, containers, Kubernetes, etc. But that one thing hasn’t even slightly changed: Bugs are there and causing sleepless nights for developers. Software bugs have become even harder with the advent of distributed microservices running on the cloud rather than our local computer. An innocent code running happily in your local with mock services can cause a catastrophic cascading error and might impact your customers.

When building something from scratch with fancy algorithms, cutting-edge event-driven infrastructure, or user interface design, the only thing that slows you down is the debugging process. In this article, we’ll discuss why remote debugging during the development phase is better than the local environment. We’ll particularly keep it in the scope of debugging.

Debugging in a Local Environment

When the term debugging was first invented, it was actually taking the bugs out of the software tapes. These days, however, debugging means different actions to different people. Developers are digging the logs, using traces, reviewing the code, and more to resolve the bugs in software. The most ancient way of debugging is still to set up breakpoints on our local machine while developing.

As debugging is closely related to development, IDEs, code editors have invented various mechanisms to debug code locally. Native debuggers of programming languages are integrated with IDEs to achieve this capability. For example, Python has pdb and Ruby has Byebug  and Pry.

As modern applications become increasingly complex, debugging solely in a local environment has proven to be inadequate.

Why Debugging in a Local Environment Is Insufficient

When we are developing cloud applications on our local, we are limited with the happy paths and known issues but an app in the cloud is full of surprises and unknown failures. As the development environment can’t mimic the cloud, it’s hard to reproduce the variable values, specific threads, and anything else that led to the bug. Besides, it’s simply impossible to reproduce some bugs in the local environment. Finally, modern applications usually rely on third-party APIs that are either mocked or skipped during local developments. It’s daunting to develop local by predicting their actual behaviors. Developers should do better than hoping that the code will work as expected when pushed to cloud services like AWS.

Bottom line: debugging applications locally is essential, but not enough to find and troubleshoot all issues.   This is especially true in microservices or serverless architectures, where several services run and communicate among themselves. To drastically reduce a bug’s time to resolution in cloud-native applications, developers should adopt developing remote environments - on AWS - and find the best way of debugging in such configurations.

Is debugging cloud applications hard?

This question brings another question: What do you understand when I say debugging cloud applications? The word debugging is inevitably understood as something, well not debugging. Developers often find it hard to debug modern apps in the cloud because the information relevant for detecting and fixing bugs in such applications is distributed between multiple sources, such as log files. Sifting through such files is as tedious as looking for a needle in a haystack.

Digging through log files to understand the issues in remote environments is the first thing when we are debugging cloud applications. Another alternative might be using more advanced tools for observability and taking advantage of tracing through several microservices.  

The Problem with Digging Logs

Logs are the most ancient component for debugging issues on any remote machine. With the advent of microservices running on cloud environments, logs are now more critical than ever. Microservices offers many new benefits like accelerating feature delivery, scaling up fast, being able to deploy independently but they’ve also introduced new challenges in understanding the behavior and debugging.

In a very typical microservices architecture, there are multiple log files distributed across a set of disparate sources. Because each microservice implements its own event-logging methods, you eventually end up with an avalanche of log data that is difficult to sift through. Besides, you need to learn even more about the local variables, call stack, queries sent to databases, etc.

Many things can go wrong in a microservice architecture. With so many components working together, it becomes more challenging and impractical to reproduce a bug and trace it to the root cause — especially when you need to track a single operation across multiple logs or systems that communicate with each other. In summary, sifting through logs is not enough to pinpoint some issues in production systems, as they may lack relevant contextual data that shows the root cause of a bug.

A Better Way: Live Debugging

If you’re looking for an experience that’s similar enough remote debugging is the closest form of it. Live debugging is debugging an application that is running outside your local environment. It's usually done by connecting the remote app to your local environment using a debugger (IDE or programming language) that supports remote debugging. It allows you to efficiently debug an application, especially in scenarios where regular debugging is impossible. Remote debugging also removes the burden of digging through huge log files or replicating the cloud environment locally.

Remote debugging eradicate the weaknesses associated with the logging approach. Remote debugging enables you to:

• Access the application states, including the full stack trace, and the global and local variables you need to debug.
• Fix errors in a cloud application remotely and quickly, without restarting or redeploying your application.
• Collaborate in real-time with your team members to resolve bugs faster.
• Get data from your code and debug issues without logging extensive data that slow down or disrupt your app's performance.

Sidekick supports application debugging in remote environments. These environments might be either production or pre-production environments. Sidekick provides non-breaking breakpoints, called tracepoints.

You can find our documentation to help you get started. See our four-minute video that explains more about Sidekick.

If you have yet to take your first step into the world of Thundra, you can begin your journey here.