There's no ops like NoOps: the next evolution of DevOps

Lately, with the rising automation and autonomy of databases, servers, networks, and everything else, there's been talk of a new mode of software delivery: "NoOps." That is, new code is pipelined -- from developers' frontal-lobe-to-front-office -- quickly and automatically, with minimal need for human intervention.

The folks at TechTarget provide a definition of NoOps as "the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house." 

Also: NoOps: How serverless architecture introduces a third mode of IT operations TechRepublic

I asked Greg Nist, director of training at MarkLogic, to explain the advantages of a NoOps approach.  He points to NoOps as the next evolution of the development model from DevOps. "Companies that have adopted the DevOps model have seen significant benefits compared with the siloed, waterfall model," he points out. "DevOps blends the role of developer and operator to increase accountability and speed time of deployments of innovative products, which provides true value-add to the company and the customer."

All good, of course. But then Nist posits the next phase: "What if you could transition from something great to something even greater -- something that could further the time devoted to development?" he asks. "That's where NoOps comes in. By leveraging cloud services, organizations can further shrink administration, configuration and deployment work in order to maximize development time."

What about organizations with weak or nonexistent DevOps initiatives -- can they make the leap to a NoOps model? Since it's also likely that DevOps laggards are also still mired in on-premises legacy infrastructures, a move to cloud may help pave the way, Nist states.

Others, however, advise caution with NoOps -- it's not a panacea, and it's way too early to think about handing over the software implementation keys to the robots. "You will at least need IT ops personnel to supervise the outcomes and handle the exception conditions," notes Jim Kobielus, lead analyst with Wikibon, in a recent tweet. "Automated systems can't be entirely trusted to their own care and feeding."

Also: What is DevOps? An executive guide to agile development and IT operations 

While we've come a long way with the tooling, "the idea that you can remove people from this equation completely is pretty absurd, at least in the next five years," says David Linthicum in an InfoWorld column.  He notes legacy systems make NoOps a nonstarter for many organizations, but, more importantly, it undermines the people-focused premise of DevOps. "DevOps is not just about the automation of ops, it's about people working together to continuously improve software development and operations," he says.

Still, moving toward NoOps offer a productivity boost that may strengthen the innovation process, Nist says. "I think it's most helpful to compare NoOps with the typical DevOps workflow, which is really just iterating among build, test and release. The build-and-test pieces are what provide value to the business, and the DevOps model does a good job of shrinking what doesn't provide value: the release phase," he explains. "However, while the release window with DevOps is smaller, it's still there. And DevOps has created this kind of gray area where developers and operations staff overlap at the release stage."

This gray area of overlap can create entanglements that will create bottlenecks. "Let's say, as a developer, the deployment of your cluster wasn't done for you, and you're doing things in a manual or even a scripted way," Nist continues. "If you don't get it just right, and you go to validate your environment once your release is done, you're going to be stuck in a cycle of debugging and trying to figure out where things went wrong. That's going to slow you down, and it could be because of a simple mistake -- like you forgot to click one of the options for high availability that you needed, and everything breaks." 

The NoOps model, on the other hand, "raises the level of abstraction around implementing releases, which allows developers to spend more time on build and test. In fact, with managed cloud services, it's possible with just a few clicks to configure your entire environment, with all the tooling and the framework needed, to run a project. In 15 minutes you can get a fully functioning, high-availability cluster with all of the software and components that you need." 

How will the roles of operations people change if the enterprise moves to NoOps? In the scenario described above, "the need for operations as far as configuration and deployment roles are concerned is significantly reduced, so much so that developers could make it part of their workflow," Nist says. "And if you allow the actual administration and monitoring of the server, via managed cloud services, it would suggest no operations teams." 

This may mean more opportunities for operations people to elevate their roles in their organizations, "to recast highly skilled operations professionals into roles in which they can dedicate their skills to more of the value-added activities," Nist says. You can transition their energy from something that was once simply a necessity to something that is really adding value to the customer. As an example, think of all the time that goes into Kubernetes, which has a massive configuration demand. Remove that from the shoulders of operations staff, and they have the time and resources for more critical tasks like continuous deployment, granular usage tracking, better testing and more."

Developers may benefit as well, of course. "NoOps frees up the chunk of time and energy that they currently dedicate to that last item in their pipeline -- release," Nist says. "You're literally taking tasks off of developers' plates, which can only mean that they get to do what they need and want to do: develop cool new products and services."