Ein ereignisgesteuertes Architekturmuster wirkt beim Entwurf oft günstiger als die Plattform, die es dauerhaft trägt. Für einen CTO ist deshalb nicht die erste Verbindung zwischen zwei Diensten entscheidend, sondern die Arbeit nach dem Rollout: Verträge ändern sich, Ereignisse müssen erneut verarbeitet werden, und jemand muss den Betrieb verantworten. Meine Position: Den Event-Bus würde ich in den meisten Fällen kaufen; die Regeln für Ereignisse müssen intern bleiben.
Ein selbst betriebener Event-Bus liefert noch kein belastbares Ereignismodell
Architekturmuster in der Softwareentwicklung verstehen hilft bei der Einordnung der Entwurfsentscheidung, unterschätzt für eine Kaufentscheidung aber leicht die Arbeit nach dem ersten produktiven Ereignis. Apache Kafka transportiert Nachrichten; es entscheidet nicht, was ein „Auftrag bestätigt“ fachlich bedeutet, wer das Feld ändern darf oder wie lange ein alter Konsument die bisherige Bedeutung erwarten kann. Diese Fragen bleiben auch dann beim Unternehmen, wenn Confluent Cloud die Broker betreibt.
Gerade diese Trennung wird in Business Cases verwischt, weil sich Brokerkosten leichter beziffern lassen als Abstimmung zwischen Teams. Für jedes Ereignis braucht es einen Eigentümer, eine dokumentierte Bedeutung, Regeln für Änderungen und einen Weg, fehlerhafte Nachrichten zu behandeln. OpenAPI 3.1 eignet sich für synchrone Schnittstellen; für Ereignisse können AsyncAPI und ein Schema Registry mit Avro oder JSON Schema die Verträge prüfbar machen. Keines dieser Werkzeuge legt jedoch fest, ob ein zurückgenommener Auftrag ein neues Ereignis erzeugt oder ein altes Ereignis „korrigiert“ wird. Das muss das verantwortliche Team entscheiden, weil Konsumenten sonst unterschiedliche Wahrheiten aus derselben Historie ableiten.
Ich würde keine eigene Kafka-Plattform aufbauen, nur weil bereits Kubernetes betrieben wird. Ein Kubernetes-Cluster nimmt dem Team weder Partitionsplanung noch Rebalancing, Replikationsüberwachung oder Wiederherstellung ab; er fügt lediglich eine weitere Ebene hinzu, auf der diese Aufgaben automatisiert und bei Fehlern untersucht werden müssen. Auch ein Operator ersetzt keinen Bereitschaftsdienst: Er kann einen gewünschten Zustand herstellen, aber nicht entscheiden, ob eine verspätete Nachricht fachlich noch verarbeitet werden darf.
Die Architekturentscheidung ist deshalb zweigeteilt. Den Transport kann ein Anbieter übernehmen; Ereignisnamen, Schemas, Zuständigkeiten und Löschregeln sollte das Unternehmen selbst kontrollieren. Wer beides als ein einziges „Event-Plattform-Projekt“ budgetiert, erkennt später nicht mehr, welcher Teil tatsächlich teuer ist und welcher Teil lediglich sichtbar wird, weil Kafka ihn nicht verbergen kann.
Die laufende Wartung steckt vor allem in Verträgen, Wiederholungen und Bereitschaft
Ein Ereignis ist veröffentlicht, sobald ein Konsument davon abhängt. Danach wird selbst ein scheinbar harmloses Feld zur Wartungsaufgabe: Ein neues Pflichtfeld kann alte Produzenten ausschließen; ein geänderter Statuswert kann Auswertungen verfälschen; eine längere Aufbewahrung kann Speicherkosten erhöhen. Ein Schema Registry kann inkompatible Änderungen erkennen, sofern die passende Kompatibilitätsregel konfiguriert ist. Er kann nicht erkennen, dass „versendet“ künftig einen anderen Geschäftszeitpunkt bezeichnet.
Für die Budgetdiskussion würde ich 24 Monate als frei wählbaren Betrachtungszeitraum ansetzen, statt nur den Einführungsaufwand zu vergleichen. Als kalkulatorischen Ansatz, nicht als gemessenen Branchenwert, würde ich pro beteiligtem Team jeden Monat einen halben Arbeitstag für Vertragsprüfungen und Abstimmung vorsehen. Der genaue Wert gehört nach einem Pilotversuch korrigiert; seine Aufnahme verhindert, dass wiederkehrende Arbeit im Projektbudget verschwindet. Zusätzlich braucht der Eigenbetrieb Zeit für Upgrades, Kapazitätsplanung, Zertifikate, Restore-Tests und Rufbereitschaft. Beim Kauf fallen diese Brokerarbeiten teilweise weg, während Integrations- und Vertragsarbeit bleibt.
Besonders teuer werden Wiederholungen, weil „Nachricht erneut zustellen“ nicht „Geschäftsvorgang gefahrlos erneut ausführen“ bedeutet. Kafka kann eine Zustellung wiederholen; der Konsument muss bei einer erneuten Verarbeitung trotzdem erkennen, ob eine Zahlung oder Benachrichtigung bereits ausgelöst wurde. Idempotente Verarbeitung kann etwa über einen eindeutigen Ereignisschlüssel und eine Transaktion in PostgreSQL 16 abgesichert werden. Die zusätzliche Tabelle und ihre Aufbewahrungsregel sind Wartungskosten des Musters, nicht des gewählten Brokers.
Auch Beobachtbarkeit entsteht nicht durch den Kaufvertrag. OpenTelemetry mit OTLP/gRPC kann Traces aus Produzenten und Konsumenten übertragen; Prometheus und Grafana können Verzögerungen und Fehlerquoten sichtbar machen. Das Team muss aber definieren, wann eine Verzögerung geschäftlich relevant wird und wer auf den Alarm reagiert. Diese mit promtool check rules event-gateway.yml prüfbare Prometheus-Regel ist ein kleiner, konkreter Teil davon:
groups:
- name: event-gateway
rules:
- alert: EventGatewayFehlerquote
expr: sum(rate(http_requests_total{job="event-gateway",code=~"5.."}[5m])) / clamp_min(sum(rate(http_requests_total{job="event-gateway"}[5m])), 0.001) > 0.02
for: 10m
labels:
severity: page
annotations:
summary: "Fehlerquote des Event-Gateways erhöht"
Die Schwelle von 2 Prozent ist ein einzustellender Startwert, kein allgemeingültiges Serviceziel. Bei geringem Verkehr braucht die Regel zusätzlich eine Mindestmenge an Anfragen, weil schon wenige Fehler sonst einen Alarm auslösen können. Entscheidend für die Kostenrechnung ist die Reaktion danach: Ein Dashboard behebt weder einen festhängenden Konsumenten noch erklärt es, ob dessen Rückstand nachgeholt werden darf.
Managed Kafka gewinnt standardmäßig; Eigenbetrieb braucht einen nachweisbaren Vorteil
Der direkte Vergleich lautet Confluent Cloud gegen selbst betriebenes Apache Kafka im KRaft-Modus. Confluent Cloud gewinnt, wenn das Unternehmen Ereignisse zuverlässig austauschen will, aber keinen strategischen Vorteil aus Brokerbetrieb zieht: Der Anbieter übernimmt einen Teil der Infrastrukturarbeit und kann Kapazität und Verfügbarkeit vertraglich zusagen. Der Preis besteht aus nutzungsabhängigen Gebühren, möglichen Kosten für Datentransfer und Funktionen sowie einer Abhängigkeit von Tarif, Region und Anbieterbetrieb. Vor einer Zusage müssen deshalb die tatsächlich benötigten Funktionen und Grenzen im konkreten Angebot stehen.
Eigenbetrieb gewinnt nur unter engeren Bedingungen: etwa wenn ein belastbarer Kostenvergleich bei stabiler, hoher Last günstiger ausfällt oder eine verbindliche Betriebsanforderung vom angebotenen Dienst nicht erfüllt wird. Sein Preis sind nicht allein Rechner und Speicher, sondern erfahrene Personen für Upgrades, Störungen und Wiederherstellung. Das gilt auch mit Terraform zur Bereitstellung, Argo CD für Änderungen und Renovate für Abhängigkeitsaktualisierungen, weil Automatisierung die Verantwortung für misslungene Änderungen nicht übernimmt.
Die Entscheidung sollte mit derselben Last und denselben Pflichten gerechnet werden. Ich würde in einer zu testenden Beispielannahme 30 Tage Aufbewahrung auf beiden Seiten verlangen und jeweils die Kosten für Speicherung, erneutes Lesen und Wiederherstellung erfassen. Ein günstiger Brokerbetrieb bei kürzerer Aufbewahrung wäre kein fairer Sieg, wenn die Anwendung für Wiederholungen längere Datenhaltung benötigt. Umgekehrt sollte ein eingekauftes Angebot nicht mit Funktionen belastet werden, die die Teams gar nicht einsetzen.
Service Level Objectives gehören ebenfalls in beide Rechnungen. Eine vorläufig vereinbarte Wiederanlaufzeit von 60 Minuten ist nur dann ein brauchbarer Vergleichswert, wenn ein Restore-Test oder eine Anbieterzusage beschreibt, was innerhalb dieser Zeit tatsächlich wieder funktioniert. „Broker erreichbar“ genügt nicht, wenn Konsumenten noch stundenlang Rückstand aufarbeiten. Ich würde außerdem festhalten, wer nachts eine fehlerhafte Nachricht stoppt, wer sie freigibt und wer den betroffenen Geschäftsprozess informiert. Beim Eigenbetrieb liegt diese Kette vollständig intern; beim Kauf wird nur ein Teil davon verlagert.
Der Kaufvertrag ist erst gut, wenn ein Ausstieg technisch vorgeführt wurde
Architekturmuster in der Softwareentwicklung: Ein Leitfaden ist ein nützlicher Ausgangspunkt für die Musterwahl; bei „Build or Buy“ würde ich jedoch früher nach dem Rückweg fragen. Ein gemanagter Dienst kann kurzfristig günstiger sein und langfristig Verhandlungsmacht kosten, wenn Anwendungen direkt an anbieterspezifische APIs, Identitätsregeln oder Zusatzfunktionen gebunden werden. Das ist kein Argument gegen den Kauf, sondern für eine bewusst begrenzte Abhängigkeit.
Ein Ausstiegstest muss mehr leisten als Nachrichten zu exportieren. Schemas und ihre Versionen müssen verfügbar sein, Konsumenten brauchen nachvollziehbare Startpositionen, und Berechtigungen müssen auf ein neues System übertragen werden können. OAuth 2.0 und OpenID Connect können Identitäten standardisieren; sie garantieren keine identischen Rechte zwischen zwei Plattformen. Auch Kafka-kompatible Protokolle beseitigen Unterschiede bei Betrieb, Quoten oder Zusatzdiensten nicht. Wer Portabilität behauptet, sollte deshalb einen Konsumenten samt Schema und Berechtigung auf der Zielumgebung starten und dessen Verhalten prüfen.
Im Vertrag würde ich klären, welche Exportwege vorhanden sind, wie Gebühren für ausgehende Daten berechnet werden und wie lange Zugriff nach einer Kündigung besteht. Intern würde ich mit OPA prüfbare Regeln für Änderungen an Berechtigungen erwägen, wenn mehrere Teams Topics selbst anlegen dürfen; ohne solche Regeln kann Self-Service stillschweigend neue Betriebs- und Freigabearbeit erzeugen. Eine eigene dünne Bibliothek kann wiederkehrende Einstellungen vereinheitlichen, sollte aber das Kafka-Protokoll nicht hinter einer umfassenden Eigenabstraktion verstecken, weil deren Pflege sonst zum nächsten Plattformprojekt wird.
Ein bestandener Ausstiegstest macht den Wechsel nicht kostenlos. Er macht seine Kosten sichtbar: Datenübertragung, parallelen Betrieb, Tests der Konsumenten und mögliche Unterbrechungen bei der Umstellung. Genau diese Sichtbarkeit stärkt die Kaufposition, weil der CTO Angebote nach realen Wechselhürden beurteilen kann statt nach einer bloßen Zusicherung von „offenen Standards“.
Ein begrenzter Pilot zeigt die Wartungsrechnung besser als ein Architekturdiagramm
Der Pilot sollte einen echten Änderungsfall enthalten, nicht nur erfolgreich gesendete Testnachrichten. Ein Produzent veröffentlicht ein versioniertes Ereignis, ein Konsument verarbeitet es idempotent, anschließend wird das Schema geändert und ein Teil der Ereignisse erneut zugestellt. Dabei werden Arbeitsstunden für Abstimmung, Diagnose und Korrektur protokolliert. So entsteht ein eigener Messwert statt einer Schätzung aus fremden Teams, deren Ereignisse und Bereitschaftsmodell anders aussehen.
Für den Vergleich gehören zwei getrennte Spalten ins Ergebnis: Aufwand für den Dienst und Aufwand für die fachlichen Verträge. Sonst erscheint Managed Kafka überteuert, weil ihm Vertragsarbeit zugerechnet wird, oder Eigenbetrieb zu billig, weil diese Arbeit im Anwendungsbudget steckt. Auch Rückstände, Wiederanlauf und der Export in eine zweite Umgebung sollten tatsächlich ausgeführt werden; eine bestandene Präsentation ist kein Nachweis dafür, dass der Betrieb später beherrschbar bleibt.
Beauftragen Sie als Erstes einen Verantwortlichen, einen bestehenden Ereignisfluss samt Konsument und Änderungsfall für den Pilot auszuwählen. Lassen Sie für genau diesen Fluss den Aufwand bei Confluent Cloud und bei Eigenbetrieb getrennt erfassen, einschließlich Bereitschaft und Ausstiegstest. Erst danach würde ich eine Plattform finanzieren: nicht weil das gewählte Muster modern wirkt, sondern weil seine wiederkehrende Arbeit einen benannten Eigentümer und einen belastbaren Preis hat.
