I recently attended DevOps Days Portland, where Kelsey Hightower gave a nice Keynote about NoOps. I had heard of the terms NoOps in passing before the conference but never really thought much about it or its implications. Kelsey’s talk started to get me thinking more and more about the idea and what it means to the DevOps world.
For those of you who aren’t familiar, NoOps is a newer tech buzzword that has emerged to describe the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.
Obviously the term NoOps has caused some friction between the development world and operations/DevOps world because of its perceived meaning along with a very controversial article entitled “I Don’t Want DevOps. I Want NoOps.” that kicked the whole movement off and sparked the original debate back in 2011. The main argument from people who work in operations is that there will always be servers running somewhere, as a developer you can’t just magically make servers go away, which I agree with 100%. It is incredibly short sighted to assume that any environment can work in a way where operations in some form need not exist.
Interestingly though, if you dig into the goals and underlying meaning of NoOps, they are actually fairly reasonable to me when boiled down. Here are just a few of them, borrowed from the article and Kelsey’s talk:
- Improve the process of deploying apps
- Not just VM’s, release management as well
- Developers don’t want to deal with operations
- Developers don’t care about hardware
All of these goals seem reasonable to me as an operations person, especially not having to work with developers. Therefore, when I look at NoOps I don’t necessarily take the ACTUAL underlying meaning of it be to work against operations and DevOps, I look at it as developers trying to find a better way to get their jobs done, however misguided their wording and mindset. I also see NoOps, from an operations perspective as a shift in the mindset of how to accomplish goals, to improve processes and pipelines, which is something that is very familiar to people who have worked in DevOps.
Because of this perspective, I see an evolution in the way that operations and DevOps works that takes the best ideas from NoOps and applies them in practical ways. Ultimately, operations people want to be just as productive as developers and NoOps seems like a good set of ideas to get on the same page.
To be able to incorporate ideas from NoOps as cloud and distributed technologies continue to advance, operations folks need to embrace the idea of programming and automation in areas that have been traditionally managed manually as part of the day to day by operation folks in order to abstract away complicated infrastructure and make it easier for developers to accomplish their goals. Examples of these types of things may include automatically provisioning networks and VLAN’s or issuing and deploying certificates by clicking a button. As more of the infrastructure gets abstracted away, it is important for operations to be able to automate these tasks.
If anything, I think NoOps makes sense as a concept for improving the lives of both developers and operations, which is one facet that DevOps aims to help solve. So to me, the goals of NoOps are a good thing, even though there has been a lot of stigma about it. Just to reiterate, I think it is absurd for anybody to say that jobs of operations will going away anytime soon, the job and responsibilities are just evolving to fit the direction other areas of the business are moving. If anything, the skills of managing cloud infrastructure, automation and building robust systems will be in higher demand.
As an operations/DevOps person just remember to stay curious and always keep working on improving your skill set.
