Beware the siren song of no-ops

Some enterprises are buying into the no-ops premise, and so are setting unrealistic expectations for what cloudops should be

Current Job Listings

No-ops is the concept that an IT environment, such as cloud computing, can become so automated and abstracted from the underlying platforms that there is no need for a team to manage the thing. The no-ops concept has largely arisen from the introduction of serverless cloud computing, and the automation that has occurred on the devops side of cloud computing.

If serverless computing systems can deal with the back-end infrastructure automatically, why not take that to the next level and automate operations completely? This means no people are involved in the provisioning of virtual servers, the changing of databases, monitoring, or the management of application workloads.

While the tools are indeed there to automate operations, the idea that you can remove people from this equation completely is pretty absurd, at least in the next five years. Here’s why:

  • Most of ops will be focused on legacy, extending to cloud computing. So the ops team needs to be focused on both, and it will need to do so under the same functional domain. You can’t remove ops from the cloud side of that. Clearly no-ops is not a one-size-fits-all solution.
  • Devops is not just about the automation of ops, it’s about people working together to continuously improve software development and operations. If that means fewer people and more automation, that’s fine. However, the notion that somehow you’ll automated everything anytime soon is just pie-in-the-sky thinking.

So, I’m okay with “fewer ops” or, as my friend Mike Kavis says, “less ops,” but no-ops is another one of those dubious “replacement” concepts such as edge computing replacing cloud computing, or data lakes replacing good database best practices.

Sadly, some enterprises are buying into the no-ops premise, and so are setting unrealistic expectations for what cloudops should be. They will be too automated, spend too much money doing so, and end up failing.

I would rather see good practices emerge around the idea of ops, including helpful automated tools. However, I would not fire your ops team anytime soon.