DevOps- und Microservice-Architektur

Microservices sind eine Architekturentscheidung, kein Reifeabzeichen. Ein sauber gegliederter modularer Monolith lässt sich oft leichter testen, ausliefern und verstehen, wenn ein Team das Produkt verantwortet, die Last überschaubar ist und sich Domänengrenzen noch bewegen. Verteilte Dienste werden plausibel, wenn Fähigkeiten wirklich eigene Verantwortung, einen anderen Release-Takt, unabhängige Skalierung, besondere Sicherheitsbehandlung oder Fehlerisolierung benötigen. NobleJackal hält diesen Entscheidungsfall fest, bevor eine Zerlegung empfohlen wird. Übersteigt der Betriebsaufwand den erwarteten Nutzen, kann die fachlich richtige Antwort eine Sanierung des Monolithen und seiner Delivery-Strecke sein.

Die Bestandsaufnahme erfasst, was tatsächlich läuft: Anwendungen, Module, Zeitjobs, Queues, Datenbanken, externe Anbieter, Repositories, Build-Systeme, Umgebungen, Netzpfade, Secrets, manuelle Schritte und die Personen, die Änderungen freigeben oder Störungen bearbeiten. Repräsentative Änderungen werden von der Anforderung bis zur Produktion verfolgt, repräsentative Vorfälle von der Erkennung bis zur Wiederherstellung. Architekturzeichnungen werden mit Quellcode, Konfiguration, Telemetrie und gelebter Teamarbeit abgeglichen. Ein aktuelles Datum macht ein Diagramm noch nicht zur Wahrheit. Unbekannte Abhängigkeiten und undokumentierte Produktionsausnahmen bleiben im Register sichtbar.

Qualitätsmerkmale machen aus einem allgemeinen Modernisierungswunsch eine belastbare Entscheidung. Für die maßgeblichen Nutzerwege werden Verfügbarkeit, Latenz, Durchsatz, Datenintegrität, Wiederherstellung, Sicherheit, Datenschutz, Prüfbarkeit, Release-Unabhängigkeit, Wartbarkeit, Portabilität und Kosten priorisiert. Wo Messwerte vorhanden sind, werden Ausgangslage und Evidenzqualität dokumentiert. Ein Ziel wie „häufiger deployen“ reicht nicht, solange Änderungsklasse, Team, Umgebung, Messfenster sowie akzeptable Fehler- und Wiederherstellungsbedingungen fehlen.

Die Leistungseinheit wird schriftlich begrenzt: Anwendungen, Domänen, Teams, Umgebungen, Servicekandidaten, Schnittstellen, Datenwege, Pipelines, Infrastruktur, Migrationswellen, Workshops, Umsetzungsaufgaben, Prüfungen und Supportzeitraum. Preis auf Anfrage bedeutet kein unbegrenztes Plattformteam. Produktentwicklung, Individualsoftware, Managed Cloud Operations, Cybersecurity-Architektur, Backup und Disaster Recovery, Hosting, Cloud-Verbrauch und fortlaufende Rufbereitschaft bleiben eigenständige Leistungen, sofern sie nicht ausdrücklich aufgenommen sind.

Servicekandidaten werden aus Geschäftsfähigkeiten und Bounded Contexts abgeleitet und anschließend daran geprüft, ob die Organisation sie wirklich tragen kann. Funktionen, die gemeinsam geändert werden, eine Transaktion teilen oder ständig koordinierte Releases benötigen, gehören möglicherweise zusammen, selbst wenn sie sich im Schaubild trennen lassen. Eine Fähigkeit mit eigenem Team, Datenlebenszyklus, Lastprofil oder Sicherheitsbereich kann dagegen ein unabhängiges Deployment rechtfertigen. Der Entscheidungsnachweis bewahrt verworfene Zuschnitte und Zielkonflikte, damit spätere Teams die Grenze nachvollziehen können.

Jede Grenze braucht einen Vertrag. Synchrone APIs, asynchrone Ereignisse, Batch-Austausch und Dateiübergaben werden mit Produzent, Verbraucher, Eigentümer, Schema, Authentisierung, Autorisierung, Verfügbarkeitserwartung, Timeout, Wiederholung, Idempotenz, Version und Stilllegung erfasst. Ein OpenAPI-Dokument kann eine HTTP-Schnittstelle beschreiben; zum Liefervertrag gehören ebenso Verhalten, Fehlerfälle und Änderungsregeln. Consumer- und Kompatibilitätstests schützen wichtige Beziehungen, ersetzen aber keinen End-to-End-Nachweis für reale Abläufe.

