Daten- und Messaging-Capabilities als Service
DBaaS, Kafka-as-a-Service und Data-Platform-Patterns auf K8s.
Lernziele
Nach dieser Lektion kannst du erklären, warum Datenbanken und Messaging-Systeme als Plattform-Capabilities angeboten werden sollten, wie DBaaS und Kafka-as-a-Service auf Kubernetes aussehen und welche Trade-offs zwischen Self-Service-Geschwindigkeit und Daten-Governance du navigierst. Du kannst Stateful-Workloads als Platform-Verantwortung von Stateless-Workloads abgrenzen und typische Betriebsfallen bei Daten-Services erkennen.
Das Problem: Jedes Team betreibt seine eigene Datenbank
Ein Entwickler braucht PostgreSQL für Staging. Ohne Plattform-Service passiert eines von drei Dingen: Er startet einen Postgres-Pod ohne Backup und ohne Monitoring, er installiert eine lokale Docker-Instanz, die nie Production-Charakter hat, oder er schreibt ein Ticket — und wartet fünf Tage. Für Kafka gilt das Gleiche in teurer: Drei Teams deployen jeweils einen eigenen Kafka-Cluster mit drei Broker-Pods, ZooKeeper (oder KRaft) und ohne einheitliches Schema-Registry — und keiner macht Upgrades, weil „das halt Team-Betrieb” ist.
Daten und Messaging sind anders als Stateless-Workloads. Ein Deployment-Fehler ist ein Rollback; ein Datenbank-Fehler ist Datenverlust. Deshalb gehören Daten- und Messaging-Capabilities in die Verantwortung des Platform-Teams — als Service mit Self-Service-Provisioning, eingebautem Backup, Monitoring und klaren Grenzen.
DBaaS: Datenbanken als API-Request
Database-as-a-Service auf Kubernetes bedeutet: Ein Team fordert postgres, staging, small an — analog zum Compute-Environment aus Lektion 31 — und bekommt eine lauffähige Instanz mit Connection-String, Backup-Schedule und Monitoring-Dashboard. Technisch steckt dahinter ein Operator (CloudNativePG, Zalando Postgres Operator, Percona, Strimzi für Kafka) plus ein Provisioning-Controller.
Was die Plattform liefert:
- Standard-Tiers mit definierten CPU, RAM, Storage und IOPS — kein „mach mal 500 Gi ohne Limit”.
- Automatische Backups mit Point-in-Time-Recovery und dokumentierter Retention.
- Monitoring über die Observability-Schicht aus Lektion 32 — Connection-Count, Replication-Lag, Disk-Usage als Standard-Dashboards.
- Secrets-Integration aus Lektion 34 — dynamische Credentials aus Vault, nicht
postgres/postgresim Helm-Values. - Netzwerk-Isolation — die Datenbank ist nur aus dem Team-Namespace erreichbar, nicht cluster-weit.
Was das Team liefert: Schema, Migrations, Connection-Pool-Konfiguration in der App. Was es nicht liefert: PVC-Sizing für Production, Backup-Strategie, Operator-Upgrades.
Kafka-as-a-Service: Messaging ohne Eigenbetrieb
Kafka ist der Sonderfall unter den Daten-Services: Stateful, ressourcenintensiv, upgrade-komplex und mit Netzwerk-Topologie-Anforderungen. Ein Self-Service-Kafka-Cluster pro Team skaliert weder technisch noch wirtschaftlich.
Das Platform-Muster: Shared Kafka-Cluster mit Tenant-Isolation über Topics und ACLs. Teams beantragen Topics und Consumer-Groups per API oder Portal; die Plattform setzt ACLs, Quotas und Retention. Schema Registry (Apicurio oder Confluent-kompatibel) erzwingt Schema-Kompatibilität — kein Team publiziert unkontrolliert Breaking Changes in ein Shared Topic.
Für Teams mit echten Isolationsanforderungen (Compliance, extreme Last): dedizierte Cluster auf Anfrage — aber als Ausnahme mit Genehmigung, nicht als Default.
Data-Platform-Patterns auf K8s
Über Einzelinstanzen hinaus entstehen auf reifen Plattformen Muster, die du kennen solltest:
Provisioning-API: Einheitlicher Endpoint für alle Data-Services — POST /data-services mit type, tier, environment. Intern dispatcht der Controller zum richtigen Operator. Entwickler lernen eine API, nicht fünf verschiedene CRDs.
Day-2-Operations zentralisiert: Backup-Restore-Tests, Operator-Upgrades, CVE-Patching — alles Platform-Verantwortung. Teams werden über Wartungsfenster informiert, führen aber keine kubectl-Eingriffe am Operator aus.
Kosten-Transparenz: Storage und Compute für Daten-Services sind teuer. Showback pro Team — auch wenn ihr nicht intern verrechnet — schafft Bewusstsein für Retention, Index-Größe und Topic-Volumen.
Disaster Recovery als Vertrag: RPO und RTO pro Tier dokumentiert. „Small” Staging darf 24 Stunden Datenverlust haben; „Large” Production nicht. Die Erwartung muss vor dem Provisioning stehen, nicht im Incident.
Stateful vs. Stateless: die Ownership-Grenze
| Aspekt | Stateless (Team) | Stateful (Plattform) |
|---|---|---|
| Deployment | GitOps, Workload-Chart | Operator + Provisioning-API |
| Skalierung | HPA, Replica-Count | Tier-Upgrade, Storage-Resize |
| Backup | Nicht relevant | Automatisch, Plattform-owned |
| Upgrade | Rolling Update der App | Operator-Version, Plattform-geplant |
| Incident | Team On-Call | Platform On-Call (Lektion 39) |
Diese Tabelle ist dein Argument in Architektur-Reviews, wenn ein Team „lieber selbst” eine Datenbank betreiben will.
Praxis: PostgreSQL-Instanz per Self-Service anfordern
- Request:
data-service create --type postgres --tier small --env staging --team checkout. - Validierung: Quota-Check (wie viele DBs hat das Team?), Policy (nur erlaubte Tiers in Staging).
- Provisioning: CloudNativePG-Cluster im Team-Namespace, PVC, Service, Vault-Credentials.
- Auslieferung: Connection-String im Portal, Grafana-Dashboard-Link, Backup-Schedule-Dokumentation.
- App-Anbindung: Team setzt Connection-String via ExternalSecret, führt Migration aus.
- Restore-Test (Plattform): Quartalsweise Restore in eine Test-Instanz — nicht das Team, sondern die Plattform beweist, dass Backups funktionieren.
Wenn Schritt 6 fehlt, hast du kein DBaaS, sondern eine Datenbank mit Backup-Checkbox.
Typische Stolperfallen
Operator ohne Day-2-Plan: CloudNativePG installiert, aber niemand macht Upgrades oder Restore-Tests. Der Operator wird zum Single Point of Failure.
Kein Storage-Limit: Ein Team füllt ein 2-Ti-PVC — und blockiert den Storage-Backend-Pool für alle.
Shared Kafka ohne ACLs: Jedes Team kann jedes Topic lesen. Compliance-Incident vorprogrammiert.
Staging-DB mit Production-Daten: Snapshot-Restore aus Prod nach Staging ohne Masking — DSGVO-Problem. Anonymisierungs-Pipeline gehört zur Plattform.
Self-Service ohne Deprecation: Teams provisionieren Instanzen und vergessen sie. Automatisches Cleanup nach Inaktivität oder Kosten-Reporting ist Pflicht.
Interview-Vorbereitung
Auf „Wie bietest du Datenbanken als Service an?” antwortest du: Problem (Team-eigene DBs ohne Backup, Governance, Upgrades) → Lösung (Operator-basiertes DBaaS mit Tiers, Self-Service-API, zentrale Day-2-Ops) → Grenze (Team besitzt Schema und App-Anbindung, Plattform besitzt Infrastrukturmanagement) → Messaging (Shared Kafka mit ACLs und Schema Registry, dedizierte Cluster als Ausnahme).
Follow-ups:
- „Wann erlaubst du Team-eigene Datenbanken?” — Fast nie in Production; in Staging mit klaren Limits und ohne Production-Daten, oder als dokumentierter Escape Hatch.
- „Wie machst du Upgrades bei Stateful Workloads?” — Operator-Upgrade in Wartungsfenster, Canary-Cluster (Lektion 38), Backup vor Upgrade, Rollback-Plan.
- „DBaaS auf K8s vs. Managed Cloud-RDS?” — RDS wenn Cloud-Lock-in akzeptabel und Betriebsaufwand minimiert; Operator-basiert wenn Multi-Cloud, einheitliche API oder Kosten bei Scale.
Zusammenfassung
Daten- und Messaging-Capabilities als Service geben Teams Self-Service für PostgreSQL, Kafka und ähnliche Systeme — mit Operator-Betrieb, Backup, Monitoring und Secrets-Integration durch die Plattform. Stateful Workloads gehören in Platform-Ownership; Teams liefern Schema und App-Logik. Shared Kafka mit ACLs und Schema Registry schlägt dutzende Team-Cluster. Ohne Restore-Tests, Storage-Limits und Deprecation-Policies wird DBaaS zu einem Datenverlust-Roulette.
Mit den Plattform-Services steht das Fundament — jetzt definieren wir, wie zuverlässig sie sein müssen: SLIs, SLOs und Error Budgets für interne Plattformen.