I’m trying to understand the difference between these three so that I can understand my customers better. It’s not obvious because everyone has a different opinion about where the lines fall between them – or even if there is a line. This is important because you can assume that customers in the different segments have difference needs for an observability solution. Here’s my best take on how they’re different and where those differences matter the most.
In traditional IT organizations, developers and systems administrators have opposing goals. Developers want to build features, innovating and creating new value for customers. On the other hand, System Administrators want to ensure that the deployed software will be reliable, performant, and secure, creating value for the business and customers. Because these two sets of people in an organization have different goals and don’t talk often, there is friction and software is released as smoothly as the business would like. When I think about these organizations that practice traditional IT, I think about my time at NetApp. When we identified a new application we wanted to build, we couldn’t just start writing code and deploying. First, we had a go through a lengthy process to get a VM from IT. They had to get information about how much storage, CPU, and memory was needed before provisioning the VM. Once we had it, we could deploy code to our 1 VM. This is solidly in the ITOps segment of the population. We could do some DevOpsy things to deploy code but we were always sitting on an ITOps framework for getting the necessary infrastructure.
Had we been practicing true DevOps at NetApp, we would have been able to deploy the infrastructure we needed – without asking a separate team. Other than the actual infrastructure being deployed through tickets, we did a lot of the other things necessary to claim DevOps. On DevOps teams, the team is responsible for the development, QA, deployment, infrastructure management, monitoring, and support of the application. The team may contain people with a role specific to one of those tasks or a team of generalists where anyone could manage any of the tasks. Either way, since the team is responsible for the operation of the application, they take on the new set of tasks. I’ve found that this causes the team to consider the impact of changes more and potentially be more careful. Nonetheless, DevOps teams can deploy faster and more dependably, helping to accomplish business objectives faster.
Finally, at some point, DevOps moves into NoOps – where automation and PaaS allows developers to deploy without the need to understand the infrastructure. The line between DevOps and NoOps is a bit murky to me but I think the main point is that the ‘Ops’ in NoOps has been minimized away so that it is trivial for the developer to execute. It’s worth pointing out that even in a NoOps practice, you would still expect some teams in the company to practice DevOps, as seen from Adrian Cockroft’s experience at Netflix. Those teams could be responsible for the platform or the automation that is making NoOps possible for the product developers.
I read a lot of content to try to understand this; here are a few links that I found especially helpful: