It’s often easier to talk about what NoOps isn’t than what it is.

It doesn’t mean you fire your Operations team. It doesn’t mean the end of Operations, or that Operations is dead.

So just what is it? To explain NoOps, we must first explain DevOps.

A DevOps primer
DevOps is a software development model designed to help developers and Operations work together. Developers and Operations have natural conflicts based on their mandates:

Developers build features and software, often criticized as throwing them over the wall to Operations.

Operations wants to keep the services running in a stable environment with as little change as possible, often criticized as being slow or blocking change.

Really, it all comes down to communication.

DevOps aims to resolve these conflicts by getting developers and Operations to talk to each other (gasp!) and make the whole process more cohesive. Aligning the teams just makes good sense. Create one team with one mandate: ship, implement, test and deploy quality software fast. Great teams were doing this long before the term DevOps was coined.

How DevOps works
Many organizations focused on processes, tools and people.

  • Process: Operations uses software development techniques to speed up the release cycle, resolve conflicts early and get people talking.
  • Tools: Configuration-management tools like Puppet or Chef and version control create and maintain the operational infrastructure and assets.
  • People: An operations engineer embedded into a development team as a dedicated resource focuses directly on the team’s deliverables.

Stepping up to NoOps
DevOps is an important incremental step toward something more. Almost all of the problems the DevOps movement tries to solve are based on the idea that the development, deployment and reliability of software are very different things. Most DevOps strategies focus only on Operations as a bottleneck, but fail to consider how Development could make software more operationally friendly, or how that software might work in production.

With NoOps, developers deploy and scale their own code and apply equal importance to acceptance criteria. It’s not “done” until it’s in production with Continuous Delivery, metrics and monitoring. It’s a system designed to operate as a whole, as a single artifact.

(Related: How to plug into DevOps)

NoOps is based on the belief that the operation, development and delivery of software are equally important. Sometimes referred to as the “You build it, you run it” model, NoOps brings developers in close contact with the day-to-day operation of their software—and the responsibilities that come with that.

Can’t we all just get along?
The approach is sometimes criticized for putting more responsibility back to Development and leaving Operations to do… just what, exactly?

I beg to differ. The criticism is based on the idea that Development and Operations are separate to begin with, or that Operations just doesn’t want to deal with software. In reality, NoOps is based on the notion of No Operators. Modern software shouldn’t need operators to run and maintain it. Classic operations summon images of operators changing tapes on reel-to-reel nine-track tape machines while operating the software, hardware and generally being the human interface. Yet many Operations teams still behave this way even if they don’t realize it!

A NoOps-focused organization aligns all the operational aspects of software as part of Development. An agile organization’s acceptance criteria include the deployment of the software and the operational aspects, such as monitoring, metrics and Continuous Delivery. They make the tools and infrastructures readily available for Development to deliver higher-quality software and build it as a system, not just a collection of parts.

At xMatters, Operations has built deployment tools and frameworks to utilize services, such as the infrastructure and monitoring, as part of our NoOps approach. This enables Dev and Ops alike to write services that automatically get the benefit of being deployable (including the infrastructure). These toolsets are included like libraries and wrappers to perform those functions. This puts the deployment and monitoring code directly with the application codebase so it can be tested and promoted through the environments by anyone.

As part of DevOps, we have embedded Operations engineers into Development teams and developers into Operations, so they can utilize these frameworks and tools as area experts. They work with these teams directly on their goals, providing instant and constant feedback from both viewpoints. This aligns the teams and provides for simplified resourcing.

Ironically, this makes Operations even more operational. The modern Operations team is actually a service-oriented extension of the Development team. Modern operations teams can develop monitoring as a service, logging as a service, and other services that other teams can easily integrate with. Want distributed logging? Add this hook. They’re writing deployment frameworks and services everyone can consume, and are taking an agile approach to delivering core services as software.

Therein lies part of the challenge: classic system administrators aren’t well versed in development approaches such as the languages, processes and often even agile methodologies. And the reverse is true: developers aren’t well versed in operational approaches. It’s turning Operations into developers and it’s turning developers into Operations, bringing the Operational aspects of software into the spotlight. And it’s a good thing. It doesn’t leave these items to chance and brings everyone together. One team, one deliverable.

At the very least, NoOps is a conversation starter.