In 2018, Microsoft Israel’s chief scientist, Tomer Simon, wrote an article titled, ‘Stop DevOps Before Someone Gets Hurt’. In it, he urged
engineers to bypass DevOps and jump straight into ‘NoOps’. Irrespective of the merits of this approach, the most illuminating part of Simon’s recommendation is to figure the DevOps environment as a continuum – upon which NoOps is just another checkpoint.
One year after the publication of Simon’s piece, Deloitte listed NoOps among its
Tech Trends to watch out for, declaring it the “next state in the evolution of cloud computing”, which “automates key tasks, allowing IT talent to shift focus from operations to outcomes.”
So where does the NoOps environment stand today? How can it be achieved? What are the benefits and drawbacks for financial players? And to what extent, if at all, does NoOps put engineers’ jobs in jeopardy? To get answers to these questions, Finextra spoke
with representatives of technology market intelligence and advisory firm, CCS Insight, software development company, Netguru, as well as cloud resource platforms, Exotanium and Platform.sh.
What is NoOps?
Let’s start with what it isn’t. NoOps, shorthand for ‘no operations’, is not about simply outsourcing IT operations, moving to the cloud, or seeking software-as-a-service. It is not a tool that can be bought.
NoOps is about reworking IT processes so that machine learning and artificial intelligence instruments enable the automation of both high and low-level tasks. Like DevOps, NoOps is implementing small yet constant changes, as opposed to releasing larger changes
in a set window.
A fully-fledged NoOps environment – at least in theory – therefore, demands little human involvement. As Bola Rotibi, research director, software development and delivery, CCS Insight, put it in an interview with Finextra: “NoOps is the march toward high
levels of automation, via the reduction of human intervention, and the fallibility that comes with it.”
Indeed, in the NoOps environment, many of the functions needed to maintain IT services are either automatic, or handled by someone other than a dedicated, in-house software team.
“NoOps is an aspirational goal on the spectrum of Ops automation,” said Exotanium’s vice president, product and engineering, Ben Boyd. “On one end is zero automation and the involvement of engineers to drive manual processes, and on the other end is a touch-free,
100% push-button automated process that requires no intervention, and ideally, zero maintenance or downtime. NoOps primarily aims to remove that human element in favour of a theoretically perfect end goal which is more cost efficient and requires very few
engineering resources to maintain.”
However, the level of automation required for the NoOps label to be applicable remains something of a grey area: “There is no established definition of NoOps,” noted Bartosz Pranczke, engineering director, Netguru. “But, I use one that pushes us in the right
direction. I define NoOps as an asymptote and a mindset. The asymptote shows us the goal: operational work doesn’t negatively influence the speed of the delivery; and the mindset – automate, automate, automate. While having a name for it helps, as it emphasises
certain aspects of work, for me, it’s just another part of DevOps.”
NoOps will not replace DevOps, says
Forrester; rather, it is an evolution of the release management aspects of DevOps.
How can it be achieved organisationally?
NoOps is not just about automating the human element. It’s also about automating decision-making processes – such as infrastructure scaling, according to current needs – or taking actions based on logged events.
For Robert Douglass vice president, channel sales, Platform.sh, a reliable steppingstone between DevOps and NoOps is GitOps. The idea is that by committing code to a Git repository, the developer has unleashed a series of automated events which eventually
lead to tested, vetted, approved code being deployed into a production environment.
“To focus on the path to achieving NoOps,” claimed Douglass, “an obvious prerequisite is that Git is used universally for code management, and that the tooling that you procure (or build… and I have warned you!) responds to Git events – like commit, branch,
push, merge-request, pull-request and so forth – such that all the required pipelines are triggered.”
Yet, financial players must not get lulled into believing that NoOps is a concrete destination, as such. It is more of an aspirational goal that cannot be perfectly achieved by any sufficiently complex organisation. NoOps is more of a process of improvement,
over time.
“Any growing organisation will be continually evolving,” noted Boyd. “As a consequence, processes will need to shift and adapt to accommodate, which means automation will need to be adapted by engineers to stay on target toward the goal.”
Indeed, in a developing system, automating everything is a never-ending process. That’s why, realistically, NoOps is a direction, not a destination.
What are the benefits to financial players?
So, why should financial institutions embark on this never-ending NoOps journey at all?
There are 5 key benefits financial players can enjoy along the way:
- NoOps limits IT management outgoings, by reducing headcount;
- It unlocks more staff capacity for addressing higher-value functions, such as developing new applications or services;
- It enables firms to hire IT generalists for diverse tasks, as opposed to specialists;
- It lets businesses react to changing needs faster, by reducing dependency on the operations team and reducing time to market; and
- It shifts the focus from operations to business outcomes.
“Cost and time savings are the primary benefit to organisations working toward a NoOps end goal,” said Boyd. “This can come through a variety of means, like automation of software builds, testing, and deployments, automated compliance checks and audits,
security checks and validations, since they are conducted in a way that is well defined and repeatable, without the risk of human error (in theory), and within a faster timeframe than if a human were performing the work.”
But the benefits aren’t without risks, such as cloud vendor lock-in, stressed Boyd. “Nevertheless, in general, automating toward a NoOps model should reduce operational overhead and increase operational excellence over time.”
“The benefits of having a NoOps mindset are similar to DevOps,” added Pranczke. “It puts proper emphasis on things like evolving and improving products, at a faster pace. It’s widely recognised that having a highly functional development teams is a fundamental
part of competitive advantage.”
But automating labour and decision-making in operations should also decrease the failure rate, Pranczke asserted. “It transforms operational knowledge into code, which is typically more reliable than our memory. On top of that, development teams that can
move quickly, without the burden of operations, are typically more satisfied, which helps retain people.”
In short, the benefits of NoOps involve a shift from maintenance to development – with smaller teams, and a stronger, faster output.
What are the drawbacks?
However, according to some, NoOps is not a complete computing nirvana. Much of the financial services universe is still concerned about the lack of human intervention at hand to correct automated, and flawed, processes – which become ‘mass produced’ and
can impact countless servers.
“The danger around NoOps is what I call a runaway operation,” argued Rotibi. “This happens when an unwanted event occurs in the system, which in turn triggers another, until you have a chain reaction or errors that becomes out of control. To avoid this,
humans need to intervene with checkpoints that break the chain.”
This is just one reason why, arguably, humans can never fully be taken out of the programming equation. Even if full automation was desirable, it will be harder to achieve in some IT environments, compared to others. As such, operations teams within many
financial firms will need to stay on, to monitor outcomes or handle exceptions.
But this produces another snag – hybrid deployments and legacy infrastructures mean bottlenecks. In these situations, zero human intervention is a futile goal.
There is also the question of security and compliance. Often, operations teams collaborate with the security team to establish controls that protect applications. The same applies for compliance processes. As such, reducing the operations team could mean
that more capital will need to be diverted to security, and to compliance. Even automated deployments, which observe security best practices, will not totally remove the need for someone to keep a continual eye on security.
Besides, threat vectors are evolving every day, so cloud security controls need to remain agile. This responsibility cannot always be allocated to automation tools.
Ultimately, NoOps critics argue, financial players should not be aiming for automation, per se. Instead, stability, reliability, and resiliency, of IT systems are more serviceable goals.
Are engineers’ jobs in jeopardy?
Arguably, one of the biggest concerns around NoOps, is the fear of redundancies. But this could be warranted.
Forrester predicts that robots, automation, and AI – all architects of the NoOps environment – will displace
24.7 million jobs by 2027. This exceeds the number of jobs (14.9 million) these technologies are expected to create.
Exotanium’s Boyd, however, expects engineering roles to change over time – with more focus on higher levels of abstraction and fewer resources concentrated at lower levels in the automation stack – but sees job prospects in a more positive light: “Automated
processes are built on tools that must themselves be developed and maintained,” he said. “No system is perfect and without risk of failure, so humans will always be required to do that work.”
Granted, there are consequences that come with this move – for example, higher-level engineers understand less of the lower-level aspects of the system in general – but the productivity and overhead benefits make up for it. Engineers who know how to make
it all work down to the very bottom will greatly benefit, too.
“People talk about NoOps as if everything will become 100% automated, and there will be no humans to work with, but this vision contradicts the philosophy that underlines DevOps – which is about collaboration and efficiency,” commented Rotibi. “DevOps is
a continuum, and NoOps is just one checkpoint along the way. Those displaced by a NoOps setup can be redeployed to other value-added functions within the workflow.”
Pranczke agrees: “Operations are not primitive work that can be automated and forgotten. It can be decoupled from development so it doesn’t slow it down, but the Ops part is still there. Somebody has to create and maintain those automated tools. Somebody
has to fix them when they break – which they will. The whole point of NoOps is not getting rid of Ops engineers, it is enabling them to do more valuable work.”
When it comes to NoOps proponents, there is an underlying assumption that operational work slows down the development process, which can be true. However, it must also be acknowledged that in a highly automated environment, the skills Ops teams bring to
the table can also boost velocity. In the event of an outage or an impactful bug, isolating and recovering from the disaster demands a range of human skills. Without these skills, financial firms are likely to suffer more from outages.
The NoOps nirvana and beyond
For NoOps to become a reality, a lot of work is required. Application stacks and services in the cloud must be selected carefully for a smooth transition.
But it’s not just about the technology. It’s about a shift in culture and process. NoOps is a win for the business – and by extension customers – as much as it is for IT.
So, if NoOps is just one stop on the DevOps is a continuum, what’s next? The answer is AIOps – technology that catches bugs in real time, without being trained what to target. Desirable or not, it holds the keys to true automation.