Despite having a clear focus on baking in application security and quality from the very start, many companies neglect the opportunity to do the same when scrutinizing their applications for performance, general health, and other issues. The approach they should be taking is monitoring as code.
This technique becomes even more critical with the move to continuous delivery, especially when issuing several releases per day.
Broadly defined, monitoring as code adopts the same approach as infrastructure as code, to which it is closely related: You manage monitoring the same way you do applications, servers, or other infrastructure components. You use high-level syntax to describe your monitoring tools, frameworks, what to monitor, and when to alert, among other things. This means your monitoring setup, processes, and rules can be versioned, shared, and reused.
True, developers have been writing more code to help monitor the apps they create. But as the number of these applications grows, developers realize they don't want to be the ones getting 24/7 alerts, and they pass off what they've done to IT Ops. Too often, however, the operations team cannot use whatever monitoring the developers have created because of incompatible tools, among other issues.
Here's how to help your development and operations teams do their best work, be on the same page strategically, and not have to re-create monitoring for every new app.
Consider monitoring as just another service
There are two key issues at play here: Developers want to create great apps and then move along to the next shiny new thing, and most organizations lack a good process for handing over monitoring from dev to ops. In theory, DevOps should be the solution to this, with dev and ops working hand in glove. The reality is that most DevOps teams really are dev teams that also do operations in the early lifecycles of a products.
As long as the application is not creating overloaded CPUs, network congestion, or storage overruns, then operations figures it is working okay. But ops knows from bitter experience that when things start to go wrong, fixing the problem requires something close to a black art.
The monitoring was not warning of issues before problems arose. There is no insight into the application, so understanding what is wrong is like fixing a car without having the keys to open the hood. And the recipes for restarting an app, or scaling it up and down, often are outdated.
What needs to happen, first and foremost, is to "promote" monitoring to become a first-class citizen. Treat it as a service that has the same respect and process-oriented thinking that documentation, testing, and other code-related activities have.
Develop user stories, much as you would for any features under development, and treat ops as you would any business partner. In other words, ops must become a business stakeholder in the development world.
In this scenario, your ops team defines different types of monitoring, including tools and processes, for different classifications of apps and their sub-components. So, for example, the tools and processes used for monitoring a web-based application's network usage would be different from those for monitoring the CPU or storage performance of an ERP system. Mission-critical apps would be treated differently from those that aren't.
Make monitoring part of your service catalog, if you have one, so it can be available to your devs to use as they go. Manage your core monitoring solutions as a first-class IT service that can be consumed by anyone who needs them. And as with any other modern service, make monitoring consumable through APIs so developers can code against the monitoring services that operations provides.
Other key best practices
As you're grappling with what it means to release a product in the era of continuous delivery, you need to shift left with monitoring along with testing and everything else. A release must contain not only the bits and bytes of the functional code, but the automation scripts for all the other activities that need to be done downstream: testing and, yes, monitoring also.
Indeed, the industry standard IT4IT Reference Architecture has embraced this concept of managing a release as a complete package that has all the assets needed for products. IT4IT is also the framework that can guide how to publish operations services in a catalog for development to consume.
Figure 1. Monitoring as code in the IT4IT Reference Architecture. Source: opengroup.org/IT4IT
An associated necessity is to incorporate the testing of the monitoring system and processes into the product release. You have to ensure that the monitoring works and can be enabled as automatically as possible in the production environment, not just in dev or ops.
Another aspect is that you need to flip the usual order of creating an app and then "discovering" it into your configuration management database (CMDB). This population should be part of the product deployment, so the code can directly populate and configure the CMDB without the CMDB having to look for it.
Growing up can be hard to do
Much of what the infrastructure-as-code approach requires will compel both dev and ops to become more mature. This often means thinking about creating a software factory. Essentially, ops needs to develop services that are geared for dev. In other words, operations becomes the starting point and not the end point of development.
At Micro Focus, we implemented the software factory concept, which requires an integrated set of tooling, services, data, and processes that help our engineers to plan, build, test, release, and/or operate and manage the software we deliver to our customers.
Keep the big picture in mind
Ultimately, monitoring as code is part of the broader infrastructure-as-code movement: How you provision code and deal with any problems, your tools, and rules. All of this should be treated and managed as code.
Dev and ops teams must collaborate and start this process early, before any monitoring code gets written. Document what you do and make this a true DevOps engagement.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
