Operations is about responsibility, what is NoOps about?
Since the NoOps movement didn’t die out as soon as it started, as I hoped it would, I think it might be nice to illustrate why there will always be an Operations team.
Technology will constantly change, and new software is always written. In the life of a company that provides services on the Internet, databases will need to be maintained, software will need to be deployed, configured and maintained, technical security policies will need to be configured, audited, reviewed and maintained, and so will networks and servers.
If the servers are rented virtual machines or owned physical machines, it makes no difference. At some point maintenance and performance tuning configuration will need to be performed, after the initial configuration, as well as ensuring backups are made, and the variety of installations across different machines are kept up to date.
Someone has to do this work. Who will it be? It doesn’t matter. Those people are your Operations team.
Do you want your developers to be your operations team, doing installation, configuration, maintenance, system testing, upgrades, and troubleshooting of things they didn’t themselves write? Ok, you can do that. Now they are Developers and Operations people.
However, we as an industry have specialized for a reason. In the old days, all developers were also the operations people, because the systems were so primitive that the work between writing new software and installing, configuring and maintaining machines were essentially the same thing.
Over time, machines have become networked systems, and the amount of non-custom software to custom software ratio has changed quite a bit. In the beginning, the user wrote all the software the machine ran. Now, almost all the software running on any given machine was written outside the user’s organization, and the user’s organization writes a small fraction; just enough to get what custom functionality they need.
In the nonsense movement that is NoOps, the idea is that no one has to spend much time doing any work on all the software not written in-house. You develop your custom applications, and then integrate them with all the pre-written OS and application software, and the developers do all the work, automating as they go along.
In reality, there is a trade off being made silently here. Either you are accepting that developers do not become skilled Operations people themselves, creating NoOps, and then all decisions made are by definition naive decisions without experience or real-world information to back them up.
Or, you are deciding that developers must become skilled operations people who do not make naive decisions, because they become skilled Operations people themselves, switching from having a distinct pool of dedicated Operations people, to people who have to develop solutions, and then also do all the support any other Operations team member would have had to do.
Doesn’t automation solve this?
Only the easiest things are easily automated. Automation is incredibly hard to do comprehensively, and you can see this clearly by looking over any of my work on how to comprehensively automate things, which I detail in other sections on this blog.
The NoOps movement is a naive idea hidden behind the incorrect assumption that developers can easily knock out comprehensive automation that allows them to not need to become experts or spend significant time on operations problems. Even if their software and internet service operations are core to their business.
Since I worked for the organization that proposed this concept, briefly, I can see why it was created, because they have indeed turned all of their developers into Junior System Administrators, without a single Senior System Administrator in the entire organization. It’s only natural in such a place to rationalize this disaster as being a good thing, and obviously the way forward for everyone else as well as themselves. Unfortunately, their track record shows that they are not good at operations, or even doing basic availability, and there is a reason for that.
As the saying goes: “A man should always think about the source of the water as he drinks it.”
Developers’ specialization is to write software, and maintain written software. Operations’ specialization is installing, configuring, maintaining, securing and adapting a given infrastructure to custom and non-custom solutions.
Who gets paged when it breaks? Operations.
If you get rid of Operations, NoOps, then developers get paged. Now developers not only specialize in writing and maintaining software, but all dealing with all infrastructure issues.
How is this efficient? How does it build deep knowledge about the specific operations of a given infrastructure?
How does it limit movement of developers across projects, if they also need to maintain a specific infrastructure they are familiar with? Or, should no one be familiar with any specific infrastructures, so no one has deep insights on it’s workings for when it has issues or needs to be adapted for a new solution?
Answering these questions yourself should give all the personal evidence you need to understand that the NoOps movement was not well thought out. It is inefficient, and if it works at all, it does so by ensuring that beginner-level decisions are made over and over, on critical infrastructure topics.
Comprehensive automation solutions making the implementation and control over changes in production infrastructure is something I, as an Operations person, care deeply about. The NoOps movement provides nothing towards this but a pipe dream built on irresponsible suggestions that will impact the efficiency and availability of any organization who naively accepts them as a goal.
Operations groups are about responsibility over infrastructure, like developers have a responsibility to write and maintain code. How the infrastructure responsibilities are divided up will be different at every organization, but unless an organization does not care about the results their operational infrastructure gives them, they need an Operations team to manage that infrastructure. Irregardless of what those team member’s other responsibilities are.