Debugging Microservices in Cloud

Debugging

Contents

Debugging Microservices in Cloud

The Challenges of Debugging Microservices

Recreating State Across Hundreds of Processes Tracing Requests Across Services Is A Hassle Code May Act and Scale Differently on Cloud

Ways to Debug Code

APM Solutions

Debugging Dumpsters

Breakpoints for Stopping Code Log Analyzers

Must Haves for Debugging Cloud Applications

Non-Breaking, Non-Intrusive Options Observability into Code

Autonomous Exception Capture

Abstract

Debugging applications in the cloud can be challenging. Microservice applications are designed to run independently with their own

databases and logging, but this poses problems for developers when attempting to trace possible bugs in the cloud. To add to this, some bugs don't show up until the developer's code is up and running in the cloud and are caused by infrastructure and environmental—rather than logic—issues. This is where developers can benefit from utilizing third-party tools to better track and target bugs that occur. In this whitepaper, we will discuss how to effectively debug microservice applications in the cloud.

This requires implementing a system or tool that allows development teams to set up non-breaking, non-intrusive options. Some of these solutions enable developers to observe and trace issues into code as well as monitor said systems. With the right tools and systems in place, developers can better manage complex microservice

Debugging

Microservices in Cloud

Microservices have become a popular software architecture in which applications are designed as suites of independently deployable services. They provide isolated modules and services that can work independently of each other, and in theory, this makes development easier and faster and also isolates bugs.

This is in contrast to monolithic systems, which are often tightly coupled, so that an error in one module could cause an entire application to fail.

The idea behind microservices was that smaller, independent services would provide more flexibility for developers to edit code without concerning themselves that they might impact separate modules. If a developer accidentally allowed a bug in the code, it would only impact that specific microservice.

However, despite the many benefits of microservices, they are far from a perfect solution, as they present their own unique challenges. It is difficult to reproduce errors because requests made between various modules are asynchronous and thus difficult to track. In addition, it’s not easy to detect which services interact with which, as each request might take a different path, and microservice systems gain complexity over time because each service can be written in different languages, log differently, and be completely independent of other services.

The lack of cohesiveness between different microservices poses a major problem when it comes to debugging.

In this article we’ll discuss some of the challenges in debugging microservices, as well as some methods your developers can use to reduce those challenges.

The Challenges of Debugging

Microservices

Because of the way that microservices are designed, debugging them is not straightforward. Microservices are developed to run

independently of each other, which leads to challenges in tracking user requests.

In addition, when you push the code you develop to cloud, state and performance issues can be difficult to replicate.

RECREATING STATE ACROSS HUNDREDS OF PROCESSES

Because the state of the application isn’t consolidated in one monolithic system but is instead spread across many different

microservices, it can be difficult to get a clear view of the system’s state. This only becomes more difficult as a system grows in complexity. As more microservices and cloud components are added, a complex web of modules develops, each of which runs on its own and might fail without affecting the other modules.

However, it can feel impossible to keep track of which requests are going where and of the state of the system.

TRACING REQUESTS ACROSS SERVICES IS A HASSLE

Modern-day infrastructure is quickly becoming more complex and difficult to understand from a high level, as microservices and servless models become more popular. The principles behind these design models make it difficult to track requests and data throughout the processes. This is because each module, each serverless call, and each cloud component only further obfuscates what exactly is going on beneath the hood.

In turn, this causes a problem with observability and tracing, which refers to the developer’s ability to tell what the system’s internal state is. When a system is developed with a microservices approach, it can be a challenge to detect the internal state based on the outputs. This becomes apparent during debugging if a developer struggles to pinpoint the root cause of an error because all the modules are

isolated.

CODE MAY ACT AND SCALE DIFFERENTLY ONCLOUD

How code acts on cloud and development is not always the same. Even if you’ve tested your code with unit and integration tests, it can be difficult to assess what will happen to it once millions of requests are being processed through it on distributed servers.

If the code scales poorly or the underlying database is insufficient for managing the number of requests occurring on cloud, this could lead to various failures.

With so many possible points of failure, it can be extremely

challenging to determine which piece of code or database is causing the problem. A table could be deadlocked or a piece of code poorly written; but whatever the reason, the issue might not be apparent.

Ways To Debug Code

There are many methods developers can use to debug coding issues on microservices. Most were developed for monolithic code, where it’s easy to trace and track requests through the singular code base. Here are a few examples of classic debugging techniques.

APM SOLUTIONS

Application performance management (APM) helps a development team stay on top of their application’s performance. APMs can also be used to detect exactly where in your application a problem is occurring. In addition, they can often parse web server logs to calculate the number of requests coming in, monitor error rates,

identify slowdowns, and track key application dependencies like your RDS or Kafka instance.

These can help pinpoint major issues from a high level so your team knows where to look when errors pop up.

DEBUGGING DUMPSTERS

Before there were log analyzers and orderly forms of error message handling, it wasn’t uncommon to get a memory dump of an entire system where an error occurred. From there, developers would have to spend time reading through the messages and trying to pinpoint the source of the error. This was far from efficient and didn’t always lead to the root cause of the problem, as it would show only the state of

memory at that time.

BREAKPOINTS FOR STOPPING CODE

Breakpoints are a key component to active debugging. Developers can see what is changing in the state of their application at each

breakpoint and track what could be going wrong. Putting breakpoints

