Um Charles Dickens zu paraphrasieren: „Es war die beste aller Ideen, es war die schlechteste aller Ideen.“ Worauf beziehe ich mich? DevOps und darauf, wie es inzwischen interpretiert wird.
Die beste Idee hinter DevOps ist Infrastruktur als Code, bekannt als IaC. Anstatt Anwendungsumgebungen manuell aufzubauen – ein langwieriger und fehleranfälliger Prozess –, definiert IaC in einer Vorlage, „wie“ die Umgebung aufgebaut wird, und erstellt diese Umgebung anschließend automatisch anhand der Vorlagendefinition.
Dies geschieht mit Computergeschwindigkeit statt mit menschlicher Geschwindigkeit und, was ebenso wichtig ist, jedes Mal konsistent, wodurch sich die Anwendungsqualität erheblich verbessert. Richtig umgesetzt, kann DevOps die Geschwindigkeit der Anwendungsentwicklung erheblich steigern.
Dieser Ansatz für die Entwicklung und Bereitstellung von Anwendungen wurde als „Shift Left“ bekannt, weil er Aufgaben nach der Entwicklung im Anwendungslebenszyklus nach vorne verlagert.
Siehe auch: DevOps, Low-Code und RPA: Vor- und Nachteile
Doch die Herausforderungen von DevOps sind zahlreich
Doch obwohl DevOps’ Infrastruktur als Code seine beste Idee war, war sie – so, wie sie üblicherweise umgesetzt wurde – auch eine der schlechtesten.
Allzu oft wurde Entwicklern gesagt, sie sollten die Verantwortung für die Erstellung der IaC-Vorlagen übernehmen. Dafür gibt es eine gewisse Logik; schließlich sollte der Entwickler einer Anwendung deren Infrastrukturanforderungen am besten kennen, oder?
Andererseits bedeutet dies auch, dass Entwickler für das Verständnis der Netzwerkanforderungen in der Produktion, groß angelegter Speicherkonfigurationen und des Managements von Ressourcen für Ausfallsicherheit verantwortlich werden. Angesichts dieser hohen Anforderungen kann man wohl sagen, dass DevOps – abhängig von der Komplexität der Produktionsumgebung einer Anwendung – kein Allheilmittel ist.
Dennoch entschieden viele IT-Organisationen, inspiriert vom Shift-Left-Mantra, dass es sinnvoll sei, weitere Aufgaben im Anwendungslebenszyklus nach vorne zu verlagern. So wurden Entwickler für das Testen verantwortlich. Und für die Sicherheit. Und für das Patch-Management.
Leider wurden diese Aufgaben, wie sie üblicherweise angegangen wurden, nicht „als Code“ behandelt. Das heißt, die zuvor dafür verantwortlichen Gruppen übertrugen die Verantwortung an die Entwickler – zusammen mit den manuellen Checklisten, die typischerweise zur Ausführung der Aufgaben der jeweiligen Gruppe verwendet wurden. So übernahmen Entwickler eine Menge manueller Arbeit in Bereichen, in denen sie über keine besondere Expertise verfügten.
Und was passiert dann? Wenn ein Entwickler etwas manuell erledigt, wird die Aufgabe dadurch nicht schneller fertig – insbesondere dann nicht, wenn sie mit geringer Fachkenntnis ausgeführt wird. Das potenzielle Tempo eines DevOps-Ansatzes bleibt daher oft deutlich hinter den Erwartungen zurück.
Siehe auch: Warum die Cloud Cloud Native bedeutet
Shift Left richtig umsetzen
Wie sieht also der Weg zu einem Shift-Left-Ansatz „als Code“ aus? Sind Anwendungen dazu verdammt, in manuellen Prozessen stecken zu bleiben, die von überlasteten Entwicklern durchgeführt werden?
Mit einem Wort: nein. Organisationen müssen Shift Left jedoch richtig umsetzen. Hier sind drei Tipps dazu.
1) Alle Aufgaben automatisieren
Wenn Infrastruktur als Code sinnvoll ist, sind auch Tests als Code, Sicherheit als Code und Patch-Management als Code sinnvoll. Mit anderen Worten: Wenden Sie die Logik von DevOps auf alle Schritte auf dem Weg in die Produktion an.
Das bedeutet natürlich, dass auf diese Aufgaben Entwicklungskompetenzen angewendet werden müssen – was nun einmal Entwickler erfordert. Rechnen Sie damit, dass sich das Profil von Fachspezialisten (z. B. eines QA-Mitarbeiters) verändert und künftig auch Programmiererfahrung umfasst. Das bedeutet außerdem, jede Aufgaben-automatisierung als eigene Anwendung mit einem eigenen Lebenszyklusmanagement.
2) Den Weg in die Produktion als automatisiertes Produkt behandeln
Technologieorganisationen mit dem schnellsten Weg in die Produktion behandeln den gesamten Prozess als integriertes Produkt, das über seine verschiedenen Teilschritte hinweg automatisiert wird. Das bedeutet automatisierte Übergaben zwischen den einzelnen Zwischenschritten und den Verzicht auf manuelle Freigaben. Ich meine euch, Change Control Boards.
In der realen Welt sind die meisten manuellen Freigabeschritte formale Rituale, bei denen Prüfpunkte automatisch abgehakt werden. Wenn sich die Übergabe von einem Schritt zum nächsten auf ein automatisches Nicken reduzieren lässt, kann sie ebenso als automatisierte Übergabe umgesetzt werden – mit klar definiertem Ausnahmehandling.
Das bedeutet außerdem, dass der Weg in die Produktion als Ganzes wie ein eigenes Produkt gemanagt werden muss – einschließlich einer Architekturprüfung, um sicherzustellen, dass alle automatisierten Subsysteme gut zusammenspielen.
Wenn sich das nach Arbeit und Investitionen anhört, liegen Sie richtig. Ohne dies bleibt der Weg in die Produktion jedoch langsam: Das Tempo an beiden Enden (durch Dev und Ops) rahmt weiterhin dieselben alten, langsamen manuellen Schritte in der Mitte ein.
3) Shift Left noch weiter vorverlagern
Auch wenn die Automatisierung aller Aufgaben – und des Gesamtprozesses – gute Schritte sind, bleibt es eine Herausforderung, für ausreichende Sicherheit zu sorgen, wenn anfälliger oder veralteter Code die Grundlage einer Anwendung bildet. Wie das alte Sprichwort sagt: Müll rein, Müll raus.
Mit solchen Sicherheitsrisiken zu leben, wird noch schlimmer, wenn eine Schwachstelle bekannt wird oder jemand sie ausnutzt. Was folgt, ist eine hektische Aufholjagd, um Codebasen zu aktualisieren und die Updates in die Produktion zu übernehmen.
Dieses Problem ist systemimmanent, wenn Entwickler mit einem leeren Blatt beginnen und Bibliotheken sowie Komponenten direkt aus dem Internet herunterladen. Es ist erschreckend, wie viele containerbasierte Anwendungen mit von DockerHub heruntergeladenen Images erstellt werden, obwohl bekannt ist, dass viele der beliebtesten davon veralteten und/oder verwundbaren Code enthalten.
Ein wesentlich besserer Ansatz besteht darin, Entwicklern vorbereitete Codebasen bereitzustellen, die nachweislich auf dem aktuellen Stand und nachweislich frei von Schwachstellen sind. Die dafür verwendeten Mechanismen werden als Vorlagen, Frameworks oder Accelerators bezeichnet. Im Wesentlichen lädt der Entwickler die Vorlage in eine bevorzugte IDE herunter und beginnt mit einer sicheren Codebasis, in die anschließend die Funktionalität der Anwendung integriert wird.
Sobald das Anwendungsupdate abgeschlossen ist, gelangt es in den oben beschriebenen automatisierten Prozess. Anwendungsartefakte werden erstellt und durch die verschiedenen Phasen des Lebenszyklus bewegt, bis sie schließlich bereitgestellt werden.
Dieser Ansatz zur Codehygiene lässt sich auf den restlichen Lebenszyklus ausweiten, indem außerhalb einer bestimmten Anwendungspipeline ein Prozess betrieben wird, der angekündigte Schwachstellen überwacht. Wird eine Schwachstelle bekannt gegeben und ein Patch verfügbar gemacht, wird ein Prozess zur Erstellung und Bereitstellung der Anwendung gestartet, der das betreffende Artefakt automatisch aktualisiert und in die Produktion überführt.
Dadurch entfällt die manuelle Nachverfolgung, welche Bibliotheken und Komponenten die einzelnen Anwendungen enthalten. Ebenso entfällt das Krisenmanagement, das damit verbunden ist, sicherzustellen, dass jede relevante Anwendung aktualisiert wird – ein Vorgehen, bei dem unweigerlich einige übersehen werden und verwundbare Anwendungen nie repariert werden.
Der aufkommende Branchenbegriff für dieses „noch weiter vorverlagerte Shift Left“ lautet Secure Software Supply Chain – ein Ansatz, der künftig immer häufiger zum Einsatz kommen wird, insbesondere da immer mehr Geschäftsprozesse auf digitale Mechanismen umgestellt werden. Ich habe ihn hier nur kurz angerissen und hoffe, in einer künftigen Kolumne ausführlicher darauf einzugehen.
Die Wahrheit ist: DevOps ist je nach Umsetzung sowohl eine gute als auch eine schlechte Idee. Wird es auf einen trägen Anwendungslebenszyklus aufgesetzt, löst es kaum Probleme. Als Automatisierungskonzept in einer Anwendungsfließstraße eingesetzt, ist es ein leistungsstarkes Werkzeug für die digitale Transformation.
Siehe auch: Leitfaden zur digitalen Transformation: Definition, Arten und Strategie