When the term NoOps was coined by Forrester last April it stirred up a lot of controversy online, especially in the DevOps camp, and the $500 price tag didn’t certainly help to drive a good conversation. The discussion has been ongoing since then with no resolution and the on and off fight over twitter and various blogs. What I’m gonna argue is that except for the random troll, everybody is working toward the same goal and the problem is terminology. But let’s start with some more information first. This week GigaOM published an infographic by AppFog on the PaaS titled ‘Why 2013 is the year of ‘NoOps’ for programmers’ to which I followed up in this blog post. Several other interesting conversations have spurred and AppFog CEO Lucas Carlson wrote a reply on the AppFog blog to clarify his position, which I really appreciated. Even better tho was John Allspaw’s comment on that post, which I encourage you to read and carefully consider.
What is that NoOps folks really want
There is historically some antagonism between developers and syadmins and that’s part of what the DevOps movement set out to fix. That said I don’t want to believe that the PaaS is a conspiracy of developers that hate sysadmins so much they want them out of the picture. It actually seems to me a very meaningful evolution of the cloud and in line with the automation that especially the DevOps movement has brought forward. In other words the goal I hear is not getting rid of ops, but rather to reduce time to market (retaining quality), which is a laudable mission and certainly something that successful companies will want. That to me is called ‘self-servicing architecture’. That is what you want. I want some too please. Does you disagree this is the future we should aim for where possible?
Engineers, developers and operators
It’s worth spending a minute clarifying who’s doing what because it will help with the conversation. There have been many articles recently on how the position of the sysadmin has evolved and certainly developers have been doing more ops work than they used to. At the beginning of my ops career I was barely asked about bash scripting while at the last interview I did for an ops position I was asked to write some python and ruby. This is a great shift and in the right direction.
Back to the operation definition problem, here’s a quote from Allspaw:
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 ... 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'
I fully agree with @allspaw and it seems that AppFog CEO @cardmagic does too based on this comment. If we agree that any good engineer will care about those things and that those things follow under the definition of ‘operations’, altho we don’t care who owns it, then how does talking about NoOps make sense? You are still doing Ops, you have just removed all that hurdle to get your code in your customers’s hands, which is what self-servicing platforms give you.
The ugly in NoOps
@cardmagic commented that:
I still think the spirit behind NoOps is much more empowering than negative, but I can understand your opposition better now
which I understand, it’s important to have that kind of empowering spirit and a name, it’s the same reason I argued DevOps as a term is very important to ensure the success of the movement.
However it’s also important to avoid picking terms that will inevitably generate bad blood. In the words of Jason Dixon:
Perhaps you /want/ the NoOps connotation to be "more empowering than negative", but by its very definition, is not.
And I think that’s where we need to get to work. If the PaaS movement wants some new term to go with it they can go ahead, I’m not sure why devops isn’t a good fit, but I don’t see a problem except maybe for further fragmentation.
However, NoOps as is is very negative term, ask anybody working with languages and they’ll tell you that starting a sentence or a word with no projects a strong negative meaning. Furthermore that doesn’t really represent the self-servicing infrastructure that is at the core of that movement (as well as of the devops movement btw), which compounds the issue.
Conclusions
I think there is strong agreement where infrastructure best practices should be going, if there are dependencies that can be removed and things that can be automated they should. There is certainly a slice of the market that can take immediate advantage of PaaS to reduce time to market, and there are realities where something like that cannot be necessarily achieved. Furthermore, nobody is questioning that there will always be the need for ops people, if nothing else by the companies building those platforms. That said the NoOps term is at best derogatory and not representing the true goal of a self-servicing infrastructure and should therefore be abandoned or replaced with something else if there really is a need for it.
If you enjoyed this article, please consider sharing it!
Words are derogatory when they are used and directed against you. If they are used in a passive manner, the term can not be considered derogatory. It also depends on the tone and way a person uses the word.
Bologna is a word. That sysadmin is a such a bologna. That starts turning the word into a derogatory term.
NoSQL is a term. Few people think that term means that “No SQL” should ever be written ever again. Even fewer people would argue that NoSQL insults everyone writing SQL. A large number of people who use NoSQL databases pair them with standard SQL databases in the same application.
NoSQL is a term that highlights a new way of thinking about databases, not a derogatory term against old databases.
This is the same spirit in which NoOps is used. NoOps highlights a new way of thinking about developing applications, where devs spend significantly less time deploying code, writing nginx configs, spawning vms, installing security patches, tuning my.cnf, etc.
Thanks guys, I just about lost it lkooing for this.
yes i am also in ops automation now
Lucas,
How much time have you spent responding to people, tweets, blog posts, etc. – all trying to convey that in using NoOps you are “not being derogatory”? How many different people within your same industry, and thus with a comparable contextual understanding, have responded to your use of the phrase stating their belief that it is dismissive of operations roles and functions and their importance?
Do the answers to the questions above tell you that the message you believe you are conveying…
…is not the message that is being heard?
NoOps doesn’t result in highlighting a “new way of thinking” – now when the response is based in reaction to the phrase itself instead of that “new way.” Not to mention that the term includes (in implication if not in intention) the perpetuation of contentious separation between development and operations – with the absurd assertion that either role has greater value (or is able to exist and thrive) without the other.
That this is the result should be enough to tell you that the term NoOps is not just self-defeating the accomplishment of your goal, but actually accomplishes the reverse: reiterating the “old way of thinking” that development can be done without operational considerations. (And insults Operations professionals as a bonus communications failure.)
If your intention is true, you need to revise the terminology you are using.
I also respectfully suggest that you consider apologizing to your Operations team. Were I a member of your Operations team, while I may see your intention, I would also hear and feel that you chose a term that appears to disparage me and my profession. That in trying to elevate developers, it didn’t occur to you to consider that you were lessening my contribution to your goals as well. That effect could very live well beyond you unapologetically attempting to explain that you didn’t mean to do so.
Hey Tom, thanks for chiming in, I think you hit the nail on the head. However, I do agree with Lucas that my choice of words was inappropriate, I should have not used the term ‘derogatory’. Ironically I ended up committing the same mistake by choosing a word that has not helped me promoting my cause, but rather created further hostility. In that sense your comment is spot on and that’s the message I really wanted to communicate. I agree on the self-servicing goal which I believe to be the new (and not even that new actually) way of thinking that Lucas is referring to. If we want a new term to highlight that, sure thing, however I rest the case that ‘NoOps’, as much as ‘derogatory’, isn’t contributing to promoting that goal, but rather just piss a lot of people off.
Adron, After your post, I asked Fancy Hands (www.fancyhands.com) to go get a list for me. Here is their list:Google Google App EngineMicrosoft Azure, C#, Java, PHP, RubyForce.com Force.comOrangescape Cross-Cloud PaaSRedhat OpenshiftActiveState Stackato multi-Perl, Python extensions to CloudFoundryAmazon Beanstalk JavaAppHarbor- NET PlatformApprenda SaaSGrid – .NETproductionCast– multiCloudBees – JavaCloudControl – PHPCloudFoundry multiCumulogic – JavaDeployinator multiDotCloudY– multiEcholibre Orchestra PHPEngine Yard – Ruby on RailsGoogle AppEngine –Java, PythonHeirloom Computing Elpaas – COBOL, CICSIBM Workload Deployer – JavaLongjump PaaS JavaMendix –JavaMule iON- JavaNodejitsu – Node.jsNodester Node.jsOrangeScape -graphicalPhpFog –PHPprivate betaSalesforce Heroku (Ruby) – Ruby on RailsSalesforce Heroku (Node.js) – Node.jsWolf Frameworks cgaphiralWSO2 Stratos Javabeta Hope it helps.
I also posted this directly on the appfog blog (http://blog.appfog.com/what-is-noops-anyhow/), where he continues along his lines above, and seeks feedback.
Lukas,
There is a big difference between the terminologies NoSQL and NoOps, where the term NoSQL was supported with a much better idea that was attractive to the whole industry. Where as NoOps was a part of business idea, and it was less explained. Infact the actual explanation came only after a bunch of debate. The much better terminology for the so called “NoOps” is the PaaS itself. Lets seperate NoOps from it.
[...] 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, [...]
I have a few comments on this. First, NoOps has cutaally been around for a while in numerous guises. Shared hosting is NoOps you can build an app and deploy it without doing sysadmin. Second, the exponential efficiency gains are only realized if developers are sharing resources and are therefore limited on some elements of the system’s configuration. Otherwise, each environment has to be managed separately and it becomes and outsourcing/managed services model rather than a leveraged automation model.I think PaaS and NoOps is a great model for startups, as suggested by the infographic, because the developers can focus on building quickly and avoid operational hassles as they try to find their market. But in a scaling mode, the startup’s need to both develop profitable economics and add capabilities that may not fit the PaaS provider’s model means that many will have to leave this constrained environment for one with more control thus bringing back the system administrator.451 Group talks about Auto-Ops the idea of automating system admin. This is a related idea and it has its own set of strengths (more flexibility) and shortcomings (less granular scaling, still requires a systems architect somewhere in the process). So, while I think this is all good stuff, it really remains to be seen how important a role it will play. In some ways, it really is just a more scalable and reliable version of shared hosting which is a huge market, but not appropriate for everything.Finally, I have a different reason than others for not liking the term NoOps. No-Op is a machine instruction in most CPU architectures that burns an instruction cycle with no effect (NOP in 8086 architecture). Thus, in some circles, the term no-op refers to someone or something useless. I don’t think this idea of leveraging a pre-configured ops platform is useless, so I don’t like the name.