Author: Cyrill Rüttimann
10 years ago, a Forrester analyst responded to the emerging DevOps hype by saying that he would much rather see NoOps. At the time, he was describing a model in which developers would take care of business challenges and not have to deal with infrastructure challenges. Intelligent cloud platforms would make this possible. The advantages for companies were obvious: more business value with less manpower. Some 10 years later, this desire seems to be materializing. What's the point?
Developing and operating proprietary applications is an expensive endeavor in many ways. Figure 1 shows a simplified representation of the architecture layers of a cloud application, which are required for the operation of an application. Specialists are used for each architecture layer, for example the VMWare or IAM team. Based on this, another team can then provide Kubernetes as a runtime platform for application operation in containers. The application cannot function in isolation; it has dependencies on underlying basic services, such as IAM.
This multi-tiered architecture is typically distributed throughout an enterprise organization. The respective specialists must work together both during setup, expansion, or in the event of a failure. This is complex to coordinate and requires a lot of mutual understanding, since the specialists do not per se understand what each other means. Among other things, such frictional losses make the operation of applications massively more expensive and slower.
With the widespread DevOps approach, a lot has already been optimized compared to the past. Especially in terms of collaboration between development and the operations team. But the DevOps team is still largely concerned with technical evaluations, building infrastructure and deploying the development environment. From the perspective of a product owner and the business, which is getting closer and closer to the DevOps teams, more business value needs to be generated.
Mike Gualtieri, the Forrester analyst mentioned above, countered in his 2011 statement on DevOps that he sees developers in the role of addressing business challenges and turning them into code. A developer should not spend his time solving problems in infrastructure along with operations teams. He called this model NoOps. Ten years later, developers (called DevOps teams) are faced with the challenge of delivering massively more business value. Technical debts are piling up. But the capacity to pay them down or solve infrastructure problems is often not considered in planning sessions. No business value, no money. An uphill battle against the business with the result that DevOps teams slowly but surely burn out and quality suffers over time. A boomerang that can take its revenge.
Wouldn't it be excellent if the development team (e.g., Trading) could focus exclusively on the business as shown in Figure 2 and obtain the necessary application infrastructure via self-servicing? And it would be even better if problems in production were solved by intelligent services without further human intervention. The coordination effort between specialists from different teams would no longer be necessary and the capacity gained could be used for more value-adding work.
This is possible today if cloud-native development is consistently adopted and the services offered by the cloud provider are consistently used. In such a setup, the Cloud Center of Excellence (CCoE) assumes the role of a broker that carefully examines the services offered by the cloud provider (cost, efficiency, data protection, security) and provides them accordingly according to the company's internal governance specifications. In addition, the CCoE assumes the role of an internal consultant who provides hands-on support to the development teams in the application of cloud services (site reliability engineer, SRE).
For example, cloud services such as serverless runtimes are predestined for NoOps because they provide a fully managed environment. The effort required by the CCoE to ensure smooth operation is much lower compared to a Kubernetes service. Services are offered to development teams in self-service via a service catalog. This enables development teams to quickly and efficiently cast business challenges into applications from a well-defined catalog of services. Compared to Figure 1, specialists are no longer needed to provide dedicated services and ensure their operation.
And what happens then with the further development of the IAM system, who repairs a corrupt database and who ensures that data is not unauthorizedly extracted by a third party? These tasks are largely handled by the cloud provider and specialized services. For example, services trained with machine learning can recognize with very high accuracy when conspicuous transactions occur and prevent them immediately so that no data flows out. Compliance policies defined as code ensure that services obtained from the Service Catalog can only be put into operation in the Swiss data center with activated encryption of the data. And the corrupt index in the database? The ever-slowing transactions are detected by automated monitoring, and thanks to an automated runbook, the index is rebuilt.
NoOps heralds the next evolution of the DevOps model based on cloud services. NoOps has both technical and organizational implications for your business. The goal of focusing on business challenges can be steadily pursued with NoOps. Building the infrastructure and running the application becomes a sideshow. Compared to DevOps, developers focus on the business rather than the underlying technology challenges. This results in less friction in the organization and more efficient processes. But the effective business value comes from massively shorter development times as well as the high-performance operation of applications.
With NoOps, a company gains enormous efficiency and can generate more business value for customers. Complex and time-consuming processes and structures can be dismantled. They will be replaced by managed services from the cloud and a lightweight CCoE. However, this also means that operations in their traditional and predominant form no longer have a raison d'être. A lightweight CCoE is fully sufficient: