What Happened to NoOps?

Intro

A few years ago a new term was coined – NoOps.

With the promise of total automation of the deployment process, eliminating the need for large DevOps organizations, it has found many proponents, but not so many believers.

Why? Let’s start from the beginning.

DevOps and broken promises

Idea

DevOps promised to bridge the gap between developers creating code and production and test environments requiring maintenance by operations teams. It was more an idea of combining the responsibilities and avoiding the blame game between development and operations.

The very idea (as it happens almost every time) opened up something very different from its origins: devops teams, methodologies and tools. It was supposed to be the methodology of blending development and operations, but it has become just another IT subdivision.

Reality

DevOps in many organizations has become big and has created another bottleneck between development and operations. The very promise of blending the two worlds, development and operations, was broken by creating a monster between them, and then having two steps instead of one between development and operations. Instead of the blame game between developers and operations, now we can have blame games with three participants: developers, devops and operations. Success, it is not.

Some devops teams became disassociated with both development and operations needs, creating a universe of their own, playing with the latest tools and testing different approaches. This creates constantly unreliable and unstable environments, which create problems on their own, requiring even a larger DevOps workforce, which tends to be expensive and hard to control.

Point of no return

Even worse, it has become acceptable for developers to have the attitude of not wanting to take responsibility for deployment;  ‘we need more DevOps people to do that.’ There’s no return to pre-DevOps times.

It’s something well-known, but not spoken about in public. Often thinking: ‘Maybe we can just let the developers do it with simple keyboard shortcuts or a click of the mouse, and get rid of most or (ideally) all of this expensive DevOps bottleneck.’

Because when this developer targeted automation is done by local DevOps teams, we find another solution which is worse than the problem (more automation requiring more people to manage the automation, it is constantly evolving and dealing with bugs and the constant ‘under construction’ mentality).

→ Read more about managing the lifecycle of applications, in the context of inevitable changes in digital transformation.

Help!

So where do we look for help? Outside? And, outside for IT means the cloud. Let the cloud automation teams do it and because of the effects of the scale (done once, used by millions), the cost should be lower for all the clients.

Serverless as an enabler for NoOps?

The promise

Serverless means high level abstraction allowing developers to write code and expose functions, and that’s it. No servers, no virtual machines, no containers, no Kubernetes, etc. – at last the dream has come true.

Let the cloud vendor deal with all of these underlying complexities. Let the developers focus on creating business functionality and deploy it for testing and production when ready. No CPU, memory, or threads, not anymore because it’s not something that we should care about as developers.

It is fully integrated with IDEs, just deploy your method as a function, wait a few seconds and it’s ready!

Reality

Unfortunately, despite being in the market relatively for a long time, serverless hasn’t really taken off.

One of the reasons is the reluctance of CIOs to create dependency on cloud services, the fear of losing control, and the lack of trust of cloud service providers. Sometimes it’s rational, and sometimes it will wait until the next management change (in attitude) in IT.

The second is inferior user experience due to known technology issues such as cold start, meaning waiting for many seconds for the functions to fire and return results. Especially for the technologies not built with serverless in mind, for instance – Java, also called “high latency” technology, but it happens to be used by over 80% of business application developers.

Scalability promises of quickly ramping up the number of function calls from a few to millions in minutes, well, it’s not working as well as advertised.

Behind the scenes

Unofficially, even authorized trainers (AWS, Azure, GCP) admit that it’s good for rare event processing, but not for regular business API execution.  Why? Because of performance unpredictability and total chaos when a business app has thousands of functions. These functions call each other directly or indirectly, and we’ve got millions of possible call chains which are hard to track and debug.

Whoever tried something bigger than serverless, like the “hello world” tutorial or famous calculator API, has noticed the same thing – it becomes very complex very fast.

In our CIO survey, only a low percent chose serverless for their next business application, even among those who are already using cloud as a default choice.

So one of the key enablers is not here to help, at least not now, and it’s hard to be a believer given the slow rise in popularity over the years. Could 2.0, 3.0, or 4.0 convince the community?

If the DevOps fate is closely bound to the Serverless fate, the news is not good. Is it all lost then?

→ Read more on Cloud adoption statistics: 57 CIOs share their experience

NoOps future?

Trends ahead of their times, like NoOps even when they fail in their original form at the very specific time, are very valuable.

First of all, NoOps is the name of the dream, need and hope for a lower DevOps cost, not more, so the pressure coming from different experiences is only natural.

It also is an enabler for rational automation, using more cloud ready solutions, letting others do the groundwork, not creating monstrous toolsets, and teams who will start to deal with their own internal problems and serve the devs and ops … later.

As an invention, it is harshly criticized as being unrealistic right now, especially by the cloud scared decision makers and those who are proud of their DevOps teams. It was so effortless to follow the easy path in this article – ‘it seems almost impossible, so let’s just forget it.’

It has happened so many times in the past, with flying machines heavier than air, information without printing, etc. – maybe NoOps will earn a new name and make the NoOps dream come true … five years from now.

For more technology stories please visit Avenga Magazine and follow Avenga on Medium.