What is NoOps?

NoOps? What does that mean?

Well, you’ve heard of DevOps: development and operational teams working together to ensure you end up with software that does what’s needed, and staff who know how to work it effectively. The NoOps approach is more radical: instead of blurring the boundaries, the aim is to create software that doesn’t require an operational team at all by automating everything to the maximum extent possible.

So it’s a way of slashing headcount?

In theory, perhaps. Realistically, you’re still going to need humans to operate your applications – even Forrester, the research company that originally coined the term NoOps, admitted that some “ops” would likely remain. However, if your apps are designed according to NoOps principles, staff can spend less time on mundane tasks and more focusing on things that are directly beneficial to the business.

What about security? Is DevSecOps no longer the holy grail?

To get finicky, I’d argue that the holy grail was never DevSecOps, but rather SecDevOps. In other words, security should be right at the start of the development lifecycle. Some argue that security is merged into DevOps anyway, and the old arguments are moot. The important thing is that security is incorporated into the development process from the get go; a NoOps approach doesn’t change that.

Hold on, isn’t operations responsible for managing security updates and enforcing regulatory compliance?

It’s true that the operations team often handles security and compliance tasks such as applying patches and controlling access, while a separate security team concentrates on the specific threat discovery and response stuff. If you simply yank ops out of the equation, it stands to reason that someone will have to take on those responsibilities – probably the already overworked security team.

So does NoOps really just mean shunting responsibilities around?

Far from it: remember, the idea is not simply to remove your ops team from an existing workflow, but to develop processes that lighten the load. Done right, this shouldn’t eat into your available manpower, but leave you with more. Another NoOps tactic is to move local applications into the cloud, as this means that a lot of maintenance tasks get taken over by your hosting provider.

To reiterate, all of this needs to be done right – and those are two words that crop up time and time again when talking about NoOps – but it can free up people to spend their time doing more worthwhile things.

So is DevOps on its way out?

Well, the idea of NoOps has been around for the best part of a decade, and DevOps is very much still alive and kicking. Indeed, DevOps has evolved and matured across the years and shows little sign of falling out of favour any time soon. That’s partly because switching to NoOps isn’t just a major cultural change but a huge technical one too. It’s not a quick process, either: ironically, you’ll need a capable ops team on hand to manage the transition, and for some time afterwards to ensure that the robots and humans are working together properly.

As we’ve noted, therefore, pure NoOps is more a philosophical ideal than a realistic working practice. Even so, it’s a model that’s worth pursuing: It can help you improve efficiency even if you don’t go quite so far as to disband your entire operations team.

What comes after NoOps

For the majority of businesses, NoOps is only ever going to really mean “ABitLessOps”. But if things keep moving in the direction of ever greater automation, the question arises: what comes next?

One possibility that’s gaining traction is the idea of IntOps – short for intelligent ops, in which the day-to-day running of your software is taken care of by AI-trained machines. This might sound like a recipe for disaster, but given the advances in machine learning that we’ve already seen, it’s not so far fetched. This is, after all, technology that’s perfectly suited to repetitive tasks, and understanding failures by analysing error patterns – and there are entire categories of human error that machines won’t make.

Of course, people will still be required to supervise, and to provide the initial data from which the machines learn, meaning we’re some way from the point of making ourselves redundant. Still, it’s not too big a stretch to see IntOps at the heart of the software development and deployment cycle. Jump forward a few years and it could well be commonplace.