Der erste aus dem Monolithen gelöste Service erzeugt nicht nur ein neues Deployment. Er erzeugt eine zusätzliche Adresse für Störungen, Versionswechsel und Zuständigkeitsfragen. Für einen CTO ist deshalb die Wahl zwischen Eigenbau und Einkauf keine Frage der Architekturästhetik. Meine Position: Solange ein Unternehmen den Betrieb einer Service-Plattform nicht als eigenes Produkt finanzieren will, sollte es deren Infrastruktur überwiegend kaufen.
Der erste zusätzliche Service schafft eine dauerhafte Betriebsschicht
Ein Monolith hat Wartungskosten, die niemand wegdiskutieren sollte. Seine Prozesse teilen aber häufig denselben Release-Takt, dieselbe Laufzeitumgebung und einen klaren Ort für Fehlersuche. Nach der Extraktion eines Services müssen mindestens zwei Deployments, ihre Kommunikation und ihre Datenänderungen zusammenpassen. Das bleibt auch dann Arbeit, wenn der neue Service fachlich klein ist: Ein zurückgerolltes Deployment muss beispielsweise noch mit Nachrichten umgehen können, die eine neuere Version bereits verschickt hat.
Der Beitrag Monolith Modernisierung: Schrittweise zur Microservices Architektur macht die Reihenfolge der Zerlegung zum Gegenstand; für die Budgetentscheidung fehlt mir daran die Frage, wer jede neue Betriebsaufgabe dauerhaft übernimmt. Kubernetes kann Container neu starten, entscheidet aber nicht, ob eine wiederholte Zahlung fachlich zulässig ist. OpenTelemetry kann einen Trace über Servicegrenzen verbinden, erkennt aber ohne gepflegte Instrumentierung keinen fehlenden Geschäftsbeleg. Beides sind keine Einwände gegen die Werkzeuge, sondern Aufgaben, die mit ihrer Einführung einen Besitzer brauchen.
Als frei gewählte Größe für eine erste Kalkulation nehme ich 8 Services an. Für jeden davon braucht das Team mindestens eine benannte Verantwortung für Alarme, Abhängigkeiten und Releases; die Zahl ist keine allgemeine Mindestgröße für Microservices. Bei PostgreSQL 16 etwa müssen Schemaänderungen mit laufenden Anwendungsversionen verträglich bleiben. Flyway 10 führt Migrationen aus, kann aber nicht entscheiden, ob eine ältere Anwendung nach einer Spaltenänderung weiter schreiben darf. Bei Kafka kommt zusätzlich die Pflege von Topics, Aufbewahrungsregeln und Konsumenten hinzu. Wer dafür niemanden einplant, hat die Arbeit nicht eingespart, sondern in den Bereitschaftsdienst verschoben.
Ich würde keine interne Plattform auf Vorrat bauen, bevor der erste abgegrenzte Service seine Betriebsanforderungen gezeigt hat. Der Grund ist nicht mangelnder Ehrgeiz: Vorher entworfene Standards für Deployments, Dashboards und Freigaben werden oft an vermuteten statt an beobachteten Problemen optimiert. Zuerst sollten ein Runbook, ein verantwortliches Team und ein Rollback-Verfahren für einen konkreten Service existieren. Erst dann lässt sich erkennen, welche wiederholte Arbeit ein gemeinsames Plattformteam tatsächlich automatisieren müsste.
Eigenbau gewinnt nur, wenn Plattformpflege eine finanzierte Aufgabe ist
Die Entscheidung lässt sich an zwei benannten Optionen prüfen: Eigenbau mit selbstverwaltetem Kubernetes, Argo CD und Prometheus gegen einen Managed Stack aus AWS EKS, Amazon RDS und Datadog. Der Eigenbau gewinnt, wenn eigene Betriebsanforderungen die Kontrolle über Cluster-Upgrades, Datenspeicherung und Alarmierungsregeln rechtfertigen und ein dauerhaftes Plattformteam verfügbar ist. Der Managed Stack gewinnt, wenn die Architektur vor allem einen zuverlässigen Standardbetrieb braucht, weil der Anbieter Teile der Wartung übernimmt. AWS EKS verwaltet dabei die Kubernetes-Control-Plane, nicht automatisch Anwendung, Konfiguration und Bereitschaftsdienst.
Die Kosten sollten mit offen gelegten Annahmen verglichen werden, nicht mit einer Cloud-Rechnung aus dem ersten Monat. Für ein fiktives Entscheidungsbeispiel setze ich beim Eigenbau 1,5 Vollzeitstellen zu je 140.000 Euro jährlichen Vollkosten und 24.000 Euro für Infrastruktur an: zusammen 234.000 Euro pro Jahr. Beim Managed Stack unterstelle ich 72.000 Euro für Dienste und 0,6 Vollzeitstellen für Integration und laufende Pflege: zusammen 156.000 Euro. Diese Beträge sind weder gemessene Unternehmenskosten noch veröffentlichte Anbieterpreise. Anwendungsentwicklung und der in beiden Varianten nötige fachliche Bereitschaftsdienst fehlen auf beiden Seiten gleichermaßen.
Der Abstand von 78.000 Euro in diesem Modell beweist daher nicht, dass Einkauf immer billiger ist. Er zeigt, welche Annahmen der CTO widerlegen müsste: Sinkt der interne Pflegeaufwand wirklich auf 0,6 Stellen? Treiben Datenvolumen, Logs und Traces die nutzungsabhängigen Gebühren höher? Braucht ein eigener Cluster ohnehin spezialisierte Mitarbeiter, weil mehrere bestehende Produkte dieselbe Plattform nutzen? Eine belastbare Rechnung weist solche Positionen getrennt aus, statt sämtliche Personalkosten pauschal als „ohnehin vorhanden“ zu behandeln.
Helm 3 und Argo CD automatisieren die Ausbringung, verursachen aber selbst Versions- und Konfigurationspflege. Prometheus benötigt Entscheidungen über Aufbewahrung und Kardinalität; Grafana-Dashboards müssen nach Änderungen an Metriknamen weiter verständlich sein. Terraform-Konfigurationen senken die Handarbeit bei Infrastrukturänderungen, verlangen jedoch Reviews und Tests gegen den tatsächlichen Anbieterzustand. Wer Eigenbau wählt, sollte diese Arbeiten als Produkt-Backlog mit Verantwortlichem und Budget führen. Ohne dieses Budget ist „wir behalten die Kontrolle“ lediglich eine freundlichere Bezeichnung für unbezahlte Wartung.
Ein Managed Stack kauft Entlastung, aber keinen fertigen Betrieb
Der Beitrag Monolith Modernisierung: Schritt fuer Schritt zur Microservices beschreibt den Weg in einzelnen Schritten; der Einkauf verdient vor dem nächsten Schritt eine eigene Betriebsprobe. Ein Vertrag über verwaltete Dienste beantwortet noch nicht, wer bei einer gestörten Bestellung die Ursache zwischen Anwendung, Netzwerk, Datenbank und Anbieter eingrenzt. Diese Arbeit bleibt beim eigenen Team, weil nur dort der fachliche Sollzustand bekannt ist.
Das gilt besonders für Beobachtbarkeit. OpenTelemetry liefert ein herstellerübergreifendes Format für Instrumentierung und Export, aber ein Exporter muss konfiguriert und nach Bibliotheks-Upgrades überprüft werden. Datadog kann Traces speichern und anzeigen; die Entscheidung, welche Attribute keine hohen Kosten oder unbrauchbaren Suchergebnisse erzeugen, bleibt beim Kunden. Als vertraglich und technisch zu prüfenden Zielwert würde ich für einen kritischen Dienst festlegen, dass ein Alarm innerhalb von 15 Minuten nach einem reproduzierbaren Ausfall bei der zuständigen Bereitschaft ankommt. Ob das gelingt, muss ein Test zeigen; aus einem Produktdatenblatt folgt es nicht.
Ein kleiner Cluster-Test macht zumindest sichtbar, ob das Team Deployments selbst ausführen und ihren Zustand prüfen kann. Die folgenden Befehle benötigen kubectl, Zugriff auf einen Kubernetes-Cluster, Rechte zum Anlegen eines Namespace und Zugriff auf das Container-Image. Sie testen weder Alarmierung noch Wirtschaftlichkeit:
set -eu kubectl create namespace platform-check trap 'kubectl delete namespace platform-check --ignore-not-found' EXIT kubectl -n platform-check create deployment probe --image=nginx:1.27 --replicas=2 kubectl -n platform-check rollout status deployment/probe --timeout=120s kubectl -n platform-check get pods -o wide kubectl -n platform-check get deployment probe
Gerade der unscheinbare Rest ist für die Kaufentscheidung aufschlussreich. Kann die Bereitschaft nach einem fehlgeschlagenen Rollout erkennen, ob ein Image nicht gezogen wird, ein Pod nicht startet oder eine Anwendung nicht bereit ist? Liegt die Lösung beim Anbieter, muss der Vertrag einen passenden Supportweg vorsehen; liegt sie beim eigenen Team, braucht es Zugang, Berechtigungen und Übung. Ein Managed Stack reduziert bestimmte Wartungsaufgaben, weil der Anbieter Komponenten betreibt. Er beseitigt nicht die Notwendigkeit, eine Störung bis zur richtigen Zuständigkeit einzugrenzen.
Verträge und Exit-Tests sind aussagekräftiger als Funktionslisten
Vor dem Kauf würde ich drei Vorgänge durchspielen: ein Upgrade, einen längeren Teilausfall und den Export der Daten zu einem anderen Betreiber. Das ist keine abstrakte Exit-Forderung. Bei Amazon RDS muss etwa geklärt sein, wie ein Restore getestet wird und wer währenddessen Schreibzugriffe stoppt. Bei einem Kafka-Angebot sind Nachrichtenformat, Aufbewahrungsdauer und Konsumentenstände für einen Wechsel relevant, weil ein bloßer Datenexport noch keinen unterbrechungsarmen Weiterbetrieb ermöglicht. Debezium 2.6 kann Änderungen aus Datenbanken erfassen; sein Connector- und Schema-Betrieb bleibt dennoch Wartungsarbeit.
Für den Einkauf ist ein zu verhandelnder Grenzwert von beispielsweise 24 Stunden bis zu einem bereitgestellten, verwendbaren Datenexport konkreter als die Zusage „Daten gehören dem Kunden“. Der Wert muss zur tatsächlichen Datenmenge und zum Wiederanlaufplan passen. Ebenso sollte der Vertrag ausweisen, wer Upgrades ankündigt, welche alten Versionen wie lange nutzbar bleiben und ob Support auch bei Fehlern zwischen zwei Diensten hilft. Ohne diese Angaben trägt das interne Team das Integrationsrisiko, obwohl es für verwalteten Betrieb bezahlt.
Den Eigenbau würde ich mit demselben Maßstab prüfen. Ein dokumentiertes Terraform-Repository ist noch kein Exit-Plan, wenn nur eine Person seine Variablen und Freigaben versteht. Ein PagerDuty-Eskalationsplan ist noch keine belastbare Bereitschaft, wenn Alarme bei einem Test niemanden mit ausreichenden Rechten erreichen. Als im eigenen Betrieb zu messende Kennzahl eignet sich die Zeit vom Auslösen einer Teststörung bis zur ersten handlungsfähigen Reaktion. Sie trennt eine vorhandene Werkzeugkette von einer tatsächlich nutzbaren Betriebsfähigkeit.
Meine Entscheidungsvorlage für den CTO wäre deshalb eine laufende Kostenrechnung samt Verantwortungsmatrix: Wer patcht, wer testet Wiederherstellungen, wer bezahlt nutzungsabhängige Telemetrie, wer entscheidet bei einem fehlgeschlagenen Release? Der Managed Stack ist die bessere Voreinstellung, solange die Antworten für den Eigenbau zusätzliche, nicht finanzierte Stellen voraussetzen. Eigenbau wird erst dann zur überzeugenden Alternative, wenn mehrere Produkte dieselben nachweislich benötigten Standards nutzen und ein Team deren Wartung ausdrücklich übernimmt.
Der nächste Beschluss sollte einen Störungstest finanzieren
Beauftragen Sie für einen bereits abgegrenzten Service einen gemeinsamen Störungstest mit Entwicklung, Betrieb und potenziellem Anbieter. Lassen Sie ein Deployment fehlschlagen, eine Wiederherstellung auslösen und die Zuständigkeiten protokollieren. Tragen Sie anschließend die tatsächlich geleisteten Stunden und die offenen Aufgaben in beide Kostenmodelle ein. Erst diese Liste zeigt, welche Wartung Sie kaufen können und welche Ihr Team behalten muss.