Die Datenhoheit wird vor einer Herauslösung geklärt. System of Record, zulässige Leser und Schreiber, Identitätsschlüssel, Schutzklasse, Aufbewahrung, Migrationsweg und Verantwortlicher für den Abgleich sind benannt. Eine gemeinsam genutzte Datenbank wird nicht als Serviceautonomie umetikettiert. Überschreitet ein Geschäftsvorgang mehrere Grenzen, werden Konsistenz, Reihenfolge, Doppellieferung, Kompensation, Replay und Fehlerbehebung bewusst entworfen. Outbox, Saga oder Event Sourcing kommen nur zum Einsatz, wenn ihr zusätzlicher Aufwand gerechtfertigt ist und das Team ihn beherrschen kann.

Die Abhängigkeitskarte umfasst Aufrufe, Events, Identitäten, DNS, Zertifikate, Konfiguration, Queues, Caches, Datenbanken und externe Dienste. Für jeden wichtigen Pfad wird entschieden, was bei langsamen, ausgefallenen, doppelt antwortenden oder mehrdeutigen Abhängigkeiten geschieht. Timeouts, begrenzte Wiederholungen, Backoff, Circuit Breaker, Bulkheads, Load Shedding und ein geordneter Funktionsabbau werden gezielt eingesetzt und geprüft. Alle Resilienzmechanismen pauschal einzubauen kann ebenso viel Ungewissheit schaffen wie ungeregeltes Fehlerverhalten.

Ein Dienst ist erst dann unabhängig deploybar, wenn Quelle, Build, Artefakt, Konfiguration, Datenbankänderung und Releasebefugnis ohne versteckte Abstimmung vorankommen. Das Delivery-Design dokumentiert Repository-Verantwortung, Branch- und Reviewregeln, reproduzierbare Build-Eingaben, Abhängigkeitsrichtlinien, Artefaktidentität und die Promotion durch die Umgebungen. Ein Container-Image ist ein versioniertes Releaseobjekt, kein Beweis für Cloud-Native-Reife. Provenienz, Software Bill of Materials oder Signaturen werden in der benötigten und betreibbaren Tiefe eingeführt; ihre Existenz wird nicht als automatische Lieferkettensicherheit verkauft.

Continuous Integration führt jene Prüfungen aus, die den jeweiligen Dienst und seine Verbraucher schützen. Unit-, Integrations-, Contract-, Migrations-, Sicherheits-, Policy-, Performance- und Smoke-Tests erhalten definierte Stufen und ein eindeutiges Abbruchverhalten. Aufwendige Prüfungen können geschichtet statt auf jeden Commit gelegt werden, doch ein kritisches Gate darf nicht stillschweigend optional sein. Testdaten, Fremdabhängigkeiten und Umgebungsunterschiede werden so weit kontrolliert, dass Ergebnisse interpretierbar bleiben. Eine grüne Pipeline belegt nur, dass ihre benannten Prüfungen für eine benannte Revision bestanden wurden.

Infrastruktur-, Konfigurations- und Policyänderungen unterliegen derselben Versions- und Reviewdisziplin wie Anwendungscode. Infrastructure as Code beschreibt die einbezogenen Ressourcen; es überführt nicht automatisch jede Konsoleneinstellung und jeden Providerstandard in einen kontrollierten Zustand. Secrets bleiben aus Repositories heraus, Zugriffe folgen dem Least-Privilege-Prinzip und Produktionszugänge haben Eigentümer, Rotation und Widerrufsweg. Planergebnisse, Drift, State-Ablage, Providerversionen und Break-Glass-Eingriffe werden erfasst, damit Automatisierung keinen undokumentierten Betriebsweg verdeckt.

Das Releaseverfahren richtet sich nach Risiko und Plattform. Rolling, Canary, Blue-Green, Feature Flags oder gestufte Auslieferung benötigen Gesundheitssignale, Entscheidungsbefugnis, Abbruchkriterien und einen Wiederherstellungsweg. Datenbank- und Ereignisänderungen bleiben während der Koexistenz kompatibel. Rollback wird nicht versprochen, wenn eine irreversible Datenänderung bereits wirksam ist; dann sind Vorwärtskorrektur, Restore oder Kompensation festgelegt. Ein erfolgreicher Deploymentbefehl gilt nicht als Nachweis, dass Nutzer das beabsichtigte Verhalten erhalten haben.

Zuverlässigkeit beginnt bei Nutzer- und Geschäftsabläufen, nicht allein bei Serverlaufzeit. Für wichtige Verhaltensweisen werden Service Level Indicators definiert; bei ausreichender Evidenz werden Objectives mit Messfenster, Ausschlüssen und Eigentümer vorgeschlagen. Error Budgets können Zuverlässigkeit und Änderungstempo ausbalancieren, verlangen aber vertrauenswürdige Messung und einen echten Entscheidungsprozess. Ein neu formuliertes SLO ist kein historischer Leistungsnachweis, und ein Provider-SLA beschreibt nicht den vollständigen Weg des Kunden.

