An der Conf42 DevSecOps 2024 Konferenz habe ich meinen Ansatz zur Architektur für Continuous Delivery vorgestellt. Nach über 21 Jahren bei Zühlke, in denen ich branchenübergreifend an DevOps-Transformationen gearbeitet habe, sehe ich immer wieder dasselbe fundamentale Problem: Wertströme, die durch Mauern der Verwirrung gebrochen werden. In diesem Vortrag zeige ich, wie Organisationen den Weg von Projekt-Denken zu Produkt-Denken schaffen, Qualität und Sicherheit von Anfang an einbauen, für Betreibbarkeit architekturieren und Platform Engineering zur Skalierung nutzen können.
Der gebrochene Wertstrom#
Wenn ich als Berater Unternehmen besuche, sehe ich fast immer dasselbe Bild. Das Business hat grossartige Ideen, schreibt sie in Word-Dokumente und Jira-Tickets und wirft sie über die Mauer der Verwirrung zum Entwicklungsteam. Die Entwickler implementieren etwas und werfen es zum Testing weiter. Die Tester schauen auf die Anforderungen (die nie ganz mit dem Gebauten übereinstimmen), testen etwas und werfen es zum Betrieb weiter. Der Betrieb sagt: “Das wird in der Produktion nie funktionieren.” Irgendwie schaffen sie es trotzdem. Schliesslich sieht der Kunde das Ergebnis und sagt: “Was ist das? Das löst unser Problem nicht.”
Die blaue Linie in diesem Bild ist der Wertstrom, und er wird durch diese Mauern der Verwirrung gebrochen. Die Ursache sind Silo-Organisationen mit unterschiedlichen Zielen, fehlender Abstimmung, Legacy-Systemen, unflexiblen Prozessen und kulturellem Widerstand.
Diese Herausforderungen stammen aus der Art, wie wir historisch Software entwickelt haben. Früher lieferten wir in grossen Wasserfall-Batches mit fixem Scope, Budget und Zeit. Um 2000 wechselten wir zu Agile mit kleineren Inkrementen. Aber wir machen immer noch Projekte, obwohl unsere Kunden eigentlich Produkte wollen.
Von Projekten zu Produkten#
Ein Projekt fokussiert auf Output: liefere diese 10 Features in sechs Monaten für 200'000 Euro. Ein Produkt fokussiert auf Outcome: löse das Problem des Kunden und verändere sein Verhalten. DevOps unterstützt diesen Wandel, denn es ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das es Teams ermöglicht, sich über den Wertstrom zu organisieren und kontinuierlich Wert zu liefern.
Der Begriff “DevOps” selbst ist nicht perfekt. Er impliziert nur Entwicklung und Betrieb. Manche schlagen DevSecOps, BizDevOps oder andere Varianten vor. Ich sage immer, wir bräuchten etwas wie “DevSecBizArcCompQAOps”, und ich bin sicher, ich würde trotzdem jemanden vergessen. Der Punkt ist: DevOps bedeutet, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.
«DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das alle Menschen, Prozesse und Technologien zusammenbringt, um kontinuierlich Wert zu liefern.»
Warum DevOps wichtig ist: Die Wissenschaft#
Das Buch Accelerate (The Science of DevOps) identifiziert 24 Schlüsselfähigkeiten, die Verbesserungen in der Software-Delivery-Performance treiben. Diese Fähigkeiten erstrecken sich über fünf Kategorien: Continuous Delivery, Architektur, Produkt und Prozess, Lean Management und Monitoring sowie Kultur.
Die Forschung bildet auch die Beziehungen zwischen diesen Fähigkeiten ab. Ich betrachte dies als eines der wichtigsten Bilder für jeden, der eine DevOps-Transformation durchführt: Es zeigt, was man investieren muss (linke Seite), um die gewünschten Ergebnisse (rechte Seite) zu erreichen.
Die State-of-DevOps-Berichte vergleichen Low Performer mit High Performern. Die Zahlen sind massiv bei Deployment-Frequenz, Lead Time, Time to Recovery und Change Failure Rate. Die Vorteile übersetzen sich in das, was jeder CIO möchte: schnellere Time-to-Market, mehr Wert fürs Geld, höhere Qualität, höhere Kundenzufriedenheit und top qualifizierte Mitarbeitende.
Qualität einbauen: Shift Left Testing#
Qualität ist essenziell für Continuous Delivery. Wenn man sich Unternehmen wie SpaceX und Tesla anschaut, investiert Elon Musk etwa 50% des Budgets für neue Produkte in automatisiertes Testing. So können sie schnelle Innovation auf den Markt bringen. Die meisten Unternehmen investieren deutlich weniger.
Traditionelles Testing folgt einem V-Modell mit verzögertem Feedback. Ein Requirements Engineer schreibt ein Feature, ein anderer eine Story, ein Entwickler schreibt Code, und wenn wir Glück haben, auch Tests. Dann, Monate später, testet ein Tester die Story und ein anderer das Feature. Die Feedback-Schleife kann drei Monate, sechs Monate oder sogar ein Jahr dauern.
Die Alternative ist der Shift Left mit Behavior Driven Development (BDD) und Test Driven Development (TDD). Abnahmekriterien im Given/When/Then-Format vorab definieren, zuerst den Test schreiben, dann den Code implementieren. Das kehrt die traditionelle Testpyramide um: Statt vieler langsamer, teurer End-to-End-Tests erhält man eine massive Menge schneller, günstiger Unit-Tests. Der Fokus verschiebt sich vom Finden von Fehlern zum Verhindern von Fehlern.
Sicherheit einbauen: DevSecOps#
Eine Continuous-Delivery-Pipeline ist mehr als CI/CD. Sie beginnt mit Continuous Exploration (Ideenfindung, Backlog Management, Requirements Engineering) und endet mit Release on Demand (Feature Toggles). Innerhalb dieser Pipeline muss Sicherheit in jeder Phase eingebaut sein:
- Planung: Threat Modeling zur Analyse von Angriffsvektoren und zur Risikominderung
- Coding: Merge Requests und Pull Requests mit Peer Review
- Build: Statische Sicherheitsanalyse, Software Composition Analysis, Lizenz-Compliance, Container Scanning, Secret Detection
- Testing: Dynamische Sicherheitsanalyse
- Produktion: Penetrationstests und kontinuierliches Sicherheits-Monitoring
Architektur für Betreibbarkeit#
Wenn wir “you build it, you run it” praktizieren, wird Betreibbarkeit zu einer erstklassigen Anforderung. Proaktive Erkennung bedeutet, dass unsere Monitoring-Systeme uns basierend auf Toleranzschwellen alarmieren, bevor Kunden Probleme bemerken. Disaster-Recovery-Verfahren müssen vorhanden und regelmässig geübt werden.
Monitoring hat sich erheblich weiterentwickelt. Zwei-Tier-Systeme brauchten grundlegende Metriken und Logs. Drei-Tier-Anwendungen erforderten Application Monitoring mit Traces. Heutige verteilte, serviceorientierte Architekturen verlangen volle Observability, oft ergänzt durch AIOps, um aus den riesigen Datenmengen Sinn zu machen.
«Wenn man ein System, ein Subsystem oder einen Microservice architekturiert, muss man immer denken: Wie wird das in der Produktion betrieben?»
Platform Engineering: Der Schlüssel zur Skalierung#
Moderne Softwareentwicklung erfordert von Teams, dass sie sich um Infrastruktur, Laufzeitumgebungen, CI/CD-Pipelines, Monitoring, Sicherheits-Tools, Support-Tools, Kostenmanagement, Wartung und Zugriffsmanagement kümmern. Ach ja, und sie wollen auch noch eine Anwendung bauen. Wenn man das über mehrere Teams skaliert, entstehen Inkonsistenzen, Redundanzen, neu erfundene Räder und eine erdrückende kognitive Belastung.
Platform Engineering löst dieses Problem. Ein Plattform-Team baut ein Produkt (die Plattform), das standardisierte Laufzeitumgebungen, DevSecOps-Fähigkeiten, Zugangs- und Identitätsmanagement, Monitoring und Observability sowie CI/CD-Pipelines bereitstellt. Die Produkt-Teams bauen, betreiben und warten ihre Produkte auf dieser Plattform.
Das ist kein neues Silo. Das Plattform-Team erstellt ein Produkt, das andere Teams nutzen wollen. Die Teams besitzen weiterhin ihre Produkte, betreiben sie und überwachen sie. Die Plattform ermöglicht es ihnen nur, DevOps zu machen, ohne das Rad neu zu erfinden.
Gartner, BCG und McKinsey sind sich einig: Platform Engineering wird in den nächsten fünf Jahren entscheidend sein.
Kernaussagen#
- Von Projekten zu Produkten wechseln. Den Kunden ins Zentrum stellen und seine Probleme lösen, statt Feature-Listen abzuarbeiten.
- Qualität von Anfang an einbauen. BDD und TDD nutzen, um das Testing nach links zu verschieben. Tests vor dem Code schreiben, um Fehler zu verhindern statt zu finden.
- Sicherheit von Anfang an einbauen. DevSecOps über die gesamte Delivery-Pipeline anwenden, von Threat Modeling in der Planung bis zu kontinuierlichem Monitoring in der Produktion.
- Für Betreibbarkeit architekturieren. Bei jeder Komponente darüber nachdenken, wie sie in der Produktion betrieben wird, und in Full-Stack Observability investieren.
- Platform Engineering zur Skalierung nutzen. Eine standardisierte Plattform bauen, damit Produkt-Teams sich auf die Wertlieferung konzentrieren können statt auf Tool-Management.
- Wir treten in das Zeitalter der industrialisierten Softwareentwicklung ein. Platform Engineering ist das Fundament, das Teams befähigt, DevSecOps zu praktizieren und kontinuierlich Wert zu liefern.