NoOps: Its Meaning and the Debate around It
A year ago Forrester published the report Augment DevOps with NoOps, envisioning a not-so-distant future when some companies will rely more and more on the cloud and developers will automate even more their building, testing and deploying operations, leading to NoOps. While the term suggests that such companies will not employ operations staff, the report actually talks about operations working on better automated tools for developers, tools that require less manual intervention:
But new developments in cloud computing are ushering in a new era of on-demand infrastructure, self-provisioning of resources, and elastic application architectures, greatly diminishing the need for developers to interact with operations for releases. A DevOps focus on collaboration evolves into a NoOps focus on automation. But there is no magic — in this ambitious NoOps future, operations professionals must utilize infrastructure, working differently to enable developers to achieve better outcomes with less manual intervention. Continue to pursue DevOps, but prepare to augment it with NoOps as cloud-based services grow in popularity.
GigaOM published this year an infographic created by AppFog’s Founder and CEO Lucas Carlson, predicting that 2013 will be a NoOps year for programmers. The infographic shows how computing costs for start-ups exponentially decreased while their productivity exponentially increased as the computing model evolved from the datacenters of the 1990s, to virtualized solutions of 2000s, then to IaaS (AWS), and it received another boost from systematized SysOps Management in 2011, which represents employing advanced automated operations with products such as Chef and Puppet. Carlson appreciates that developers currently spend 60% of the time programming and the other 40% doing operations – middleware, network and virtualized hardware management, plus provisioning and security.
After another year when Application Lifecycle Management will pick up speed through PaaS solutions such as VMware Cloud Foundry or RedHad OpenShift, Carlson predicts that 2013 will be the NoOps year when start-up developers using managed PaaS solutions from AppFog and Heroku will spend only 5 % of their time doing operations – middleware, services, failover, log and audit management-, the rest of operations being done inside the cloud.
Although Carlson’s infographic referred to start-ups, Netflix is already doing NoOps, according to Netflix’s Cloud Architect Adrian Cockcroft:
Netflix runs NoOps …
All prod changes are made by the developers that wrote the code. We have some central coordination for reliability engineering that is a devops skill set (working in a dev org, and writing code, not run books), but they don't make changes, they call the dev to do it. Dev says launch new code version (pick, click) send traffic to this version of the code (click). Autoscaler figures out how many to run according to traffic. Alerts go directly to the developers, on-call rota for devs managed by pagerduty. There is no ops function or team for the product, its all development. We do have corporate ITops, for laptops, email, DVD shipping etc. but they don't deal with the streaming product.
While all this seems reasonable so far, the NoOps term has been creating waves throughout the operations community. Another No* term had similar reactions: NoSQL. Originally coined by Carlo Strozzi in 1998 to designate a SQL database without a SQL interface, NoSQL was reintroduced by Eric Evans from Rackspace in 2009 to describe data stores not relying on SQL technologies, but was later perceived by some as an affront to SQL and those who have invested many years in it. In the beginning some alluded that SQL will slightly disappear making room to NoSQL. Others sweetened the term suggesting it meant Not Only SQL.
NoOps has a similar unfortunate connotation: NO to operations, no to ops people. John Allspaw, VP Operations at Etsy, is one of the most vehement opponents:
"NoOps" beats "cloud", "agile", and "SOPA" as the dumbest marketing term ever coined in my field.
The big picture is the term has "no" in it, describing something that *has* it.
Mark Imbriaco, VP Technical Ops at
I have a bad feeling about this podcast I'm recording tomorrow with how belligerent I'm feeling about NoOps right now ...
How can you trust a NoOps spouting PaaS provider to know how to operate their own platform? Hint: You can't.
And James Urquhart, VP of Product Strategy at enStratus, expressed his disappointment with the NoOps term: “That said, my concern with NoOps isn't with the concept of devs doing everything, but with the term itself. Like early NoSQL.”
Operations is certainly going through a change. There will continue to be large enterprises running their equipment on premises, and ops will play a major role there. There will be other companies which will rely on the cloud and having less ops personnel, but the clouds have huge numbers of operations specialists. DevOps will continue to progress in other companies, with developers learning and some assuming partial operation roles. And yet in other circumstances, developers will do the minimum operations needed, the large chunk being hidden in a managed PaaS cloud. It all seems OK, but the NoOps term seems uninspired. Perhaps because one cannot build something on nothing.
Don't forget CFEngine 3
Moreover, even if CFEngine-2-the-ancient keep having bad press 4 years after its end of life, but people are starting to understand that CFEngine 3 is a complettly new thing and its ecosystem to be intersting: see for example stuff like the nice Web Interface and new user exeperience brought by Rudder, built on top of CFEngine 3.