The DevOps – NoOps Debate

A catchy new term can cause quite a lot of misunderstanding when it is picked up with enthusiasm by IT journalists. The cloud will, in time, allow us to outsource some of our Ops chores to Platform service-providers, but there will still be a need for those who are responsible for applications to be able to administer them in production wherever they are deployed.

It all started when GigaOM published an infographic, “Why 2013 is the year of ‘NoOps’ for programmers” created by Lucas Carlson, CEO of AppFog. Now, NoOps is not a new concept. In fact, this was not even the first time someone used the phrase NoOps to talk about the advantages brought by platform services.

In April 2011, Forrester published Augment DevOps with NoOps, which states that “the goal of NoOps is to completely automate the application deployment (aka Lifecycle management), monitoring and management of infrastructure”. In November 2011, ReadWriteCloud published an article, “From DevOps to NoOps: 10 Cloud Services You Should Be Using“. Even then there was not much public debate about this within the community. But, since GigaOM published this sponsored article, as some commenters have claimed, a number of people have come out against the idea of NoOps and claimed that the role of DevOps is not going to diminish in the near future. Carlson has had a tough time explaining his stand to the community. Here are some of my thoughts on NoOps and why it’s not a compelling concept.

 Pre NoOps – DevOps

Before we proceed, let me tell you something about DevOps. Wikipedia defines DevOps as a

set of principles, methods and practices for communication, collaboration and integration between software development (application/software engineering) and IT operations (systems administration/infrastructure) professionals.

As a descendant of Agile development methodology, DevOps is inherently agile. Thismakes it applicable in a wide range of contexts, especially to companies that have frequent release cycles. DevOps aims to ensure continuous delivery and consistency, focusing on the ability of systems to dynamically adapt to business requirements. Specifically, DevOps makes use of automation to streamline the application lifecycle. A DevOps-toolchain has been created to help with parts of this process, such as automated provisioning, managing VCS, issue tracking, deployment and so on. As a whole the process brings agility to a business through a better alignment of its IT provision. To achieve these goals, DevOps professionals interact with developers, operations, and QA. Consequently, software engineers working in DevOps require a certain level of operations knowledge and involvement.

 PaaS and NoOps

So-called NoOps can be considered a by-product of PaaS. PaaS, by definition, is a cloud service delivery model and one of the most important evolutions of the cloud concept. It’s a place where people can try out their ideas with much lower upfront costs. Start-ups can easily bootstrap their ideas without having to worry about infrastructure, enabling them to market products quicker than the traditional route. PaaS also has many other advantages that are already well known.

On the other hand, PaaS can’t cut down costs exponentially, as claimed in Carlson’s infographic. For instance, if you go for the Gold cloud from PHPFog (who offer comparatively attractive pricing, I acknowledge), it will cost around $1000 a year. Compared with the cost of buying the hardware, you can easily own one or two such servers. For an actual cost cutting, many organizations will look for a hybrid cloud strategy where they can integrate existing infrastructure with cloud. Any PaaS service is not going to be that cost effective beyond a certain point. Also, PaaS doesn’t get rid of Ops. Instead, someone else, at a Cloud provider, is doing much of the Ops for the consumer.  At most, PaaS merely separates Ops from the developers and provides it as a service. And that’s why even people from AppFog are annoyed by the phrase NoOps. From the PaaS consumer perspective, I don’t think you can simply sit, code, and later deploy your application without worrying about scalability, monitoring, and any other Ops jobs. You should definitely monitor the application, gather metrics, and optimize the environment and application to the best possible level. If this involves any monitoring tool or service at all, you need to make sure its functioning well. All of these are nothing but Ops jobs.

Allspaw makes this clear from his comment on “What is NoOps Anyhow?.

Are you

– Gathering metrics on how your application is performing? Congrats, you’re doing ‘operations’

– Taking action (automated or not) based on feedback loops that you’ve built around faults and performance of your application? Congrats, you’re doing ‘operations’

– Alerting someone to complex failures? Congrats, you’re doing ‘operations’

– Making informed decisions about datastores, external APIs, storage, etc. based on technical requirements? Congrats, you’re doing ‘operations’

In his later explanation AppFog blog, Carlson agrees there is a certain level of Ops in NoOps.  He says

“the point isn’t that ops are going away, but they’re going away for developers”.

But there is also another problem. In so-called NoOps, where developers consume PaaS services and the providers do the rest for them, the aforementioned responsibilities will fall on developers. Eventually they will become Devs+Ops.

Adrian Cockcroft from Netflix argued that they run NoOps. But it is clear from his later comment that they make use of DevOps to meet the market dynamics, and that’s not NoOps. They have a reliability engineer with a DevOps skillset, who doesn’t code, but communicates with Devs to make changes.

I would say NoOps can’t be used in the same context where we use DevOps. Or, rather, do not use NoOps for the time being. Let’s reserve that word for something in future. We are all concerned with solving business problems, rather than political issues. So-called NoOps is a political problem, and it cannot solve business problems. DevOps, on the other hand, enables organizations to react to market requirements quickly, which means it can solve business problems quickly.


NoOps is actually a bad name for an apparently good idea. But it won’t solve the problem even if we call it LessOps; I am sure there are plenty of Ops peoples in AppFog. Apart from that, from the consumer side, someone needs to monitor the service and decide the strategies. One of the problems with the “AppFog NoOps” movement is its bias towards start-ups. Most of the metrics in the infographic are talking about the differences for start-ups in the PaaS and noPaaS eras. But there is a much, much bigger community outside which doesn’t fit in this movement.

Starting a new business is not all about launching an instance from the dashboard. There are many Ops activities involved. Organizations will need to find their own way to minimize the cost and increase the profit. So there is always room for Ops and, like Spike Morelli said, “The year of NoOps will never come“. People will continue to call so-called NoOps “PaaS”. Let’s try not to mix the two. It’s quite certain that PaaS has its own potential market and it will flourish in 2012-13, but not because of NoOps. It’s because of the advantages of PaaS such as lower upfront cost, less risk, and faster time to market that’s going to make it a success.