Dezentrales DevOps: Autonomie und Verantwortung für Entwicklungsteams

Inhaltsverzeichnis

Unternehmen sind auf leistungsstarke Entwicklungsteams angewiesen, um schnell auf veränderte Marktbedingungen reagieren zu können und um Kunden neue Produkte und Funktionen schneller bereitzustellen. Solche Teams zeichnen sich dadurch aus, dass sie klein und unabhängig sind und ihre Arbeit größtenteils oder vollständig unabhängig von anderen Teams erledigen – auch die meisten Entscheidungen treffen sie selbst. Ihre Flexibilität und Entwicklungsgeschwindigkeit müssen jedoch stets in Einklang mit den Unternehmensrichtlinien bleiben, sodass Sicherheit, Qualität und Zuverlässigkeit gewährleistet sind.

iX-tract

• Die zunehmende Komplexität Cloud-nativer Technologie-Stacks führt zu einer hohen kognitiven Belastung für Entwicklungsteams.
• Internal Developer Platforms bieten Werkzeuge, Dienste und Artefakte, um die Komplexität zu reduzieren und Entwicklungsteams den Bau gut strukturierter Anwendungen zu erleichtern.
• Die Decentralized Developer Platform ist eine besondere Variante, bei der erfahrene Entwicklungsteams kuratierte Patterns für das Bereitstellen und den Betrieb von Anwendungen in ihren eigenen Umgebungen nutzen.

Entwicklerinnen und Entwickler erleben die Notwendigkeit, Unternehmensanforderungen einhalten zu müssen, in der Regel als Bremsfaktor für ihre Entwicklungsarbeit – und darüber hinaus wächst die Liste an nichtfunktionalen Anforderungen immer weiter. Gleichzeitig ist die kognitive Belastung (Cognitive Load) der Teams gestiegen, da sie sich mit komplexen Technologie-Stacks auseinandersetzen müssen, um Cloud-native Anwendungen zu erstellen und auszuführen. Diese Diskrepanz können Unternehmen durch Platform Engineering reduzieren. Das Ziel: Softwarebereitstellung für die Produktteams umfassend vereinfachen. Eine Internal Developer Platform (IDP), im Folgenden kurz als Developer Platform bezeichnet, schafft dazu die Basis. Sie stellt eine Reihe von Selfservice-Diensten bereit, die Entwicklungsteams möglichst einfach und automatisiert konsumieren können.

Robert Hoffmann

Robert Hoffmann ist Senior Solutions Architect bei AWS und unterstützt Unternehmen auf ihrem Weg in die Cloud. Er beschäftigt sich leidenschaftlich mit Observability, Infrastruktur als Code und Entwicklerproduktivität.

Heise-Konferenz: CLC 2024

Im November 2024 richten iX und dpunkt.verlag die CLC-Konferenz – Continuous Lifecycle/ContainerConf – im Congress Center Rosengarten in Mannheim aus. Das Event greift seit 2014 alljährlich die wichtigsten Fragestellungen rund um Continuous Integration (CI), Continuous Delivery (CD), Dev(Sec)Ops und GitOps auf, um Antworten, Know-how und Hilfestellung für den Projektalltag zu vermitteln. Vom 12. bis 14. November setzt die CLC dieses Mal auf Themenschwerpunkte zu KI-gestütztem DevOps, Security und FinOps sowie Nachhaltigkeit.

Highlights aus dem Programm

• Der KI-gestützte Entwickler
• Nachhaltigkeit in der Cloud
• Boosting AI Innovation: Wie AI-Plattformen helfen, eure Use Cases auf die Straße zu bringen
• OpenTelemetry: Was macht eigentlich mein verteiltes System?
• Eine Pipeline als Produkt denken: Modularisierung, Versionierung, Testen, ...
• Die Leiche im Keller: Sicherheitsrisiken von CI/CD-Systemen
• Workload Identity: Die Zukunft der sicheren Authentifizierung

Bis zum 23. September können sich Interessierte zum Frühbucherpreis von 1049 Euro registrieren, Workshops kosten 649 Euro (alle Preise zzgl. MwSt.).

Dieser Artikel erläutert, wie sich Platform Engineering aus der DevOps-Bewegung entwickelt hat und welche Arten von Developer Platforms es gibt. Ein besonderer Fokus liegt dabei auf den Decentralized Developer Platforms. Sie ermöglichen ein Höchstmaß an organisatorischer Skalierbarkeit und Selfservice und begünstigen darüber hinaus die Eigenverantwortung der beteiligten Entwicklungsteams. Ein Überblick zu den Leitprinzipien und den erforderlichen technischen Fähigkeiten (Capabilities) einer Decentralized Developer Platform rundet den Beitrag ab.

Der Ursprung der Developer Platforms

Unternehmen bauen schon seit Jahren interne Developer Platforms auf, noch bevor sich der Begriff und das Konzept in der gesamten IT-Branche etabliert hatten. Amazon Web Services (AWS) beispielsweise spricht seit 2019 beim Aufbau von Plattformen in der Cloud treffend von Cloud Platform Engineering. AWS beschreibt es als das Anpassen der Standardkonfigurationen von AWS-Diensten an Unternehmensstandards. Die angepassten Dienste werden dann als per Selfservice anforderbare Produkte für interne Kunden (die Entwicklungsteams) angeboten und kontinuierlich verbessert.

