NoOps: The Good, the Fad and the Ugly
NoOps: The Good, the Fad and the Ugly
Join the DZone community and get the full member experience.Join For Free
Do you need to strengthen the security of the mobile apps you build? Discover more than 50 secure mobile development coding practices to make your apps more secure.
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.
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.
Opinions expressed by DZone contributors are their own.