NoOps: Divining the Future of the Network

The Rise of the Developer

Mention NoOps and you’re sure to start an argument. But terminology aside, this is a coming trend to which ITs should pay attention.

Fewer terms can anger denizens of the IT community faster than “NoOps.”

This one short innocuous term has set executives at major online companies at odds with each other and has launched a highly polarized debate on the role of operating within the enterprise – particularly an enterprise that’s rapidly moving away from traditional data centers and into the cloud.

The debate itself is loaded with buzzwords and marketing terms, and many detractors are accusing NoOps of being an empty marketing term itself. Is there substance to the NoOps movement, or is NoOps just a clever repackaging of DevOps methodologies?

Begin at the Beginning

The origins of the NoOps term seems to have come from a single source: AppFog CEO Lucas Carlson, who coined the term back in January within an AppFog infographic that illustrated how Platform as a Service (PaaS) companies like Heroku and (natch) AppFog were the NoOps wave of the future.

In 2013, the infographic continued, managed PaaS-based vendors – what AppFog classifies as the NoOps toolsets – will take the lead. With managed PaaS, the graphic asserts, developers can take complete control of application creation and deployment workflow, without involving the operations staff.

“By freeing developers to focus on what they want to do – and on what they do best – we are enabling them to even more easily start companies and build products,” the graphic stated. “And that is why AppFog is a Start-up Enabler.”

See? Told you this would be a buzzword-loaded conversation.

Not unpredictably, a lot of people called BS right from the get go.

Fire in the Hole

The flash point for the arguments against NoOps was the use of that most loaded syllable: No. The “No” in NoOps was a distinct threat to many in IT operations.

The implication of NoOps was that it would deliberately exclude operations as a functional unit within the enterprise. Actually, it wasn’t really an implication within the AppFog infographic so much as a blatant statement. Without the need for operations allegedly to bog down an agile cloud-based operation, start-ups and existing businesses could be lighter on their feet and a whole heck of a lot more efficient.

SysOps is blueray [sic], NoOps is streaming. Blueray is going to be around for a long time and there is a strong market for it. There will be people wanting to play blueray disks for decades to come. But streaming is a generational shift. [Lucas Carlson]

This might not be the best example for Carlson to have used. I can personally attest that one of the reasons I don’t own a Blu-ray player is the simple reason that I can get HD-quality video content via any number of online services. Why buy a physical medium? If SysOps (Carlson’s term for what some call DevOps) is Blu-ray, it might be present for some time to come, but it doesn’t represent growth. And in business, no-growth can easily come to represent something that holds you back.

“Netflix runs NoOps …. Netflix is a much larger example of a PaaS based NoNops [sic] organization …. We claim a competitive advantage from the agility and automation of a PaaS based product and a NoOps organization. - Adrian Cockcroft …” [Lucas Carlson quoting Cockcroft]

Cockcroft goes into lengthy detail on how data center operations at Netflix (which currently handles the company’s DVD operations) differ from the cloud-based developer-centric streaming video process. Give yourself plenty of time to read this one because it’s a stunningly clear insight into the way Netflix works.

There’s a lot in Cockcroft’s article to digest, and quite a bit that makes a good case for NoOps, but this description of how the cloud operations work seems to be the best summarization of NoOps’s benefits:

Several hundred development engineers use these tools to build code, run it in a test account in AWS [Amazon Web Services], then deploy it to production themselves. They never have to have a meeting with ITops [IT Operations], or file a ticket asking someone from ITops to make a change to a production system, or request extra capacity in advance …. This is part of what we call NoOps. The developers used to spend hours a week in meetings with Ops discussing what they needed, figuring out capacity forecasts and writing tickets to request changes for the datacenter. Now they spend seconds doing it themselves in the cloud. [Adrian Cockcroft]

Cockcroft argues quite passionately that what Netflix is doing can perfectly well be described as “NoOps” because as far as he’s concerned, operations is out of the picture.

But an operations counterpart at another popular online business, Etsy, has a thing or two to say about that.

It’s All Still DevOps

John Allspaw, VP of Technical Operations at Etsy (and veteran of Flickr and Friendster), has been one of the most vocal opponents to the whole notion of NoOps pretty much from the beginning. Back in January, Allspaw smacked NoOps around with this Tweet: “‘NoOps’ beats ‘cloud’, ‘agile’, and ‘SOPA’ as the dumbest marketing term ever coined in my field.”

Allspaw certainly saw this coming; that same Tweet pointed to a 2009 blog post of his own that decried the notion that cloud meant the death of operations.

If by “ops” you mean “people in data centers racking servers, installing OSes, running cables, replacing broken hardware, etc.” then sure, cloud computing aims to relieve you of those burdens. If you really think “ops” is just that, then you really should put down your Nick Carr book and pay attention to the real world for a change. [John Allspaw]

Allspaw continued this thread when he directly responded to Cockcroft’s recent “PaaS at Netflix” blog entry. For Allspaw, the big problem with NoOps and its proponents is that it makes certain assumptions about operations as some sort of friction-inducing organization within a company that does nothing but reflexively set up roadblocks to that company’s growth.

But operations and development each have areas of expertise that can’t be blurred into a single process under the bailiwick of development alone, Allspaw writes:

Not many Devs have deep knowledge of how TCP slow start works, but Ops does. Not many Ops have a comprehensive knowledge of sorting or relevancy algorithms, but Dev does. Ops has years of experience in forecasting resource usage quickly with acceptable accuracy, Dev doesn’t. Dev might not be aware of the pros and cons of distributing workload options across all layers 1-7, maybe only just at 7, Ops does. [John Allspaw]

For Allspaw, what Cockcroft is describing isn’t really “no” ops, but rather a very developer-centric version of DevOps. Operations still has a valid place within even Netflix’s cloud operations and doesn’t deserve the short shift the NoOps proponents seem to be giving it.

Sticks and Stones

It might seem silly to come down so hard on the use of the term “no,” but Allspaw has a very valid point. Operations is far more critical to an operation than what NoOps – intentionally or otherwise – seems to imply. Even in Cockcroft’s description of Netflix practices, he makes repeated mention of seeking out and pulling in operations folks from existing data center teams to work on new cloud teams.

As Allspaw points out, this doesn’t mean that operations is really gone, it’s just working under a different title.

Ultimately, “NoOps” might fade away as an unfortunate choice in words. But this does not negate the fact that whatever you want to call this next phase of IT, developers are clearly going to be given a lot more emphasis in IT decision making and responsibility. Whether this completely phases out the notion of a separate operations process remains to be seen, but such a move would be a foolish extreme.