NoOps, ShmoOps and Somebody Else’s Problem

March 21, 2012 by kowsik

This week there’s been much talk about NoOps with posts from @adrianco, @allspaw and @krishnan, to name a few. It all started with this infographic from @appfog. The challenge is that the combination of the words No and Ops is wide open for [mis]-interpretation.

Somebody Else’s Problem

I think what we are witnessing is rapid emergence of services that started with the infrastructure (storage, compute, network) and rapidly moving up the application stack. PaaS, of course, is the latest of these services allowing developers to not worry about servers and OS and instead focus on their app. Our own cloud offering Blitz.io has its web tier hosted on Heroku.

We use TenderApp for support, Sendgrid for email, Campfire for IM, GitHub for revision control and issue tracking and Heroku again for Continuous Integration. Of course, we also run our own CouchDB instances on EC2 and all of the scale engines are also on EC2. In this sense, Blitz is a hybrid PaaS/DevOps application. We manage our own scale engines across all 8 regions of EC2 and while we don’t have IT watching over these, the developers do get operational visibility.

But the Heroku tier? It’s Somebody Else’s Problem. And I think it’s in this sense NoOps makes sense (to me). Obviously Heroku has their team (call it IT, call it Ops, call it DevOps) watching over their dynos to the point we don’t have to care (for the most part).

IT vs. Ops vs. DevOps

Way back when we started the company, I remember having to spec a build machine and we paid a good $6K (IIRC) on this thinking it was going to last us a few years. Didn’t even come close. At the end of the first year, we maxed out and over time, there were RAID failures, memory upgrades, OS and the software maintenance, security patches, etc, etc. Of course all of this done by IT with developers complaining that builds were taking long.

Fast forward to now, with Continuous Integration running on Heroku’s Cedar Stack with GitHub’s post-commit hooks, all of those concerns went out the door. And there’s no IT. But guess what? If Heroku or GitHub goes down, we are fsck’d. If GitHub gets hacked with a Rails vulnerability, we can’t do anything about it. We have to watch their status pages and wait until all of those Elevated Error Rates go away. So by giving up server-hugging and control, we saved operational costs and headaches, but still trapped by the S.E.P. field.

NoOps

DynamoDB from Amazon is a great example of NoOps (in my sense of what it means). Running a highly scalable, fault tolerant database is not easy, by any stretch of imagination. You just have to read a few of @adrianco‘s blogs to see the time investment and expertise it took to build a global Netflix application. A small startup trying to do this? I don’t think so. It takes a level of operational maturity and excellence to pull this off. And there in lies the beauty of NoOps. It lets me focus on my app/data and let the operations be Somebody Else’s Problem.

Just like PaaS is enabling a whole class of developers (and non-developers – awwwwwwwwwww!) to get an app running without worrying about servers, the NoOps movement is going to allow large classes of developers with no IT/Ops experience to build amazing apps. And in the long run, that’s a good thing™

Categories: Cloud, DevOps
7,575 Comments
Bookmark and Share