APM tools have been formerly and primarily siloed in the application development arena, with only the most important and mission-critical applications having their APM instrumentation extended into production use due to complexity and cost. In the modern world of application monitoring, the requirements for Dev and Ops need to be tightly integrated.
A truly hybrid APM environment, one requiring monitoring across the entire app stack, means Ops and Dev will need to occupy the same domain from a monitoring perspective. It seems obvious Ops faces a skills gap in this new world, but what will Dev and Ops need to learn to navigate the terrain together?
Dev vs. Ops: The Traditional Landscape
We often speak of DevOps as an integrated unit in the IT realm, but this hasn’t always been so. Historically, development and operations existed in isolation from each other and interacted only as necessary during releases. Dev wants as much change incorporated into a new release as possible, whereas Ops is devoted to ensuring the said release is rigorously tested for performance and stability.
Application creation, by definition, has been firmly couched within the lap of development, with operations only having the responsibility of verifying its stability prior to release and then reactive troubleshooting when something goes wrong. However, with the evolution of virtual environments, hybrid infrastructures, and distributed cloud services, application production and monitoring are becoming increasingly complex and integrated. It’s no longer sufficient for only Dev to be responsible for application performance. How do you not only bring Ops onto the monitoring team but also teach DevOps to become unified?
The first requirement to achieve this is to recognize the world has changed.
Hybrid APM and the New Reality
The traditional uses of APM have only addressed a subset of overall application deployment. Of commercial off-the-shelf (COTS) applications, Software-as-a-Service (SaaS) hosted applications, and custom applications, APM has been utilized primarily against custom applications, but not all three application platforms.
Businesses aren’t working solely in on-premises environments anymore—or at least not nearly as many as in the past. Whether your domain is strictly on-premises, hybrid, or purely cloud, you need to face the new reality of all applications requiring continuous full-stack monitoring.
Common assumptions or myths preventing the widespread adoption of end-to-end application monitoring are a skills gap among IT pros, particularly owing to the perceived complexity of application monitoring tools and methods, and the belief that integrating monitoring tools into the IT environment would involve a prohibitive expense. The reality is APM can be both simpler to use and less expensive. In fact, optimal use of APM can save the costs of lengthy troubleshooting time.
Although APM has finally hit the mainstream, it’s still largely misunderstood and therefore underutilized, and it remains largely siloed within DevOps during application development. Because applications now live in a hybrid environment, regardless of the perspectives by DevOps, application monitoring requires a truly holistic view, from application code to the supporting infrastructure and to the end-user experience.
Hybrid APM and What Will Ops Need to Learn?
According to the
SolarWinds® Cloud Confessions 2020 report, 57% of tech pros believe a lack of training was the major challenge in end-to-end APM adoption, followed by a lack of awareness of the APM solutions currently available in the market.
Although the least expensive method of ensuring good application performance is to catch and fix bugs and performance issues during pre-production development and testing, 70% of organizations still rely on manual troubleshooting processes in response to a production performance bottleneck.
According to survey results published in Cloud Confessions 2020, 84% of IT pro respondents were confident in their ability to manage application performance, mainly due to their troubleshooting skills.
However, application availability and performance must rely on the APM solutions that aren’t just reactive troubleshooting tools, which has been the usual role for Ops. To proactively leverage APM across the entire application stack, the silos containing services and the application code, underlying infrastructure support, underlying databases, and end-user experience must be eliminated.
For example, when Ops becomes aware of a performance issue, the immediate response can no longer be “It’s the code’s fault.” This attitude results in a code rewrite on Dev’s end but doesn’t necessarily get to the overarching systemic cause or arrive at a solution in a timely fashion.
The problem isn’t the data needed for Ops to proactively work not existing, or the Ops teams lacking the necessary education to learn; it’s the data being trapped in silos. This leads to the conclusion the information needed to optimize availability or recover from a performance lag is somehow nonexistent, when in fact, it’s available but not on a dashboard visible to the entire DevOps team.
DevOps has the responsibility to immerse itself in APM functionality from proverbial “cradle-to-grave” or rather throughout the lifecycle of an application. As public cloud, relational databases, and non-SQL datastores proliferate, this cradle-to-grave now spans database administration and optimization. Once this is achieved, DevOps then proceeds to scale APM tools and methods to monitor across the entire stack, sharing performance results with all business stakeholders.
The key takeaway for Ops is the same as for Dev. The silos isolating Dev and Ops from each other and the overall business environment have to be torn down.
Outside the APM Silo: Educating Dev and Ops to Work Together
As previously mentioned, Dev has traditionally focused on the rapid change with each release cycle, whereas Ops has prioritized the stability and performance of a release live in production. It may be an exaggeration to say this has created a type of enmity between these teams; however, the two competing priorities haven’t encouraged cooperation either.
The division between Dev and Ops must be addressed by both groups.
The key points Ops must absorb to achieve synchronization in DevOps include the following:
- A collaborative team mindset with Dev
- A flexible, agile approach to frequent feature changes
- A rigorous monitoring regime within all application environments from staging to production, and inclusive of all related underlying infrastructure such as hosts, storage, network, services, cloud platforms, databases, etc.
- Cooperative structured management of all application builds and releases
This isn’t all on the Ops side. From a Dev perspective, goals should include the following:
- A collaborative team mindset must be established with Ops and DBAs
- Engaging with Ops to develop the necessary—and shared—metrics for monitoring production systems, applications, and databases
- Involving Ops during code testing to understand underlying application performance characteristics (e.g., external performance dependencies not “in the code” or "not in the database")
If the optimal APM tool set is a unified interface for monitoring applications across a distributed environment, then the target of Dev and Ops is to become a single, integrated unit containing purposeful, mutually supporting goals and outcomes.
It’s All About the End User
A well-known political figure once used the slogan, “It’s the economy, stupid.” The reality for business is it’s all about the end-user experience. Even within a unified DevOps, it’s easy to get lost in the technological weeds. Enterprises often lose sight of applications existing to serve a business requirement. In this sense, APM is the property of not only Dev or Ops or DBAs but also the entire organization.
There’s no more powerful motivator to bring together a cohesive DevOps team than the realization that everyone who benefits from being part of a successful business is invested in the success of APM and the extension of its use to all applications instead of only a subset. DevOps then becomes part of the wider corporate community, and its achievements are those of its enterprise.
