NoOps is a New Ops: AppFog is an Ops Company

A few months back, we helped to ignite a fairly heated debate when we used the term “NoOps” in a piece published by GigaOm arguing that a new era in development is just around the corner. While we vigorously defended the term against some of its detractors, we do understand why the term awakened misunderstandings and strong feelings on both sides. This is why we feel like it’s now time to weigh back in on this debate and shed new light on PaaS in general.

Let us start by saying that our intentions in using the “NoOps” term were far more modest than some critics claimed, and we’d like to make two things clear.

First, we never meant to argue that Ops will vanish or Ops people are going to be out of a job. Ops themselves will never vanish. Things like web security, efficient server allocation, and intelligent scaling will always be important. What we were communicating is that the responsibility for dealing with Ops is not (and should not be) fixed and unchangeable. Under the right conditions, it can pass from old hands into new hands (PaaS). And this is precisely what individuals, start-ups, and now even larger enterprises have already begun to discover.

Second, this was not an attempt to denigrate Ops or the people and organizations that do Ops. How could we? Ops is the indispensable backbone of development. They demand enormous amounts of knowledge and care. AppFog is an ops company. Ops people are some of the absolute brightest people in the tech world. But that’s the point: it’s precisely because Ops are so demanding that relieving developers of this burden can be so transformative for them.

The debate around NoOps has been roughly analogous to the debate surrounding “NoSQL.” In both cases, the critics’ charge was essentially that the terms in question are glorified marketing concepts that are trying to invent something that isn’t really there. The critics of NoOps have argued that the emperor has no clothes.

But this was never our claim. Ops are not disappearing. We can’t emphasize this enough. Instead, what’s happening is that Ops are changing in ways that are transforming the whole cost structure faced by developers. As Spike Morelli helpfully notes in this article, it’s “reducing the time to market” for developers, and that reduced time can be the difference between capturing a decisive first-mover advantage and being too late to the party.

When developers are forced to take on systems admin-type tasks, these advantages are perpetually in danger. Previously, learning how to do Ops and then performing Ops over the entire lifecycle of web apps was seen as a necessary evil. It was the cost of doing business, the “you must be this tall to ride” of web development.

But one problem with this is that learning and doing Ops is immensely time-consuming. It demands that every programmer become a jack-of-all-trades Renaissance (wo)man to even hope to become (and remain) a full-time developer. Spending years to become a highly skilled polyglot programmer and master of a variety of development frameworks? Not enough. If you want to deploy, scale, and manage web apps, this way of thinking goes, be prepared for a whole lot of heavy lifting that has nothing to do with innovation.

Another problem with this idea is that not all developers want to do Ops. Rather than punishing the developer who simply wants to write code (and who is very good at writing code) because they don’t also want to be an Ops person, we should be freeing them up to do what they do best. It’s not that good developers cannot do Ops. They’re very often skilled and smart enough to do it. But they’re also valuable enough to make this a poor use of resources (and clever enough to figure out a way out of doing what they don’t want to do).

It does not have to be this way. AppFog and others in PaaS are working to change the whole division of labor in development. The principle is simple: skilled bricklayers should lay bricks, solid system admins should spend their time doing system admin work, and developers should develop. When this happens, everyone is better off.

But when skilled bricklayers are forced to spend their time doing plumbing or yard work, they waste their skills and those who would otherwise benefit from their skills and labor lose out. Why would we expect anything different when a brilliant Rails developer is forced to engage in late-night security monitoring or when a JavaScript developer with a great idea wants to learn node and Backbone but needs to take a crash course in load balancing instead?

I think that what somehow got lost in the semantic discussion was the vastly more important underlying point: that there is a real rupture on the horizon and that PaaS is already beginning to change the basic parameters of development, reducing entry costs to once-unthinkable levels. Right now, it’s doing so for developers and start-ups. Soon, it will do so for ever-larger organizations and enterprises.

To repeat: NoOps is not eliminating Ops. NoOps is decoupling Ops from Dev.

Share this post

Try AppFog: The new PaaS Hackers love