How to Scale the Ops in DevOps
DevOps has been a popular IT buzzword for years, and its use is only continuing to grow as more and more companies try to break down walls between developer and operations teams. According to InformationWeek’s The State of DevOps report, 50 percent of organizations have implemented DevOps, or plan to implement it soon. Only 20 percent of respondents have no plans to implement DevOps in the foreseeable future. Despite this interest in DevOps and its maturation, organizations still face barriers to adoption.
Barriers could be in large part due to a misunderstanding of the benefits of DevOps and what implementing it actually entails. There are probably as many definitions of DevOps as there are developers and ops people. To many, DevOps is being equated to agile software development practices like Scrum, and faster software delivery through continuous integration and continuous delivery. The State of DevOps report backs this up, as the top two DevOps benefits cited were increased collaboration and higher frequency of software and services deployments.
Enterprises have focused a lot of effort on automation in their software delivery pipelines, through containerization, microservices, testing, orchestration, or other technology initiatives. With all of this concentration on development, enterprises are neglecting the other half of DevOps – operations. Scaling DevOps also means developing scalable processes for monitoring and troubleshooting once the software is deployed. When code starts its “real life” in production, you need to be ahead of the curve.
The number of moving parts in modern software architectures, coupled with the release cadence that other DevOps practices introduce, make monitoring and troubleshooting much more complex than it was in the days when you could just fire up tail-f on a handful of production servers and know everything about an application. In the initial design, development, and QA phase, the most important question should be “Is my code doing what the design says it should be doing?” Once it hits production, an equally important question must be asked: “Is the system handling the real world as well as we thought it would?” And you need to be ready to answer that question very, very quickly.
To do so, you can’t just monitor for the problems you might expect to see. In addition to detecting the unknown knowns, via tracking metrics, dashboards and alerting, you need to have ways to detect the unknown unknowns, such as broad anomaly detection capabilities. Sometimes the things that cause the most pain in production environments are the things you expect the least.
If you’re embracing the wonderful world of DevOps, you know that one of the most important principles is getting everyone in development and operations on the same page. That’s why it’s important to pull in the right people to make sure development and operations are working in tandem. It’s not just on the devs to know how that code is behaving in production. The ops team should also want to know about the internal monitoring and be comfortable using tools to dig.