to the applications running on cloud is not feasible. You can’t stop your code as it’s running live just to see what the variables are. That is why this method of debugging can’t truly be used in production. It’s too invasive and doesn’t allow developers access to the information they need when they’re trying to get to the root of their problem.

LOG ANALYZERS

There are plenty of third-party log analyzers that can help break down and process logs to reduce the amount of time developers spend parsing through them. These analyzers can help detect where bugs or other issues are occurring, provide dashboarding to track performance, and help file bugs directly into Git repositories.

Must Haves for Debugging

Cloud Applications

While many of the methods described above can be very challenging to use in the context of microservices, that doesn’t mean you can't debug your microservice code using the methods described below: This works great with monolithic systems where a request is

interacting with one system, regardless of how many modules it interacts with. However, once you start working with microservices, it can become much more difficult to manage and track a request

through logs.

NON-BREAKING, NON-INTRUSIVE OPTIONS

This method will often require a third-party tool that provides non-breaking breakpoints. These tools allow your team to set

breakpoints that do not actually pause or halt, as they would with a standard debugger.

However, you can use these breakpoints in an execution flow to view stack traces and global variables as well as individual watch variables. Developers can use these non-intrusive breakpoints to test their

OBSERVABILITY INTO CODE

As discussed, one of the challenges with microservices is observability: It can be difficult to track requests as they pass through the complex systems developed over the years. Development teams would need to spend time and resources to develop their own observability platform, taking up valuable time that should be spent on new features for their company’s product.

However, many modern third-party tools have been developed to help track requests and provide code observability for microservices, as well as serverless and distributed computing. For example, Thundra can help you to observe how your user requests go through your complex infrastructure.

The ability to observe what is happening in your coding environment at a request level is very important and can help your developers track down bugs.

AUTONOMOUS EXCEPTION CAPTURE

Part of the battle with debugging in production is knowing that there is a problem in the first place. One way your team can approach this is to develop systems that automatically capture exceptions as they occur and track them.

This can help in the future, especially in tracking patterns or repetitive bad behaviors that might not show up often, even when users are looking at your site. For example, you may have an error due to the browser version or because of some strange stack overflow that happens only once every 30 clicks.

Whatever the issue, it’s important to have a system that automatically captures these errors. However, capturing them is not enough. Your team will also need the logs and variables that show when the error occurred so that it can be easily replicated on their end. This is

especially necessary for obscure bugs that occur only at odd times, like daylight savings or a leap year.

Systems that automatically track these exceptions and also help point out patterns can be very helpful for debugging applications on cloud, whether or not your system is a microservice.

Debugging with Thundra

Debugging microservices doesn’t have to be hard. As mentioned

earlier, Thundra offers several helpful features for developers to debug their code. From its early days, debugging the code in serverless

architecture has been a strong point of Thundra. Live debugging feature of Thundra lets developers pause and play the Lambda invocation from their own IDE. Thundra also provides offline

debugging (a.k.a time-travel debugging) that lets developers step through the code minutes, hours and days after the execution finishes. This lets developers understand the flow in the code and detect the unexpected behavior.

Not only does Thundra have a debugger that you can use for both serverless and microservice architecture; it also offers several

observability features that can be very helpful when you’re debugging your microservice code.

Thundra’s observability features take the three components of traceability—traces, metrics, and logs—and correlate them.

For example, Thundra offers traces that can help provide end-to-end visibility for a request throughout a microservice system. These traces can be used to help developers detect where in their microservice architecture there are bugs, bottlenecks, and other exceptions. As discussed earlier, having the ability to track a request and see where issues are occurring is an important step to debugging.

Developers can even drill down into a specific request and figure out more information, like variable values and which microservices were involved. You can also correlate similar information about traces and logs, or logs and metrics, or all three.

This allows your team to work backwards and find the root cause of a bug quickly, without needing to interfere with your other users.

Using our strong roots at debugging, we are preparing to solve the debugging issues for any type of application at any stage. Thundra will soon let developers set tracepoints on the code and take

snapshots that are integrated with the traces produced. Using Thundra, developers will be able to reduce the time spent for debugging from hours to minutes pushing changes to production.

Join our waitlist and claim your early access when the

cloud debugging with tracepoints is freshly baked!

Debugging Microservices Doesn’t

Have to Be Hard

Debugging has always been an art and a discipline that requires time to master. In the modern microservice space, it has become more

complex as systems grow and mature.

It is difficult to trace requests through code and to predict how code will scale once you deploy it to cloud. Add in the challenge of

debugging while in production and the task becomes even more daunting—though not impossible.

Using third-party tools to help track requests and create a more observable environment provides a huge advantage for developers. Besides just creating more observable environments, many of these third-party tools, like Thundra, can provide breakpoints and help correlate logs with metrics and tracing.

Microservice architectures offer many advantages, but you shouldn’t let debugging negate them. Consider employing a few of these

features in your environment to improve your team's development process. It will help your team maintain their codebase and reduce the time they spend tracking down pesky bugs.

About Thundra

Thundra is an enterprise SaaS company providing the industry’s first Application Observability and Security Platform™ for serverless-centric, container, and virtual machine workloads. Application teams

spanning software development, DevOps/SRE, IT operations, and IT security rely on Thundra to run fast safely, troubleshooting and debugging with improved MTTR while ensuring security and

compliance policies are enforced. Thundra is committed to making the lives of enterprise IT professionals better by reducing the

complexity, costs, and bottlenecks slowing teams down, leveraging Thundra’s unique technology footprint to replace numerous existing enterprise tools while improving productivity and efficiency.