When companies move toward hybrid and multi-cloud, both leadership and IT can struggle to adapt their organizational structures and processes to a new, more complex way of doing things.
With the classic form of DevOps, for example, operational monitoring and management procedures are radically new and different: from a management perspective, it almost appears as a free-for-all, making assessment and accountability to the business difficult to achieve on a regular, ongoing basis.
The older system was straightforward: on-premises monitoring and management teams were organized around a technology stack, with associated monitoring and management tooling. The network, server and storage teams each had distinct processes. Different problems were escalated and triaged (Level One, Level Two, Level Three). It was formulaic—perhaps even annoying to some tech pros—but it worked.
DevOps is different. Applications are changed, tested and deployed in production continuously, often on an hourly basis (or more frequently). It’s revolutionary because it delivers maximum business market agility, embraces technical and business evolution, and is never-ending. It radically redefines the concepts and approaches we associate with application and infrastructure support and triage processes.
But there’s good news: Application performance solutions and workarounds are coalescing. Here’s a few ways we’re seeing teams evolve to overcome the challenge of hybrid and multi-cloud application and infrastructure management.
Try a Monitoring Engineer
Right now, we’re all experimenting—we’re in a digital Wild West. In that spirit, forward-looking outfits are working with the concept of a monitoring engineer (sometimes monitoring support), someone who owns the monitoring of everything important in the context of an application or a line of business.
“Monitoring engineer” as a job title can mean many things. If you Google it you’ll find open positions for many kinds of these engineers. But for our purposes, it’s a stand-in for a new concept, a new way of thinking. To be clear, this isn’t a network monitoring engineer, or any other kind of job with the title of engineer. It’s a new way to better and more proactively align IT with the business goals of the company paying the bills.
Traditionally, metrics have been aligned to the application or applications being built out—not the business itself. More importantly, these metrics aligned around answering questions like, “Is this specific element of infrastructure or application available and performing?” Especially at the infrastructure level, performance was defined typically as a technology resource utilization metric (i.e., how efficiently are technology resources being consumed). This new concept of monitoring engineer is designed to allow management to quickly get the answers it needs in a consolidated and focused fashion—to move, in effect, from resource-centric monitoring to service and application-centric monitoring.
Application performance monitoring (APM) has evolved thanks to measurement focused on application availability and performance rather than infrastructure. APM requires a certain amount of applications knowledge. The monitoring engineer needs to know enough about the application environment, how the application is configured and how it’s deployed operationally but doesn’t have to be the expert in the application code itself.
Importantly, a successful monitoring engineer requires time and focus—and management needs to set up a structure to support it. Any competent system administrator or network engineer who’s worked in a complex private cloud or on-prem hybrid environment would have the skills to do this. But these engineers need time and the ability to focus on their job, while adding APM skills to their repertoire.
Creating Metrics That Matter
Along with the dedicated monitoring engineer who’s minding the technology store for management, processes and languages must be standardized.
Think back to when virtualization swept the tech pro world, some 10 or 15 years ago. We had to change and adjust. We have to do it again.
We should start by standardizing the application languages tech pros use. How we choose languages should always be business-driven: Different languages are good at different things, which should be the deciding factor. The number of languages should also be limited, so management can be more straightforward. Similarly, standardization should be the default wherever possible to approaches considered for automated deployment and dynamic configuration management of both applications and infrastructure resources.
Keeping things as simple as possible doesn’t mean not learning new things, however. Management will need to cultivate a culture of curiosity. Tech pros must learn new ways of working—if they don’t, the transfer to hybrid and multi-cloud will be a guaranteed slog, or worse.
If the tech pros stay curious, they’ll stay ahead. The APM market is growing at a considerable rate, and the people with the curiosity to get involved in it are the ones who will succeed.
APM gives tech pros a powerful tool they can easily add to their skillset by which they can then generate the data and the metrics in the language of the business. When metrics are business focused, they matter.
The measurements the business (and customers) care about are fundamentally limited to four key metrics, in two classes:
- Application performance—how much business work is being accomplished over time, along with the response-time experience of users.
- Availability management—whether all resources associated with the entire technology stack are continuously up and available to service the applications, along with any and all associated errors.
Taking this approach to measurement is about meeting the company needs in business terms, not IT. This approach is critical for ensuring excellent customer experience or an ability to immediately and cost-effectively respond to peaks in business demand. This approach answers the questions: What are users experiencing? How are specific pages and transactions performing? APM can also discover what infrastructure components are needed to support those applications delivering successful service.
Answers like these can’t be discovered with infrastructure monitoring alone, nor with infrastructure-centric monitoring of application performance that infers performance from technology resource utilization rates. Nor can they be answered with network monitoring or storage monitoring. Only APM provides the answers the business needs. It’s the glue to bind together the different silos.
Measurement Matters Most on a Thin Margin
We’re in a new environment. In many ways, it’s the Wild West and there are many ways to win and lose. Few things seem absolutely right, except this: Tech pros need to be completely aligned with the businesses they work for.
In the past, a strategy such as APM was perhaps better aligned with industry verticals. Companies operating with thin business margins were reluctant to measure. Now, it’s the opposite. Companies such as those in the e-commerce, B2B, B to high volume and B2C spaces continue to operate on thin margins and are now in a virtuous spiral. Their success depends on efficiency—and efficiency is key to making them win in the increasingly competitive marketplace.
To achieve this level of success, companies must measure and assess where they’ve been and where they’re going. They need to do more than just keep up with the competition, they need to accept innovative processes such as DevOps, while continuously measuring their progress.
Ultimately, speaking in the language of business can take many IT professionals outside their comfort zones. But APM gives the wary tech pros a powerful tool for generating the kinds of data and metrics management needs. APM grounds the business, but also makes sense of the new hybrid and multi-cloud environment. It’s a chance for management and IT to bridge the gap between us and them. It’s the best way to manage the changes to come.
