The Changing Face of Application Performance Management
Raygun sponsored this post.
Are you simply “monitoring” your application or have you graduated, as some may imply, to “observability?” Is “observability” actually the evolutionary successor to “monitoring,” or is it merely a rebranding of nomenclature? And how has monitoring (or observability) changed in this new world of microservices and serverless architectures?
This week on The New Stack Makers podcast, Alex Williams, founder and editor-in-chief of The New Stack, is joined by co-host Bradley Rydzewski, who is the co-founder at Drone.io, as well as guest JD Trask, co-founder and CEO of Raygun, to discuss the continuing evolution of application performance management (APM) beyond changing terminology.
According to Trask, one of the primary changes that has occurred in the world of APM has been the amount of available compute and the resulting capabilities available to APM users.
“We’re starting to be able to layer on more value for the customers of APM tools and part of that is driven by the fact that we can actually do that work without it taking, say, 90 percent of the compute power on a box just because of the improvements that have come out,” said Trask. “The next challenge being, now that we can collect all this extra data, how do we no distill that down into some actionable insights? Just having more data isn’t actually a huge win in of itself.”
Of course, this point is one that some see as precisely at the core of the debate over monitoring versus observability — that observability involves more than watching something happen, instead of extrapolating these “actionable insights.” Rydzewski points to the recent popularity of the idea of OpenTracing as a key point of interest for APM moving forward.
“Traditionally, developers have thought about applications in terms of individual servers and databases, but this idea of open tracing where a user takes an action in an Android app or in a web app and you can actually trace that action from the client side software to the server to any microservices that are happening to the database and back and you can get this really interesting timeline of everything that happened, and how long it took — it really gives you this holistic view into your stack,” notes Rydzewski.
For Trask, a key point in the evolution of APM follows along these lines, but rather focuses on the separation of APM from the physical structure of an application itself. It is this separation, after all, that allows for the ability to follow these user paths and offer deeper insight than lagging database calls and the like.
“You shouldn’t have to think about the physical implementation, you should just be thinking about the logical representation of your software, whether that’s lots of services or whether you’re starting out on day one and it’s just one server with one monolithic piece of software. It shouldn’t matter and it shouldn’t change how you use these sorts of tools,” said Trask, later adding, “We don’t really believe that the future is having to think super hard about the physical layout of your software. If your app is running across 5,000 containers, one container, 10 physical servers, one physical server, the way we look at the world, we don’t really care.”
In this Edition:
2:16: How do you feel that APM has evolved over the last few years? And how do you feel about that evolution?
5:45: Brad, what would you like to see from this type of technology over the next few years? What is most interesting to you?
10:21: What is the boundary where logging ends and tracing begins?
17:30: A lot of people that are listening are going to be wondering what APM and tools like Raygun can enable in a Kubernetes environment and how it can help teams manage it.
23:09: Exploring the concept of tying traces to individual users and how this made its way into Raygun’s crash reporting.
27:41: What are the common pitfalls you’re seeing teams experience working with serverless if I’m not using APM?
Feature image via Pixabay.
