Achieving NoOps: The Reality

While working on the Apollo missions, Margaret Hamilton felt that operations of the software was not just part of the machine itself, but also involved the individuals that wrote the software.

She coined the term software engineering in order to cover this new responsibility. As the field of software evolved, it has become increasingly complex and operations eventually split into a separate effort, usually a software operations team.

That is, until 2008, when the term DevOps was first used by Patrick Debois and Andrew “Clay” Shafer.

The idea of DevOps was to integrate the Operations department and the Engineering department in order to more effectively manage the software. The idea of DevOps quickly gained popularity among businesses who wished to cut operational costs and increase scalability of their infrastructure by creating more automation using the state-of-the-art tools being created.

DevOps has created such automations that recently organizations and thought leaders alike have been exploring the concept of NoOps or rather the complete automation of the operational piece (deployment, management and monitoring) of the software being built.

It’s no shocker that the idea is really compelling to anyone who incurs any operational costs for their software at all: completely getting rid of operations has been a dream of many CIOs and CTOs for years.

However, how possible is it to totally remove operations for your software? How close are we to achieving the utopia of self-managing infrastructure?

The graphic below from Smartface shows the differences between DevOps and NoOps.

I believe most companies are years away from even thinking about NoOps.

One of the reasons is that many businesses are investing into DevOps practices, yet haven’t adopted the practices enough to truly create the level of automation required for NoOps.

A recent study done by RightScale showed that 80%of enterprise companies and 70% of small businesses are currently investing inDevOps. The practices that these companies are still investing in are required to create the automation needed to get rid of an operations department entirely.

Netflix, who has completely embraced DevOps as a culture, removed the need for operations from their engineering department. This includes management, monitoring and deployment of their solutions to the cloud.

However, they have fully adopted DevOps and even built their own solutions to solve common problems like QA. For example, they have built their own tools to monitor the fault tolerance of their system like ChaosMonkey .

This represents a huge investment into tooling and infrastructure that many businesses simply can’t afford to undertake.

In addition, for NoOps to be a reality for some businesses, they must choose tore-write their existing legacy applications that do not support the amount of automation required for deployment, management and monitoring by many of the cutting-edge tools available.

For example, Kubernetes is an incredibly robust tool for container management and scaling, however some solutions that enterprises deploy do not run natively in containers. This blocks the ability to use Kubernetes and the vast capabilities provided by its ecosystem.

These software application re-writes are a huge investment for businesses that may not be able to make them. While their new software can be automated usingDevOps practices and modern tooling, they will always have to contend with the legacy software and that will require manual operations.

Finally, many businesses have legacy requirements, whether by outside factors like contracts, clients or regulation or internal factors like politics that are put on their software development lifecycles that require robust operations.

Things like quality assurance, security and auditing can’t quite be automated completely. There are incredible tools for automating QA like BDD style tests.

But there are things that only a human is equipped to find like usability issues and other problems that can only be found during exploratory testing.

The same applies to security and auditing as well. As AI systems advance, it is possible that this changes and tooling becomes so robust that it outperforms even humans at these kinds of tasks. However, we are likely years away from this being a reality.

NoOps is an incredible goal. And for organizations with light regulatory demands and software that is modern, it can be a reality, especially with available NoOps services such as AWS.

But many organizations aren’t able to create the types and level of automation required to really eliminate software operations all together.

Companies that fall into this category, which I feel is the vast majority of them, should strive to adopt the automation practices needed to eventually remove operations as a need. This will help identify areas of their software strategy that aren’t as robust and potentially help them find ways to innovate in the future.

Organizations should always strive towards a NoOps reality.