Die Ursprünge des Platform Engineering lassen sich auf die DevOps-Methodik zurückführen. Das von Amazon-CTO Werner Vogels 2006 formulierte Paradigma "you build it, you run it" forderte Entwicklerinnen und Entwickler auf, sich mit dem täglichen Betrieb ihrer Software und letztlich mit ihren Kunden zu befassen. Dies führte zu einer Bewegung, die den Entwicklungsteams mehr Verantwortung für den Lebenszyklus ihrer Anwendungen überträgt – vom Schreiben des Codes bis zum Bereitstellen in Produktion. Gleichzeitig nahm auch die Komplexität der Anwendungen und der verwendeten Technologien zu: Beispielsweise begannen Entwicklungsteams, Monolithen in Microservices aufzubrechen und sie auf verteilten Plattformen wie etwa Kubernetes auszuführen, wobei die Infrastruktur und das Deployment "as Code" definiert sind. Darüber hinaus wählten sie Cloud-Dienste und Software-as-a-Service (SaaS), um undifferenzierte, aufwendige Betriebsaufgaben zu reduzieren und die Benutzererfahrung durch geringere Latenzzeiten, globale Verfügbarkeit und zusätzliche Funktionen zu verbessern.

Die Einführung dieser Technologien und die Entwicklung Cloud-nativer Anwendungen halfen den Teams, die Zeit bis zur Veröffentlichung neuer Software(versionen) zu verkürzen und den steigenden Erwartungen der Benutzer gerecht zu werden. Im Gegenzug stieg die kognitive Belastung beim Integrieren und Ausführen von Anwendungen (siehe Abbildung 1).

Platform Engineering reduziert die kognitive Belastung durch Bereitstellen von Tools, Diensten und Artefakten, sodass sich die Entwicklungsteams auf die Produktentwicklung konzentrieren können, im Idealfall mit verkürzter Vorlaufzeit und verbesserter Anwendungsqualität. Die konkrete Definition von Qualität hängt vom jeweiligen Kontext ab, aber eine gängige Methode ist das Well-Architected Framework von AWS, das anhand von sechs Säulen Leitlinien für das Entwickeln und den Betrieb sicherer und effizienter Anwendungen bietet (siehe Abbildung 2). Eine hochgradig automatisierte Selfservice-Developer-Platform ist sowohl für die Plattformteams, die sie entwickeln und pflegen, als auch für die Nutzerinnen und Nutzer – die Entwicklungsteams – von Vorteil. Die Plattformteams verwenden weniger Zeit für das Onboarding neuer Teams und das Bearbeiten von Tickets und gewinnen so mehr Zeit, die Developer Experience bei der Nutzung der Plattform zu verbessern. Die Entwicklungsteams können Ressourcen und Dienste bei Bedarf anfordern und sich dank geringerer kognitiver Belastung besser auf die Produktentwicklung konzentrieren.

Übergang zum dezentralisierten Betriebsmodell

Ein Unternehmen bietet in der Regel ein oder mehrere Betriebsmodelle für das Erstellen und Ausführen von Anwendungen an, und diese bestimmen die Eigenschaften der Developer Platform(s). Eine Haupteigenschaft, die das Betriebsmodell definiert, ist die Aufteilung der Verantwortlichkeiten zwischen Entwickler- und Plattformteams:

• Bei einem Modell mit zentralisierter Provisionierung liegt die Verantwortung für die Architektur, Bereitstellung und Verwaltung der Infrastruktur in erster Linie bei einem zentralen Plattformteam. Entwickler fordern die Bereitstellung von Ressourcen per Ticket an, das vom Plattformteam manuell abgearbeitet wird – was einige Zeit dauern kann.
• Das plattformgestützte Golden-Path-Modell ist ein Ansatz, der Entwicklungsteams einige Anpassungen erlaubt und gleichzeitig eine gewisse Konsistenz durch das Einhalten einer Reihe von Standards gewährleistet. In diesem Modell legen die Plattformteams bevorzugte Standards mit sinnvollen Vorgaben, Leitplanken und Best Practices in Form einiger typischer Architekturen fest. Die Entwicklungsteams nutzen diese Vorgaben als "goldenen Weg" (Golden Path). Sollen Entwicklerinnen und Entwickler noch mehr Freiheit und Selfservice-Optionen erhalten, bieten Plattformteams weitere Dienste über eine klar definierte Schnittstelle an, die Anwendungskonfiguration und -bereitstellung ermöglichen. In der Regel handelt es sich dabei um einen oder mehrere verwaltete Container-Cluster, bei denen die Plattformteams die Infrastruktur verwalten, während Entwicklungsteams die API des Clusters nutzen können, um Container auszuführen.
• Im eingebetteten DevOps-Modell verlagern sich mehr Verantwortlichkeiten auf die Entwicklungsteams, da geteilte oder dedizierte DevOps Engineers dem Team beitreten. Anhand der zentralen Plattformstandards implementieren die DevOps Engineers für die einzelnen Teams maßgeschneiderte Infrastrukturen, die sie bei Bedarf weiter anpassen können.