Betrieb von Cloud Applikationen ohne Operations-Team: Tiefere Kosten dank NoOps

Autor: Cyrill Rüttimann

Vor 10 Jahren erwiderte ein Analyst von Forrester auf den sich anbahnenden DevOps-Hype, dass er sich viel eher NoOps wünsche. Er umschrieb damals ein Modell, in dem sich Entwickler um die Business-Herausforderungen kümmern und nicht mit Herausforderungen der Infrastruktur herumschlagen sollen. Ermöglichen würden dies intelligente Cloud-Plattformen. Die Vorteile für Unternehmen lagen auf der Hand: Mehr Business Value mit weniger Personalaufwand. Rund 10 Jahre später scheint sich dieser Wunsch zu materialisieren. Was ist da dran?

Kostentreiber Betrieb von Applikationen

Die Entwicklung und der Betrieb von eigenen Applikationen ist in vielfältiger Hinsicht ein teures Unterfangen. In Abbildung 1 sind die Architekturschichten einer Cloud-Applikation vereinfacht dargestellt, welche für den Betrieb einer Applikation benötigt werden. Für jede Architekturschicht kommen jeweils Spezialisten zum Einsatz, zum Beispiel das VMWare-  oder IAM-Team. Darauf aufbauend kann dann ein weiteres Team Kubernetes als Ablaufplattform für den Applikationsbetrieb in Containern bereitstellen. Die Applikation ist isoliert nicht funktionsfähig, sie hat Abhängigkeiten zu darunter liegenden Basis-Services, wie zum Beispiel IAM.

Diese mehrschichtige Architektur ist typischerweise in einer Unternehmensorganisation verteilt. Sowohl beim Aufbau, bei der Erweiterung oder im Fehlerfall müssen die jeweiligen Spezialisten zusammenarbeiten. Das ist aufwendig zu koordinieren und braucht viel gegenseitiges Verständnis, da die Spezialisten nicht per se verstehen was der andere meint. Unter anderem verteuern und entschleunigen solche Reibungsverluste den Betrieb von Applikationen massiv.

Mit dem weit verbreiteten DevOps-Ansatz wurde im Vergleich zu früher schon viel optimiert. Vor allem was die Zusammenarbeit zwischen der Entwicklung und dem Betriebsteam anbelangt. Aber noch immer beschäftigt sich das DevOps-Team zu einem grossen Teil mit technischen Evaluationen, dem Aufbau von Infrastruktur und dem Bereitstellen der Entwicklungsumgebung. Aus der Sicht eines Product Owner und des Business, das immer eng an die DevOps-Teams herangeführt wird, muss mehr Business Value generiert werden.

Mehr Business Value, weniger Personalaufwand

Mike Gualtieri, der oben erwähnte Forrester-Analyst, hat in seinem Statement zu DevOps im Jahre 2011 entgegengehalten, dass er die Entwickler in der Rolle sieht, sich mit Business-Herausforderungen zu beschäftigen und diese in Code umzusetzen. Ein Entwickler soll seine Zeit nicht damit verbringen Probleme in der Infrastruktur zusammen mit den Operations-Teams zu lösen. Er hat dieses Modell NoOps genannt. Zehn Jahre später sind die Entwickler (DevOps-Teams genannt) mit der Herausforderung konfrontiert, massiv mehr Business Value zu liefern. Technical Debts (technische Schulden) häufen sich an. Doch die Kapazität, um diese abzubauen oder Infrastruktur-Probleme zu lösen, wird in den Planungs-Sessions oft nicht berücksichtigt. Kein Business Value, kein Geld. Ein Uphill-Battle gegen das Business mit dem Resultat, dass DevOps-Teams langsam, aber sicher ausbrennen und über die Zeit die Qualität leidet. Ein Bumerang der sich rächen kann.

Wäre es nicht ausgezeichnet, wenn sich das Entwicklungsteam (z.B. Trading) gemäss Abbildung 2 ausschliesslich um die Fachlichkeit kümmert und die nötige Applikations-Infrastruktur über Self-servicing beziehen könnte? Und noch besser wäre es, wenn Probleme in der Produktion durch intelligente Services ohne weiteres Zutun von Menschen behoben würden. Der Koordinationsaufwand zwischen den Spezialisten aus den unterschiedlichen Teams wäre nicht mehr notwendig und die gewonnene Kapazität könnte für wertschöpfendere Arbeiten eingesetzt werden.

