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:
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.
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.