Up Your DevOps Game: Its Time for NoOps

Key Insights from the World Forum Event

A panel of experts gathered virtually on January 28, 2021 for the World Forum Disrupt Data Series webinar to discuss the emerging shift from DevOps to NoOps. It was a great discussion out of which came a number of key insights summarized here. The panel included the following speakers:

• James Rutt (Moderator): Chief Information Officer, The Dana Foundation
• Rahul Subramaniam: Chief Executive Officer, Dev Factory
• Mark Hahn: Director of DevOps, Ciber Global

Forrester Research defines NoOps as the goal of completely automating the deployment, monitoring, and management of applications and infrastructure on which they run.

The next generation of PaaS platforms are evolving to meet this goal. If development teams prefer not to deal with operations or lack the necessary skills sets, they can opt into platforms that provide standardized best-in-class operations with minimal hassle. This also accelerates the evolution of their infrastructure to emerging technologies such as Kubernetes and containers. Not only that, but it can be accomplished at a fraction of the cost. However, as we see in this webinar, the NoOps concept is not without its own bit of controversy.

Insight #1: The End Goal is to Empower Development Teams

Insight #2: Consistently Making the Right Infrastructure Choices is Hard

Insight #3: Evolve from NoOps to DevOps, Instead of the Reverse

Insight #4: NoOps Platforms vary by Cloud Provider

Insight #1: The End Goal is to Empower Development Teams

Mark Hahn: “The differences (between DevOps and Nops) have a lot to do with shifting left more on all of the processes. With DevOps, teams have to rely on various operations and infrastructure support services. With NoOps, the goal is to make those teams fully self-sufficient.”

Automation is the key to making development teams fully self=sufficient. Continuous integration and deployment automation can be created and configured by the team (DevOps), or provided in an opinionated fashion by the platform (NoOps). In either case, the end goal is to empower the team such that they can primarily focus on the business problem at hand.

In a DevOps model, a few developers on the team typically manage the continuous integration pipelines and their associated deployments. This includes the creation of the application stack and subsequent updates, as well as observability and scalability mechanisms. The widespread availability of infrastructure-as-code and associated APIs has made this possible.

NoOps platforms provide these capabilities without much additional work by developers, thus enabling application teams to accelerate their delivery velocity. This comes at the cost of some flexibility, however. Teams with special requirements, such as GPU-centric environments or extremely high-scale use cases, may opt to build their own infrastructure to meet their needs.

Most teams don’t need the additional complexity though, and are better served to avoid it. Applications with a user base in the low thousands will likely not need much beyond the standard configuration provided with frameworks such as Spring Boot or .Net Core. You start with just the infrastructure you need, avoid solving problems you don’t have, and leverage only select offerings from cloud providers.

Insight #2: Consistently Making the Right Infrastructure Choices is Hard

Rahul Subramaniam: “Today we have far too many choices, making the right choices is extraordinarily hard. Today when you build a Spring Boot application, the number of deployment choices you make is 10x what it was even five years ago.”

Mark Hahn: “I’ve seen teams that put together really large CI/CD pipelines that run 1,000s of builds a day. The problem is it works for 50% of the teams really well, and the other half are struggling. Those developers that are building Java-based systems, it works great, but those that are doing Android development, it doesn’t support the mobile applications well.”

The NoOps approach has a key dimension that extends beyond automation. The infrastructure landscape is continually evolving and developers are faced with a growing array of choices as they deploy and manage applications. How can teams know which are the right tools to pick? There are too many out there to be an expert on all of them.

Consider the area of observability where choices range from open-source solutions such as Prometheus and Grafana to commercial offerings such as Dynatrace and DataDog. Is the extra value added by the commercial offerings worth it? Is it a requirement for your application?

It can be difficult to say up front. Oftentimes, the best way to learn how to operate your service is to operate your service. Starting with an opinionated, bundled solution gets you started quickly and in a position where you can learn those lessons. With NoOps, the infrastructure arrives ready-to-go, right out of the box. You can focus on your core business function and not worry about the deployment mechanism. This shrinks the surface area where errors may occur and improves the efficiency of development teams. From a management perspective, the reduced cost is also quite appealing.

Mark Hahn offers a different perspective on this topic. He notes that if there is one opinionated CI/CD framework, it may suit some teams well but not the others. Teams that develop various components may have different requirements, thus they may need the option to build their own pipelines. This is a consideration to keep in mind as organizations seek to adopt the NoOps philosophy.

Insight #3: Evolve from NoOps to DevOps, Instead of the Reverse

James Rutt: “There is a broad assumption that DevOps is mature, whereas in most shops, they feel mature in some areas of the value stream but not necessarily in the synchronization of all the tools. Now we are talking about another quantum leap into NoOps. Do you think we are jumping ahead too quickly?.”

DevOps and NoOps represent a spectrum rather than a conflict where one wins over the other. Many applications don’t need a highly-engineered infrastructure, as opposed to companies like Amazon and Netflix who require it. Thus, don’t over-architect solutions until the time where you need to. Grow into DevOps when it becomes a business priority for you. For Amazon, it is a business priority to manage that infrastructure. For you, it may not be.

Thus, Rahul made the point that teams should actually begin with the NoOps approach as the default. Look for NoOps solutions out there to quickly get started, and at some point, you may need to manage that infrastructure yourself as your business grows or requires it.

Another consideration is that not all organizations are at the point where developers make choices independently. You always want the business and technology groups to be in alignment. This is where more traditional processes fall into place. Further, DevOps teams typically place numerous checks and balances in their systems. For example, custom pipelines enable reconciliations and cross checks to make sure the data being operated on is correct and accurate.

Insight #4: NoOps Platforms vary by Cloud Provider

Rahul Subramaniam: “We need to constantly coach developers, similar to how an athletic coach reviews exactly what happened using game film. Do this with each individual developer, and within 6–8 weeks you can start eliminating (code quality) issues.”

For developers running on Google’s cloud, App Engine “lets app developers build scalable web and mobile back ends in any programming language on a fully managed serverless platform.” Teams running on AWS can use Engine Yard Kontainers from DevGraph to “deploy apps in one click directly from your Git repo.” There is also AWS Elastic Beanstalk which bills itself as “an easy-to-use service for deploying and scaling web applications and services” on one of their supported technology stacks.

Looking Ahead

A number of perspectives were offered in this webinar on the state of DevOps and NoOps, however our panelists all agreed on the central thesis that development teams need to be empowered. Gone are the days where you can afford to spend time on undifferentiated activities or wait on dependent service teams. Focus on the business value from day one, make it observable, and use the platform that best enables you to accomplish that goal.

Originally published at https://blog.engineyard.com.