NoOps appears to be the word of the month, with AppFog (amongst others) posting a “controversy as marketing” blog post titled What is NoOps anyhow?, and stating that:

NoOps doesn’t mean that operations are dead and nobody will do them

What they end with though, is perhaps the most interesting point:

Ops guys despise the term NoOps and will try to drag it through the mud.

So, as an “Ops guy”, I wondered what actually does NoOps mean, and should I despise it?

The term wasn’t invented by AppFog, I think that credit (or not) belongs to Mike Gualtier, who said:

NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them.

So how does NoOps achieve this “nirvana”? By using IaaS and Paas offerings from service providers it seems. Using these services is a pretty good idea anyway, and I’m looking forward to CloudFoundry or an alternative gaining widespread adoption.

But this NoOps movement seems to ignore the hard parts of what “Operations” is.

Operations is made up of many tasks, just a few of them are listed below:

Building new servers

Installing software

Upgrading software

Capacity planning

Performance analysis

Backups

Business continuity (Disaster Recovery)

You might look at this list and say that using a hosted platform removes the need for all these tasks, and for some (building a new server, upgrading software), you’re probably right.

But capacity planning? Your PaaS provider wants you to use more capacity than you need.

Performance analysis? Your PaaS provider wants you to buy more CPU time, not optimise your systems

Backups? Your PaaS provider will have a backup system in place, and they’ll tell you it’s working. You must perform test restores to alternative systems to actually know this.

Business continuity? Business continuity is one of the hardest problems in computing, and very few people spend the time and money to make it work. Your PaaS provider might offer something (though I can’t find one that does currently?), but as with backups, if you’re not doing regular failover tests, then the day you find out it isn’t working is the day you need it.

Beyond actually carrying out these tasks, there’s the hard decisions that need to be made around them.

Do we need constant synchronous replication to a second site for this application?

What kind of downtime can we tolerate on the main database?

These kinds of hard decisions, seemingly ignored by NoOps, are in reality the hardest part of operations.

It might surprise you to find that running a backup is pretty easy. It’s deciding what to backup and when that takes the time. And to AppFog? I don’t despise the term NoOps, but I do think it’s pretty naive.