Architect ist der dritte Schritt im SAFe DevOps Health Radar, Teil von Continuous Exploration. In diesem Video erkläre ich, wie wir die minimale Architektur definieren, die benötigt wird, um eine Hypothese zu beweisen und die kontinuierliche Wertlieferung an Kunden zu ermöglichen.
Wo Architect in die Pipeline passt#
In den vorherigen Schritten haben wir Ideen von der Business- und Kundenseite gesammelt und sie in Epics mit Hypothesen umgewandelt (Hypothesize). Danach haben wir die echten Kundenbedürfnisse analysiert, Marktforschung betrieben und das Geschäftsmodell aktualisiert (Collaborate & Research). Nun definieren wir im Architect-Schritt die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen.
Warum minimale Architektur?#
Der Zweck dieses Schritts ist nicht, eine vollständige, finale Architektur zu entwerfen. Wir wollen gerade genug Architektur definieren, um die kontinuierliche Wertlieferung zu ermöglichen. Wenn sich eine Hypothese als wahr herausstellt, wollen wir bereit sein, kontinuierlich Wert zu liefern, ohne erst eine Continuous Delivery Pipeline aufbauen oder angesammelten Technical Debt beheben zu müssen.
Trennung von Deployment und Release#
Eines der grundlegenden Konzepte in DevOps ist die Trennung von Deployment und Release. Ein Deployment ist das Bringen von kompiliertem Code in die Produktion mit einem Feature Toggle, der ausgeschaltet ist. Ein Release ist das Einschalten dieses Feature Toggles in der Produktion. Durch die Trennung dieser beiden Aktivitäten ermöglichen wir das kontinuierliche Deployment von Code in die Produktion, was ein zentraler Enabler für die kontinuierliche Wertlieferung an unsere Kunden ist.
Architektur für Testbarkeit#
Als Architekten und Entwickler müssen wir unsere Systeme so gestalten, dass sie ordentlich getestet werden können. Das bedeutet:
- Ordentliche Tests und ordentliche Testdaten haben
- Lose gekoppelte Architekturen mit kleinen Komponenten oder Services bauen, die jeweils einen einzelnen Zweck erfüllen
- Über die API-Schicht testen, die stabile und zuverlässige Test-Interfaces bietet
- Den Microservice-Architekturstil verwenden, bei dem kleine, unabhängige Services in separaten Containern laufen
Lose gekoppelte Systeme sind nicht nur einfacher zu testen, sondern auch einfacher zu ändern, zu deployen und unabhängig zu skalieren.
Architektur für Releasefähigkeit#
In einem grossen System hat man typischerweise mehrere Komponenten, Services oder Microservices. Jede davon sollte ihren eigenen Deployment- und Release-Zyklus haben. Zum Beispiel könnte eine Komponente alle zwei Wochen releasen, eine andere nur bei Bedarf für Sicherheits-Patches, und eine dritte etwa monatlich. Das Gesamtsystem könnte einen vierteljährlichen Release-Zyklus haben.
Durch das Design für unabhängige Deployment- und Release-Zyklen können Teams in ihrem eigenen Tempo Wert liefern, ohne von anderen Teams oder Komponenten blockiert zu werden.
Architektur für den Betrieb#
Beim Architekturdesign müssen wir die operativen Bedürfnisse von Anfang an berücksichtigen. Das bedeutet, darüber nachzudenken, wie das System in der Produktion überwacht und betrieben wird, ohne sich direkt auf dem Produktionsserver einzuloggen. Dafür brauchen wir:
- Ein gutes Telemetrie- und Logging-System, das alle relevanten Daten aus der Produktionsumgebung extrahiert
- Nicht nur Applikationsdaten, sondern auch Geschäftsdaten, weil wir unsere Hypothese beweisen und den gelieferten Wert messen müssen
- Feature Toggles, mit denen wir problematische Features schnell abschalten können, was die Betreibbarkeit massiv verbessert
Feature Toggles ermöglichen es uns auch, Features zunächst nur für eine Teilmenge der Benutzer einzuschalten, damit wir beobachten können, wie sich das System in der Produktion verhält, bevor wir einen vollständigen Rollout machen.
Architektur für schnelle Wiederherstellung#
Wir brauchen einen Plan für den Fall, dass in der Produktion etwas schiefgeht. Dazu gehört:
- Ein klarer Incident-Response-Plan zur Wiederherstellung nach schwerwiegenden Vorfällen
- Die Fähigkeit, Incidents schnell zu analysieren, um Grundursachen zu identifizieren
- Sicherstellen, dass die Geschäftskontinuität auch während Ausfällen aufrechterhalten werden kann
Für schnelle Wiederherstellung zu designen bedeutet, dass die Architektur selbst schnelles Rollback, Isolierung von Fehlern und schnelle Wiederherstellung unterstützt.
Sicherheit: Threat Modelling#
Sicherheit muss in der Architekturphase berücksichtigt werden. Wir wenden Threat Modelling an, was folgende Schritte umfasst:
- Alle Bedrohungen identifizieren, die Ihre Anwendung betreffen könnten
- Potenzielle Angreifer analysieren, die Ihr System ins Visier nehmen könnten
- Angriffsvektoren abbilden, die diese Angreifer nutzen könnten
- Die Sicherheitsbedenken adressieren, die aus dieser Analyse hervorgehen
Dies gilt sowohl für internetfähige Anwendungen als auch für interne Anwendungen. Es ist wichtig, Sicherheitsexperten aus Ihrer Organisation einzubeziehen, weil sie die Bedrohungen, Angreifer und Angriffsvektoren am besten kennen.
Was der Architect-Schritt produziert#
Der Output dieses Schritts ist:
- Ein Solution Intent (auch Solution Blueprint oder Solution Design genannt): eine architektonische Idee für die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen
- Ein klares Set von nicht-funktionalen Anforderungen (die “-ilities”): Verfügbarkeit, Nutzbarkeit, Zuverlässigkeit, Testbarkeit, Releasefähigkeit und weitere
Diese nicht-funktionalen Anforderungen sind Randbedingungen, die für jede User Story im Backlog gelten. Sie müssen zusammen mit den funktionalen Anforderungen getestet und verifiziert werden.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für den Architect-Schritt. Sie bewerten die Effektivität Ihres Teams beim Architekturdesign für Continuous Delivery:
- Sit: Die Architektur ist monolithisch und fragil. Sie ist schwer zu ändern und erfordert das Management komplexer Abhängigkeiten über viele Komponenten und Systeme hinweg.
- Crawl: Die Architektur ist überwiegend monolithisch, aber einige Anwendungen und Systeme sind lose gekoppelt.
- Walk: Die Architektur ist grösstenteils entkoppelt, erlaubt aber kein Release on Demand.
- Run: Die Architektur ist auf Wertlieferung ausgerichtet, mit wenigen Abhängigkeiten zwischen Komponenten und Systemen.
- Fly: Die Architektur ist für Release on Demand und Betreibbarkeit gebaut.
Kernaussagen#
- Nur die minimale Architektur definieren. Nicht über-architekturieren. Gerade genug bauen, um die Hypothese zu beweisen und Continuous Delivery zu ermöglichen.
- Deployment von Release trennen. Feature Toggles ermöglichen kontinuierliches Deployment und gleichzeitige Kontrolle darüber, wann Features für Benutzer sichtbar werden.
- Für Testbarkeit designen. Lose gekoppelte Architekturen mit API-Level-Testing und containerisierten Microservices machen die Verifikation einfach.
- Von Anfang an für den Betrieb designen. Telemetrie, Logging und Feature Toggles sind keine Nachgedanken. Sie sind Architekturentscheidungen.
- Für Ausfälle planen. Für schnelle Wiederherstellung architekturieren, damit schwerwiegende Vorfälle nicht zu langen Ausfällen werden.
- Threat Modelling früh anwenden. Bedrohungen, Angreifer und Angriffsvektoren in der Architekturphase identifizieren und Sicherheitsexperten einbeziehen.