Produktion in der Cloud / SaaS

Herausforderung

„Cloud“ wird als eine Option behandelt. Tatsächlich unterscheiden sich Managed SaaS und Self-hosted auf Cloud-K8s stark in Identity, Netz, Residency und Wer patched. Ohne diese Unterscheidung entstehen Lücken: niemand besitzt Private Connectivity, der Vendor-Vertrag schweigt zu Exit/Export, und Stewardship glaubt, „die Cloud macht Governance“.

Typische Symptome:

• SaaS ist gebucht, SSO kommt „nächsten Sprint“ — bis dahin Default-Admin im Chat.
• OM-UI kurz öffentlich erreichbar „zum Testen“.
• Warehouse nur über das öffentliche Internet, obwohl Private Link möglich wäre.
• Niemand weiß, ob Backup und Upgrade beim Dienstleister oder bei euch liegen.

Ansatz

Explizit eine Cloud-Variante wählen und im Deploy-Pfad-Record (Teil 1) festhalten:

Cloud-Pfad wählen (SaaS vs Self-hosted)
→ Identity + Residency klären
→ Netzwerk zu Sources
→ RACI Vendor vs Platform
→ Auth/Secrets (Teil 6) + Betrieb (Teil 7)
→ Connectoren (openmetadata-connectors)

Pflichtthemen vor Go-Live

• Identity: Entra ID / Okta / vergleichbar — vor dem ersten Produktion-User. Default-Admin nur Break-Glass.
• Data Residency: Region, Unterauftragsverarbeiter, Vertragsgrenzen dokumentieren.
• NetIn einem Satz:** Private Connectivity zu Warehouse/BI; keine öffentlich offenen Admin-UIs ohne Kontrollen.
• Secrets: Cloud Secret Manager oder Vault; Connector-Identities getrennt von Human-SSO.
• Ausstieg: Export/Backup-Strategie und Kündigungs-/Datenrückgabe-Klauseln, falls der Dienstleister gewechselt wird.
• Kosten/Limits: Ingestion-Jobs, API-Limits, Speicher — als Betriebsrisiko, nicht als Überraschung.
• RACI: Wer patched die App? Wer owns Connector-Credentials? Wer eskaliert bei Stale Jobs?

Self-hosted Cloud vs On-Prem

Self-hosted in der Cloud folgt Teil 4 (Härte, getrennte Ingestion, Restore). Zusätzlich: Cloud-IAM, Network Policies, Backup in Object Storage, Regionalität. Der Unterschied zu On-Prem ist die Infrastrukturplattform — nicht die Governance-Logik. Wenn ihr Self-hosted wählt, übernehmt ihr dieselben Betriebsnachweise wie On-Prem (Teil 7).

Managed SaaS: was ihr trotzdem liefern müsst

Auch wenn der Vendor die Control Plane hostet, bleibt bei euch:

1. IdP-Anbindung und Rollenmodell (Teil 6).
2. Netzwerkpfad zu Sources (Private Link, Firewall Rules, Allowlists).
3. Stewardship: Domains, Glossary, Verantwortung — siehe openmetadata-governance.
4. Connector-Scope und Decision Records — siehe openmetadata-connectors.
5. Verständnis von Vendor-SLAs: Was ist Backup, was ist RTO/RPO, was ist euer Export?

Nach dem Deploy

Quellen anbinden → openmetadata-connectors. Domains, Glossary, Discoverability → openmetadata-governance. AI-Kontext später nur auf freigegebenen Assets. Teil 8 (dbt-Artefakte) erst, wenn Warehouse-Connector und Environments sauber sind.

Häufige Anti-Patterns

• SaaS buchen und SSO „nächsten Sprint“ planen.
• Öffentliche IP zum OM-UI „kurz zum Testen“.
• Annehmen, der Dienstleister owned Stewardship und Data Quality.
• Self-hosted Cloud ohne Restore-Test (gleiche Falle wie On-Prem).
• Cloud-Pfad im Deploy-Record nicht festgehalten — drei Monate später streiten Platform und Security.

Hilfe beim Umsetzen

Füllt den Cloud/SaaS Decision Record mit: Variante, Region, RACI (Vendor vs Platform), SSO-Zieltermin, Private-Connectivity-Status, Exit/Export. Ohne RACI entstehen Ticket-Pingpong bei Stale Jobs.

Wenn SaaS: Identity und Source-Netz sind eure Arbeit — Stewardship auch. Wenn Self-hosted Cloud: Teil-4-Härte + Cloud-IAM. Danach OpenMetadata-Ingestions-Generator für Non-Prod-Smoke.

Checkliste

• SaaS vs Self-hosted schriftlich entschieden?
• RACI Dienstleister/Platform unterschrieben und kommuniziert?
• SSO und Residency geklärt?
• Private Connectivity zu kritischen Sources getestet?
• Erster Non-Produktion-Smoke in der Cloud-Umgebung grün?
• Ausstieg/Export und Backup-Grenzen gelesen und akzeptiert?

Artefakt

Cloud/SaaS Decision Record plus RACI-Einseiter und Residency-/Netz-Skizze.

Tools

• Governance Starting-Point Decision — SaaS vs Self-hosted und Residency als Entscheidung.
• Architecture Fit — Private Link, Region und Integrationsgrenzen.
• OpenMetadata-Ingestions-Generator — erster Non-Produktion-Smoke nach Cloud-Deploy.
• OpenMetadata Deployment — Cloud-/Managed-Deploy-Hinweise.

Ressourcen

• OpenMetadata Deployment
• Dienstleister-Doku der gewählten Managed-Option (falls genutzt)