Beware the siren song of no-ops

try {
threshold : 0, // You can set threshold on how close to the edge ad should come before it is loaded. Default is 0 (when it is visible).
forceLoad : false, // Ad is loaded even if not visible. Default is false.
onLoad : false, // Callback function on call ad loading
onComplete : false, // Callback function when load is loaded
timeout : 1500, // Timeout ad load
debug : false, // For debug use : draw colors border depends on load status
xray : false // For debug use : display a complete page view with ad placements
}) ;
catch (exception){
console.log(“error loading lazyload_ad ” + exception);

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 , 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.
  • 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 , 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 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.