DevOps or NoOps: Can You Have Too Much Automation?
Some DevOps thought leaders have been promoting “NoOps,” which is the notion that IT resources can be provisioned in a fully automated way that does not require operations engineers to manage. NoOps is not really new. Lots of folks use continuous integration servers to provide build engineering services without having a specific person actually perform this role.
But NoOps takes things a step further: Your data center is actually lights-out, with no personnel on premises. You can think of NoOps as the point at which we have robotic resources to help us run our data center.
IT controls exist to avoid mistakes and ensure that big corporations, such as banks and trading firms, meet regulatory requirements to protect their shareholders and people who depend on their services. Medical supply firms also have to follow similar requirements as part of HIPAA and CFR 21. What if we could have the same level of control without the expense of hiring people to perform this role? Microservices may provide the technical means by which to accomplish part of this goal.
In microservices, we create systems that are complete entities and deploy them as packages or, often, as containers. When you need to fix something, you don’t log into the production machine; you fix the code and push the button for your automated build, package, and deploy procedures to continuously deploy updates. There have been notable successes with this approach, but also some challenges.
I see two challenges with NoOps. The first is that it tends to be an excuse for allowing developers to bypass controls and get access to production. The ideal of headless servers is, well, an ideal—that is, not always practical.
But there is a far greater issue: Expert operations engineers have specialized skills that we need on our team. Technology today can be complicated, and finding specialized expertise in storage systems, networking, and systems administration is not always easy. We actually need real Ops teams, but we need them to be able to operate effectively in a dynamic environment.
I find that the notion of NoOps often comes from folks who are frustrated with operations engineers who lack the skills and expertise required to do the job. So, in my opinion, we need strong operations engineers who work as part of our cross-functional DevOps team.
Now, this does not mean that we cannot benefit from extreme automation too. Providing resources that can be self-provisioned and fully automate build, package, and deployment scripts is an absolute must-have. But these capabilities should just be part of our effective and agile Ops.
I don’t want to do away with operations. What I want is SuperOps: a dedicated group of top experts who get the job done while delivering value to my customers. Let’s strive for that cross-functional, high-performance team.
