Debugging Microservices in Cloud Contents

Home , Software architecture

3 Abstract

4 Debugging Microservices in Cloud

6 The Challenges of Debugging Microservices

6 Recreating State Across Hundreds of Processes

7 Tracing Requests Across Services Is A Hassle

7 Code May Act and Scale Differently in Production

8 Ways to Debug Code

8 APM Solutions

9 Debugging Dumpsters

9 Breakpoints for Stopping Code

9 Log Analyzers

10 Must Haves for Debugging Cloud Applications

10 Non-Breaking, Non-Intrusive Options

11 Observability into Code

11 Autonomous Exception Capture

13 Debugging with Thundra

15 Debugging Microservices Doesn’t Have to Be Hard 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 beneﬁt 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 architecture. 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 speciﬁc 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.

DEBUGGING MICROSERVICES IN CLOUD 4 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.

DEBUGGING MICROSERVICES IN CLOUD 5 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’re moving code from development to production, state and performance issues can be difﬁcult 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 difﬁcult to get a clear view of the system’s state.

This only becomes more difﬁcult 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.

DEBUGGING MICROSERVICES IN CLOUD 6 TRACING REQUESTS ACROSS SERVICES IS A HASSLE

Modern-day infrastructure is quickly becoming more complex and difﬁcult to understand from a high level, as microservices and servless models become more popular. The principles behind these design models make it difﬁcult 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 IN PRODUCTION

How code acts in production and development is not always the same. Even if you’ve tested your code with unit and integration tests, it can be difﬁcult 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 insufﬁcient for managing the number of requests occurring in production, this could lead to various failures.

DEBUGGING MICROSERVICES IN CLOUD 7 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 MICROSERVICES IN CLOUD 8 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 efﬁcient 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 in production 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 ﬁle bugs directly into Git repositories.

DEBUGGING MICROSERVICES IN CLOUD 9 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 difﬁcult to manage and track a request through logs.

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:

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 hypotheses on where issues are occurring without halting code or redeploying/restarting their code base.

DEBUGGING MICROSERVICES IN CLOUD 10 OBSERVABILITY INTO CODE

As discussed, one of the challenges with microservices is observability: It can be difﬁcult 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 in production.

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 ﬁrst place. One way your team can approach this is to develop systems that automatically capture exceptions as they occur and track them.

DEBUGGING MICROSERVICES IN CLOUD 11 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 in production, whether or not your system is a microservice.

DEBUGGING MICROSERVICES IN CLOUD 12 Debugging with Thundra

Debugging microservices doesn’t havehave toto bebe hard.hard. AsAs mentionedmentioned earlier, Thundra offers twoseveral main helpful products features (Sidekick for developers and APM) withto debug severaltheir code. helpful From features its early for days, developers debugging to debug the code their in code. serverless Thundra’s productsarchitecture provide has been comprehensive a strong point observability of Thundra. into Live the debugging microservice applicationsfeature of Thundra that are lets hosted developers anywhere pause from and on-premises play the Lambda to the cloud. invocation from their own IDE. Thundra also provides offline Itdebugging is blazing (a.k.a fast to time-travel debug applications debugging) that that you lets do developers not host with step Thundrathrough theSidekick. code minutes,Sidekick enableshours and developers days after to the set executiontracepoints finishes. on theThis code lets developersand take snapshots understand that the are flow integrated in the code with and the detect traces the produced.unexpected After behavior. guessing the problematic parts in the code, developers can make hotfixes and reload without redeploying the app to the cloud.Not only Using does Sidekick, Thundra developers have a debugger are able that to reduce you can the use time for spent both for debuggingserverless and from microservice hours to minutes architecture; pushing it changesalso offers to severalproduction. observability features that can be very helpful when you’re debugging Fromyour microservice Thundra’s early code. days, debugging the code in serverless architecture has been a strong muscle. The live debugging feature lets developersThundra’s observability pause and play features the Lambda take the invocation three components from their of own IDE. Thundratraceability—traces, provides another metrics, useful and logs—andfeature called correlate offline them. debugging (a.k.a time-travel debugging) which lets developers step through the codeFor example, minutes, Thundra hours, and offers days traces after that the executioncan help provide finishes. end-to-end This lets developersvisibility for understand a request throughout the flow in athe microservice code and detect system. unexpected These traces behavior.can be used to help developers detect where in their microservice architecture there are bugs, bottlenecks, and other exceptions. As Notdiscussed only does earlier, Thundra having have the aability debugger to track that a yourequest can useand forsee both where serverlessissues are andoccurring microservice is an important architecture; step it to also debugging. offers several observability features that can be very helpful when you’re debugging your microservice code.

DEBUGGING MICROSERVICES IN CLOUD 13 DevelopersThundra’s observability can even drill features down into take a thespecific three request components and figure of out moretraceability—traces, information, like metrics, variable and values logs—and and correlate which microservices them. were involved. You can also correlate similar information about traces and logs,For example, or logs and Thundra metrics, offers or all traces three. that can help provide end-to-end visibility for a request throughout a microservice system. These traces Thiscan beallows used your to help team developers to work backwards detect where and in find their the microservice root cause of a bugarchitecture quickly, withoutthere are needing bugs, bottlenecks, to interfere and with other your exceptions.other users. As discussed earlier, having the ability to track a request and see where Usingissues our are strongoccurring roots is anat importantdebugging, step we areto debugging. preparing to solve the debugging issues for any type of application at any stage. Thundra willDevelopers soon let can developers even drill set down tracepoints into a specific on the request code and and take figure out snapshotsmore information, that are like integrated variable with values the and traces which produced. microservices Using were Thundra,involved. developersYou can also will correlate be able similar to reduce information the time aboutspent fortraces and debugginglogs, or logs from and hoursmetrics, to orminutes all three. pushing changes to production.

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

JoinSignup our for waitlist Thundra and S claim IDEKICK’s your public early accessbeta today when and the start DMPVEdebugging debugging your cloud with tracepointsapps 10x faster is freshly than beforebaked! with non-breaking tracepoints combined with distributed tracing. Join the Waitlist Signup for free

DEBUGGING MICROSERVICES IN CLOUD 14 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 difﬁcult to trace requests through code and to predict how code will scale once you put it into production. 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 in-production 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.

DEBUGGING MICROSERVICES IN CLOUD 15 About Thundra

Thundra is a SaaS developer platform company that empowers application teams to develop, debug and deliver modern microservices on cloud. By offering everything from automated instrumentation to cloud debugging in a single platform, Thundra eliminates the need for multiple tools for pre-production environments. Developers who embrace DevOps and are motivated to solve issues in cloud applications use Thundra to eliminate problems in production. Thereby minimizing the need for on-call response, increase productivity, and deliver robust and resilient applications.

Want to see Thundra in action?

demo.thundra.io Any questions or inquiries?