_
_
Are you an SRE at an organization that is looking to either roll out APM (Application Performance Monitoring) or expand its usage? If so, then look no further! First, I will run through approaches that I’ve seen be successful in my experience, rolling APM out at Wayfair and being responsible for all of our Datadog deployments at RapDev. Next, I’ll highlight the selling points and benefits that developers can expect to see. A proper implementation of APM with both buy-in and adoption from the majority of an engineering org is an extremely powerful step change that can often reduce friction that you may experience as a developer or an SRE.
Let’s start by getting into a few of the best approaches for presenting APM.
First, the most ideal scenario is that you are able to get a POC spun up that shows an application team’s service instrumented rather than selling them on what they can expect to see. Nothing beats live data and visualizations, no matter how good you are at pitching it. The beauty of automated tracing is that it’s very quick to be able to spin up APM for a developer without them even needing to manually instrument anything within their application.
Second, I also recommend that you provide similar views to what they are currently used to using for their application observability. For example, if their primary platform of choice is Kibana and log searching like this…
…you can show them a similar view like this:
With this foundation in place, you can then start detailing all of the great benefits they can get from this model, which I’ll touch on in the following section.
In any organization, it’s very likely that there will be an incident where your application is having issues and it may be called out as the primary cause. Empowering developers to be able to troubleshoot issues with their application (or in some cases ruling out issues with it and pointing to a broader cause) helps with incident response and also reduces the stress from having to scramble to debug what’s going on in the heat of the moment.
Prior to APM, it often took development teams considerable effort to be able to provide a baseline level of observability around their application. It is not uncommon for developers to have to add hundreds of timers to their code or logs just to try and build a cohesive picture. APM removes much of that upfront cost to know what’s going on and a lot of the guesswork needed to know where you should be instrumenting timers or logs. It’s also very easy to add additional spans within your application code if you find some areas where auto instrumentation isn’t properly picking up on your application’s behavior.
Performance drift for an application is an extremely common problem that can easily get out of control if unchecked. Especially if you have deployment tracking in place, you can keep a very close eye on application performance and link with new features as they get introduced. You are basically getting a post deploy dashboard for free!
Finally, with APM in place it can be a very helpful tool for onboarding new engineers to an application, especially in cases where architectural diagrams may not exist, be up to date, or accurate. By leveraging service mapping, you can reveal places where your application is being called from that they weren’t aware of (i.e. application > your application or even being an unknown dependency in critical paths like customer checkout).
This is by no means a conclusive list of all of the benefits of APM, (I’d recommend checking out Datadog’s docs as a launching point!) but hopefully this can act as a helpful guide to you for the areas where developers can get the most benefit upfront out of leveraging APM.
