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.
Traditionally 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.
This is a perfect fit for BMC’s Service Blueprints, because trying to do NoOps by scripting, or suddenly dropping this approach into an existing organization without warning, is a recipe for disaster. The Service Blueprints allow developers to design for the entire application lifecycle, or rather, for the entire lifecycle of the business service which that application implements, and hand that over to automation for the delivery.
What do you think? Is the world ready for NoOps? Are you ready for NoOps?