ITOps, DevOps, and NoOps Explained

To my relief, new terms are emerging that are even more buzzwordy and fashionable than “cloud”. The specific examples I have in mind are DevOps and its younger cousin, NoOps.

difference between itops and devopsTraditionally there has been a split, not to say a wall with spikes on top and a trench filled with fire, between IT operations and application developers. In this mode, developers write and package the application, and then throw it over the wall for IT to deploy and manage. Of course this can lead to issues, such as unproductive blamestorming meetings where sysadmins accuse coders of incompetent development, and coders deride sysadmins for being overly cautious stick-in-the-muds who won’t deliver what the apps team needs.

DevOps is basically the latest spin on the long-standing notion that developers should have the competence and access rights to do their own administration, at least for the pre-production environments. Of course this can cause problems in the hand-over, especially around documenting requirements and dependencies, but the DevOps view is that having IT in the loop for every change is just too much of a bottleneck, especially for the rapid deployment cycles associated with modern web applications.

NoOps is the extension of this concept to the idea that IT should not be in the loop for any actions. In this view developers do not simply release their code to an environment which is designed and managed by a separate ops team. Instead developers take over all responsibility for architecture design, capacity planning, performance optimization, and so on.

This of course makes perfect sense. The major cause of outages is human error, and not necessarily the fairly obvious moment when the poor overworked sysadmin realizes one oh-no-second after hitting Enter that he was not where he thought he was. The major cause of outages is complexity, so the issue is the valid change that is made here but not there, or the upgrade that happened to one component but did not flow down to later stages of the lifecycle. These are the types of human error that can either cause failures on deployment, or those more subtle issues which only show up under load, or every second Thursday, or only when the customer’s name has a Y in it. Instead NoOps aims to eliminate downtime and improve performance by removing every possible human intervention and hand-over, and instead allowing one single original design, created by the developers who understand the system, to propagate everywhere automatically.

In this world there is still a role for IT, but it moves away what I once heard a sysadmin friend describe to a colleague as “monkey-compatible tasks” – basically low-value-added, tactical, hands-on-keyboard activity. Instead the IT team has a more consultative and strategic approach, working in partnership with developers and other users of IT infrastructure to ensure that they all have access to what they need without bottlenecks or barriers to entry.

Last updated: 1/7/17

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post

Dominic Wellington

Dominic Wellington

Dominic Wellington is BMC's Cloud Marketing Manager for Europe, the Middle East and Africa. He has worked on the largest cloud projects in EMEA, and now he calls on that experience to support new cloud initiatives across the region. Previously Dominic supported BMC's automation sales with direct assistance and enablement throughout EMEA. Dominic joined BMC Software with the acquisition of BladeLogic, where he started up Southern Europe pre-sales operations. Before BladeLogic, he worked in pre-sales and system administration for Mercury and HP. Dominic has studied and worked between Italy, England and Germany.