Dies ist heute möglich, wenn beständig auf Cloud-native Entwicklung gesetzt und die von Cloud-Provider angebotenen Services konsequent genutzt werden. In einem solchen Setup übernimmt das Cloud Center of Excellence (CCoE) die Rolle eines Brokers, der die vom Cloud-Provider angebotenen Services sorgfältig prüft (Kosten, Effizienz, Datenschutz, Sicherheit) und gemäss den unternehmensinternen Governance-Vorgaben entsprechend bereitstellt. Zusätzlich übernimmt das CCoE die Rolle eines internen Consultants, der die Entwicklungsteams bei der Anwendung von Cloud-Services hands-on unterstützt (Site Reliability Engineer, SRE).
Zum Beispiel sind Cloud-Services wie Serverless-Runtimes prädestiniert für NoOps, da sie eine vollständig verwaltete Umgebung bereitstellen. Der Aufwand des CCoEs um einen reibungslosen Betrieb zu gewährleisten ist wesentlich geringer im Vergleich zu einem Kubernetes-Service. Über einen Service Catalog werden die Services den Entwicklungsteams im Selfservice angeboten. Das ermöglicht es den Entwicklungsteams, schnell und effizient aus einem wohldefinierten Katalog an Services die Business-Herausforderungen in Applikationen zu giessen. Im Vergleich zu Abbildung 1 braucht es keine Spezialisten mehr, welche dedizierte Services bereitstellen und deren Betrieb sicherstellen.

Und was passiert dann mit der Weiterentwicklung des IAM-Systems, wer repariert eine korrupte Datenbank und wer stellt sicher, dass Daten nicht unberechtigterweise von einer Drittperson abgezogen werden? Diese Aufgaben werden weitgehend durch den Cloud-Provider und spezialisierten Services übernommen. So können zum Beispiel mit Machine Learning trainierte Services mit sehr hoher Genauigkeit erkennen, wann auffällige Transaktionen auftreten und diese unmittelbar unterbinden, so dass keine Daten abfliessen. Als Code definierte Compliance-Policies stellen sicher, dass aus dem Service Catalog bezogene Services ausschliesslich im Datacenter Schweiz mit aktivierter Verschlüsselung der Daten in Betrieb genommen werden können. Und der korrupte Index in der Datenbank? Die stets langsamer werdenden Transaktionen werden von der automatisierten Überwachung erkannt und dank eines automatisierten Runbooks wird der Index neu aufgebaut.

Mit NoOps wird die nächste Evolution des DevOps-Modells auf Basis von Cloud-Services eingeläutet. NoOps hat sowohl technische als auch organisatorische Auswirkungen auf Ihr Unternehmen. Das Ziel, sich auf die Business-Herausforderungen zu konzentrieren, kann mit NoOps stetig verfolgt werden. Der Aufbau der Infrastruktur und der Betrieb der Applikation wird zu einem Nebenschauplatz. Im Vergleich zu DevOps konzentrieren sich die Entwickler auf die Fachlichkeit und nicht auf die Herausforderungen der darunterliegenden Technik. Daraus resultieren weniger Reibungsverluste in der Organisation und effizientere Prozesse. Aber der effektive Business Value entsteht durch massiv kürzere Entwicklungszeiten sowie dem leistungsfähigen Betrieb von Applikationen.

Fazit: Der Betrieb in seiner heutigen Form wird nicht mehr existieren

Mit NoOps gewinnt ein Unternehmen enorm an Effizienz und kann mehr Business Value für die Kunden generieren. Komplexe und zeitaufwendige Prozesse und Strukturen können abgebaut werden. An ihre Stelle rücken Managed Services aus der Cloud sowie ein leichtgewichtiges CCoE. Das heisst aber auch, dass der Betrieb in seiner klassischen und vorherrschenden Form keine Daseinsberechtigung mehr hat. Ein leichtgewichtiges CCoE reicht vollumfänglich:

• Es fungiert als Drehscheibe zwischen den Entwicklungsteams und dem Cloud Provider, welcher Managed Services anbietet.
• Es ist dafür verantwortlich, dass die Entwicklungsteams die richtigen Services in der geforderten Qualität als Selfservice zur Verfügung gestellt bekommen.
• Es automatisiert die anfallenden Betriebsaufgaben (z.B. Monitoring, IAM, Billing) selbst oder nutzt spezialisierte Services für diese Aufgabe.
• Die Governance der Cloud-Services wird sichergestellt (Landing Zone, Policies).
• Und es unterstützt die Entwicklungsteams mit Betriebsknow-how von der Konzipierung bis zum Betrieb der Applikationen (Site Reliability Engineer - SRE).