NoOps is coming, in some form or another. Whether you have homegrown DevOps or outsourced DevOps, it’s time to realize that a simpler way is coming: NoOps automation. We spoke with a group of IT pros to get their perspective and insights, including James Rutt, CIO, The Dana Foundation; Rahul Subramaniam, CEO, DevFactory; and Mark Hahn, director of DevOps and cloud strategies, Ciber Global.
Forrester Research defines NoOps as the goal of completely automating the deployment, monitoring and management of applications and the infrastructure on which they run.
The next generation of PaaS platforms is evolving to meet this goal. If development teams prefer not to deal with operations or lack the necessary skill 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, the NoOps concept is not without its own bit of controversy.
Insight #1: The End Goal is to Empower Development Teams
Mark Hahn: “The differences [between DevOps and NoOps] 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 this self-sufficiency. Continuous integration and deployment automation can be created and configured by the DevOps team or provided by the platform (NoOps). In either case, the end goal is to empower the team such that they can focus more on the business problem at hand than deployment.
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 does come at the cost of some flexibility. 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 individual 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: “We have far too many choices; making the right choices is extraordinarily hard. When you build a Spring Boot application, the number of deployment choices you make is ten times what it was even five years ago.”
“I’ve seen teams that put together really large CI/CD pipelines that run thousands of builds a day. The problem is, it works for 50% of the teams really well, and the other half are struggling. For developers building Java-based systems, it works great, but those that are doing Android development, it doesn’t support mobile applications well,” added Hahn.
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, upfront. 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 puts you 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 offered a different perspective on this topic. He noted 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.
Subramaniam 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 can 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
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.
Regardless of DevOps versus NoOps, our interviewees agreed 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.
