What is NoOps anyhow?

Since having our infographic published on GigaOm, there has been a lot of controversy and FUD around “NoOps”. Paul Graham recently wrote about schlep blindness. NoOps is a response to the schlep blindness of developers doing SysOps.

What does NoOps mean:

  • NoOps means developers can code and let a service deploy, manage and scale their code
  • NoOps means automated systems like CloudFoundry managing app lifecycles, not SAs
  • “the point isn’t that ops are going away, but they’re going away for developers” – Derrick Harris at GigaOm

What does NoOps NOT mean:

  • NoOps doesn’t mean that operations are dead and nobody will do them (like this tweet thinks)
  • NoOps isn’t a job role (like this tweet and this tweet thinks)
  • NoOps isn’t blissful ignorance (like this tweet thinks)
  • NoOps isn’t marketing fluff made up by non-technical idiots (like this tweet and this tweet thinks)

This is the true spirit of NoOps:

“Netflix runs NoOps … Netflix is a much larger example of a PaaS based NoNops organization … We  claim a competitive advantage from the agility and automation of a PaaS based product and a NoOps organization.” - Adrian Cockcroft, Cloud Architect at Netflix (read more)

And this:

malminhas
From DevOps to NoOps via PaaS. Am +1 for devs doing more dev and less ops

Short history of SysOps

The growth of the SysOps movement has been driven mainly by developers who were tired of two things:

  1. Developers tired of waiting for systems administrators because they did their work inefficiently
  2. Developers tired of doing the work of systems administrators inefficiently

Why is it so hard to hire SysOps roles?

Because most SA’s aren’t versed in the programming needed to manage SysOps and because most developers who can use SysOps tools don’t want to spend their time doing SA.

Since SysOps roles are so hard to fill,  what usually happens is all the developers at a company become responsible for handling ops through the SysOps tools (read SiliconANGLE to hear a contrary opinion to why schlep should stay).

SysOps is adding more horses to the carriage. NoOps is the car.

I understand why legendary ops guys like John Allspaw (Flickr, Friendster, Etsy) are scared of a term like NoOps and resort to calling it names.

allspaw
“NoOps” beats “cloud”, “agile”, and “SOPA” as the dumbest marketing term ever coined in my field. http://t.co/53On2fZf #devops



NoOps is not for ops guys. It’s for developers. More dev and less ops.

It is not a job title because with NoOps, you don’t grow by adding headcount to your ops team. You grow by moving sliders. You grow by connecting managed services together. You grow by focusing on your core competency: coding.

Doesn’t this mean ops are dead?

No. SysOps is blueray, NoOps is streaming. Blueray is going to be around for a long time and there is a strong market for it. There will be people wanting to play blueray disks for decades to come. But streaming is a generational shift.

SAs and DevOps guys are always going to have a place to work. As long as there are datacenters, you will always be able to get a job at AWS, Google, TerreMark, etc. etc. As long as there are legacy systems, SAs and DevOps will be employable positions. That is not going away any time soon.

NoOps is for developers to focus on core competency

Ops isn’t a core competency or differentiating factor for many high tech startups. Ops is a necessary schlep for most high tech startups.

Customers don’t choose between groupon and livingsocial based on how well they hook their nginx confs together. Assuming NoOps services like AppFog and Heroku did just as good a job if not better than an in-house ops team, NoOps enables you to build and run high tech startups and enterprises without investing as much in the ops side.

Conclusion

Ops guys despise the term NoOps and will try to drag it through the mud. There is no need. NoOps is not the antithesis of ops. NoOps is simply recognizing inefficiencies for developers and optimizes around it.

NoOps is happening whether people want it to or not. Developers are driving it. They are driving it at startups, they are driving it at SMBs, they are driving it in enterprises. All NoOps does is give this shift a name.

