To automate your DevOps processes, start with monitoring
Within companies trying to scale to even moderate size and sophistication, IT must change its focus from "making it work" to "making it efficient." It's not surprising, then, that themes such as agility and automation are now among the most important design criteria.
But where should companies that see automation and DevOps as the future start?
While there is a burgeoning ecosystem of DevOps tools, enterprises that want to fully unlock the benefits of automated operations need to start with something more foundational: monitoring.
Start with workflows
Automation is about workflows. A workflow is simply a set of steps that must be executed to meet some objective. At the core of automation is stringing these steps together so that they can be executed automatically.
So whether it's automated provisioning to speed up the time to stand up a new application or streamlined troubleshooting to more quickly find and resolve issues in the infrastructure, the practice of automation and the tools that support it become the foundations for modern operations practices.
But concluding this means that automation that starts with these tools misses one of the most basic points of DevOps.
Even if a workflow is automated, you need to have some way to trigger it. If the trigger is a human typing a command, most of what you have done is remove keystrokes from the process. This is still worth doing, but it falls short of the transformative benefits of a truly dynamic infrastructure.
Rather, enterprises looking to introduce automation and DevOps need to start before the workflows. They need to consider what initiates action.
See something, do something
If workflows are the foundation of automation and DevOps, then monitoring is the bedrock on top of which that foundation is poured. To put it simply: See something, do something.
As basic as that sounds, the implications are actually fairly profound. If you cannot see what is happening, you cannot take full advantage of the automation and DevOps movements. This means that before you start down this path, you need to make sure that you have adequately instrumented your infrastructure.
How can you know what workflows you can automate if you do not know what data you have access to? Architects need to start with an inventory of the data that is available and then map that data to the workflows that will be triggered.
Starting with a list of workflows leaves the task only half-finished.
When identifying what data is available, teams need to pay particular attention to how that data is retrieved. In most IT environments, getting stats is an exercise in looking backward. You pore over logs and data stores, typically in response to some event or perhaps a request. This is because most infrastructure instrumentation is used to troubleshoot or report trends, tasks that happen in hindsight for the vast majority of mainstream enterprises.
If you want to automate things in the moment, you have to architect your infrastructure to make this information available in real time. It's not enough that data be available on request—it has to be continuously available.
This is why automation and DevOps frequently involve a streaming state and collection mechanisms to allow that state to be consumed centrally. If you are embarking down the DevOps path and you have not yet discussed message buses and the role of real-time telemetry, chances are that you have skipped a key step.
If the workflows that can be automated depend on access to data, then the more underlying information that is available, the broader the set of workflows that will be in play for your operations teams.
When monitoring is an after-the-fact exercise, the only data available is that which is already on the devices that are deployed. As you adopt a more proactive stance toward monitoring, you should also be looking to expand the diversity of information within your DevOps environment.
Thus, monitoring and visualization tools that extend your reach beyond the devices can be some of the most important force multipliers to consider. You already have device-level information about the servers, storage devices, switches, and routers, but how robust is your application and user data? And can that data be correlated with the information coming from the rest of your infrastructure?
Fundamentally, if you can paint a more complete real-time picture, you will be able to do more with your automated infrastructure.
Where to start your architecture
Architecture changes for much of the past 30 years have begun with the underlying devices. But as we move to environments that are more responsive and adaptive, we will naturally need to change not just how we build but also how we design our infrastructure.
As the meaningful design objectives shift primarily from making it work to making it operationally friendly, the most important bits will not be how workloads are computed and transported, but rather how workflows are automated.
This means that continuous monitoring and automation become the problems to solve for. And only after these solutions are architected should you make decisions on the underlying devices that support your operational framework.
Traditionally, monitoring has been a function performed by humans, but ideally, monitoring should be a function driven by machine learning and algorithms. Monitoring tools need to provide more than visualization; they should deliver on continuous monitoring and automatically trigger actions to complete workflows without the need for human intervention and remediation.
To do all this, enterprises will need to bring their operations teams into the architecture discussion, which itself will need to start with the data that is available and the tools required to automate the workflows. Ultimately, the requirements for real-time data ought to shape which devices are deployed. After all, how can you reach the right end state if you ignore the most important prerequisites?