Metriken, Logs und Traces werden gemeinsam entworfen. Korrelationskennungen begleiten eine Anfrage durch die Dienste; Ereignisse liefern brauchbaren Kontext, ohne unnötige personenbezogene Daten oder Secrets offenzulegen; Dashboards verbinden Symptome mit Abhängigkeiten und Releaseversionen. OpenTelemetry kann eine anbieterneutrale Telemetriestruktur schaffen, doch Instrumentierungsqualität, Sampling, semantische Konventionen, Speicherung und Alarmdesign bleiben bewusste Entscheidungen. Ziel ist die Antwort auf eine reale Betriebsfrage, nicht eine Wand aus farbigen Diagrammen.

Sicherheit wird in Identitäten, Schnittstellen und Delivery eingebaut. Menschliche und Workload-Identitäten werden getrennt, Berechtigungen eng gehalten, Service-zu-Service-Vertrauen explizit gemacht, Secrets rotiert, Netzpfade kontrolliert und API-Autorisierung auf Objekt- und Funktionsebene getestet. Das Threat Model umfasst Administrationswege, Build-Systeme, Registries, Abhängigkeiten, exponierte APIs, Queues, Datenspeicher und Drittanbieter. NIST SSDF und OWASP können die Auswahl stützen; weder zertifiziert eine konkrete Umsetzung noch ersetzt es systemspezifische Tests und Prüfungen.

Jeder produktive Dienst braucht einen benannten Eigentümer, eine Eskalationsroute und Betriebsnachweise. Alarme sind an handlungsfähige Zustände gebunden, Runbooks nennen sichere Diagnose- und Wiederherstellungsschritte, Vorfälle bewahren Zeitlinie und Entscheidungen für die Nacharbeit. Kapazität, Quoten, Rate Limits, Queue-Wachstum, Zertifikate, Backups, Restore-Abhängigkeiten und Cloud-Verbrauch werden geprüft, bevor sie zum Notfall werden. Rund-um-die-Uhr-Monitoring, aktive Incident Response, Managed Cloud Operations und Disaster-Recovery-Zusagen gelten nur, wenn sie gesondert besetzt, kalkuliert und schriftlich vereinbart sind.

Eine Brownfield-Migration wird als Folge kontrollierter Koexistenzzustände geplant. Strangler, Branch by Abstraction, Modularisierung oder gezielter Ersatz können eine Fähigkeit verlagern, während das bestehende System weiterhin Nutzer bedient. Routing, Identität, Datensynchronisierung, Abgleich und Verantwortung werden für den Übergang entworfen, nicht nur für das Zielbild. Ein Big-Bang-Ersatz kommt nur mit vertretbarem Cutover-Plan, erprobter Wiederherstellung und einer Instanz infrage, die das konzentrierte Risiko bewusst übernimmt.

Der erste Ausschnitt wird nach Lernwert und beherrschbarer Auswirkung gewählt, nicht danach, wie leicht er sich zeichnen lässt. Er durchläuft den vorgesehenen Quell-, Vertrags-, Pipeline-, Infrastruktur-, Observability-, Sicherheits- und Supportweg. Die Abnahme umfasst Funktion, Kompatibilität, Leistung, Fehlerverhalten, Datenabgleich, Deployment und Recovery. Pilotnachweise dürfen die Architekturentscheidung ändern: Eine Herauslösung kann erweitert, neu zugeschnitten, pausiert oder in eine modulare Anwendung zurückgeführt werden, ohne dass evidenzbasierte Korrektur als mangelnder Ehrgeiz gilt.

Delivery-Leistung wird gemessen, ohne Kennzahlen in Quoten zu verwandeln. Deployment Frequency, Change Lead Time, Failed Deployment Recovery Time, Change Fail Rate und Deployment Rework können Engpässe sichtbar machen, solange Definition und Grundgesamtheit stabil bleiben. Sie werden zusammen mit Zuverlässigkeit, Sicherheit, Kundenauswirkung, Teamlast und Kosten gelesen. Ein Team wird nicht dafür belohnt, Releases künstlich zu teilen, Vorfälle zu verstecken oder den Nenner zu verändern. Baselines gehen Behauptungen voraus; ein Architekturrelease erhält keinen Erfolg zugeschrieben, der vorher entstand.

Die Übergabe verbindet Diagramme mit dem laufenden Bestand. Sie erfasst Repositories, Services, Verträge, Daten, Pipelines, Infrastrukturcode, Umgebungen, Konten, Secret-Verantwortliche, Dashboards, Alarme, Runbooks, Recovery-Abhängigkeiten, Kostenstellen, Anbieter, offene Risiken, Ausnahmen und Stilllegungsarbeit. Zugriffe werden über freigegebene Wege übertragen; das übernehmende Team demonstriert die vereinbarten Betriebsabläufe. Weitere Migrationswellen, Plattformbetrieb, Cloud-Verbrauch, Monitoring, Rufbereitschaft, Sicherheitsarbeit und Produktentwicklung benötigen einen neuen oder fortgeführten schriftlichen Umfang.