Share this post
Facebook Twitter Google
Try AppFog: The new PaaS Hackers love
  • WAlbenzi

    Please tell me if I misunderstand:
    NoOps means that most of the infrastructure is outsourced to PaaS providers in certain businesses.  This leaves developers to care about code.  The spectrum of code that the developers who operate in those business models will create and maintain is the application, the integration, testing, deployment, performance/utilization monitoring, security, and incident response code and systems.  NoOps also inherently recognizes that tools will continue to evolve which make developer tasks easier (such as better IDEs, CI suites, provisioning and monitoring tools).  This means that performance of individual contributors will increase.

    If I understand it, it sounds to me like there might be a use for those developers who are more focused on the latter part of that spectrum of code.  Those developers will of course not be isolated from the developers who are more focused on tasks in the first, because they are all developers with the same goal of delighting the customers.  

    Do I get it?

  • http://pulse.yahoo.com/_26OHXOWZTI67FAW2VSGUB6UU4Y Allspaw

    Lucas: like I said before – there’s too much to be discussed in 140 characters, and my opposition to the term is misunderstood. I’m disappointed that a better conversation cannot be had.

    Again: my opposition is to the *term*. Because it’s not “No” operations, as defined by you or Adrian. Operations is still going on, as a domain expertise. Who owns these topics matters little to me.

    If you’re a good engineer, then you are not ignorant of things such as:

    - fault tolerance
    - availability
    - performance
    - monitoring

    in fact, you care about them greatly, as you should. This is the case with on-premise capacity, cloud capacity, Paas, or any other resources that you use to deliver the value of your business.  I’m willing to bet that any of AppFog’s customers care about these things, and Netflix is certainly hiring people who care about those things. If I were to look at modern Ops teams, only a tiny slice of what they do could be classified as traditional systems administration. Systems Administration != Web Operations, not unlike how Computer Science != Web Development.

    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’

    So ‘NoOps’ is still doing operations, unless you don’t care about the above things.
    This definition that I have for ‘operations’ is not just mine.

    If physical management of servers and manual install/deployment is what you mean by ‘Ops’, then I’ll argue that the definition needs to be updated. ‘NoRackAndStack’ is better than NoOps, and I’d accept and welcome that.

    All startups are resource constrained, obviously. So developers are usually the people also making early design decisions for this reason. Would you call this “NoDesign”? Design is obviously happening, but the term doesn’t communicate this. In fact, it’s communicating the exact opposite, due to the “no”.

    I truly do understand (and actually welcome!) the intent behind “NoOps”, that you’ve taken the time to explain. But I maintain that you’re going to continue to meet confused people by using the term, because it’s not clear.

    And is “devops” any clearer? Maybe, maybe not. But at least there’s not an affirmative or negative in the term to add to any confusion it has already.

    I hope that helps, it’s longer than 140 characters. :)

  • Anonymous

    Thank you for your excellent and thoughtful reply. I agree there is a level of “ops” even in NoOps. That is reflected in the infographic we built (see the pie chart over time and technology). I still think the spirit behind NoOps is much more empowering than negative, but I can understand your opposition better now.

  • Anonymous

    Absolutely right!

  • http://twitter.com/obfuscurity Jason Dixon

    Perhaps you /want/ the NoOps connotation to be “more empowering than negative”, but by its very definition, is not.

  • WAlbenzi

    Since it turns out I understand, I would assert that those developers who are more concerned with the later part of the code spectrum are engaging in tasks normally handled by an Ops team.  I would further assert that the emerging practices known as DevOps enable the behavior you are describing, which seems to be more communication between traditional development roles and traditional ops roles.  

    I don’t think it is correct to call the practice NoOps, because both Development and Operations roles are changing and adapting to the growing power of the tools at their disposal.  

  • http://www.facebook.com/cardmagic Lucas Carlson

    Just because devs are currently engaged with ops through sysops doesn’t mean that is how it should be done, nor that it is the better behavior for developers.

  • WAlbenzi

    Please answer, as I am genuinely curious:

    I guess I do not understand what alternative to “Someone doing tasks traditionally associated with Ops engaging with people who do what is traditionally considered development” is being offered.  Two specific questions:Fist, if you accept that “You do what you are doing.”, Isn’t it true that a Developer who is performing tasks normally associated with Ops could be said to be “Doing Ops”?
    Second, if it is true that people who specialize in a thing often become better at that thing that people who do not, then doesn’t it follow that a developer who specializes in the tasks normally associated with Ops should leverage that ability for the benefit of the organization?Possible answer:It might be that you believe that “Doing Ops” will not need a on-staff specialist any more that you need an on-staff specialist to refill a car’s gas tank.  If you believe that, I would ask that you visit http://www.thegaspumpstore.com/pumps.htm and think about the rate of change to the interfaces we use.  Is AppFog nearly finished innovating?

  • http://www.facebook.com/cardmagic Lucas Carlson

    Yes, developer who is performing tasks normally associated with Ops is “doing ops”. What I am saying is that provided an alternative like PaaS and NoOps, developers time would be better spent developing and innovating on the product rather than the ops to run the product.

    AppFog is not even close to finished innovating.

  • Tyler McMullen

    1. Pick provocative name.
    2. Portray those that are bothered by it as dinosaurs.
    3. Profit!

  • WAlbenzi

    We agree that Developers are best utilized doing development.  Operational implementations are still changing rapidly and expected to do so for quite some time.  These implementations are best understood by domain specialists.  In order to give the customer what they want we need an excellent product that is produced and delivered in a way that is as cheap and reliable as we can do it.

    I am walking away with the idea that NoOps means that Ops will best be done by Devs who specialize in Ops.  But in spite of their specialization in Ops they must not be called Ops.  Because…

    Ultimately, as long as you are doing Ops, by people who specialize in Ops, you can call it anything you like.  Except Windows-Admin, because that is just a mean thing to say…

  • http://www.paulgraydon.co.uk Twirrim

    NoOps is fundamentally the wrong term, you’re not actually getting rid of Ops.  Ops is more than hardware, more than software deployment, more than infrastructure management.  If anything you’re pushing things even stronger towards DevOps.

    Ops goes right down to the balls of the application, down to performance, scaling and software choice too.  You talk about devs doing that seemingly without realising that is absolutely what Ops is, and it has been for a long time.

    Very few sysadmins in the internet side of the field sit high and mighty about the application and say “Well, it’s running a bit slow”.  We’re in there looking at it, working with the developers to figure out exactly why, offering ideas from both a macro and micro infrastructure perspective.  We’re polyglots, jack-of-all-trades, part developer (do it twice, script it once), part DBA, part security analyst, part network specialist, part storage advisor.  Monitoring never provides the full picture.  Good Ops oriented developers know this, just like we do.

    Just adding another instance will not fix fundamental flaws in the approach taken to solving a problem.  In fact it could be the worst thing to do, exasperating or masking the situation rather than resolving it.  You know this.  You must do, just building something on the scale you are with AppFog must have brought you up against this at least once.

  • http://www.spikelab.org Spike Morelli

    Hey Lucas,

    thanks for the post and great discussion overall. I think there’s a lot of good in what you guys are doing and we need to try and resolve the conflict over terminology. I’ve written up some more thoughts here I’d like your opinion on:

    http://bit.ly/yAPE4o

    thanks

  • Anonymous

    Ops will be best done by tools like CloudFoundry and managed PaaS platforms like AppFog. 

  • http://www.belowtradeprices.co.uk/serve-over-counter.aspx Serve Over Counter

    ‎”NoOps means developers can code and let a service deploy, manage and scale their code” 

  • http://www.notarypublicwinchester.com/ Notary Public Winchester

    Hi
    I believe other website owners need to take this website as an model, quite clean and excellent user pleasant pattern . 

  • stupiddeveloper

    I love all the hate from ops… you mad? Getting phased out is painful :)

  • http://blog.cobia.net/cobiacomm/2013/04/19/devops-ticket-reduction/ DevOps Ticket Reduction | From the HomePort @cobiacomm

    [...] automating repetitious tasks, and accelerating business innovation iterations.  While the ‘NoOps‘ model is subject to confusion and derision, reducing manual activity and operation desk [...]

  • https://blog.logentries.com/2012/02/digging-into-engineyard-logs/ Digging into Engine Yard Logs | Logentries Blog

    [...] managing your instances and you worry about writing your apps (what is being referred to by some as NoOps these [...]

Powered by Olark