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 anhand der folgenden Tabelle:

Cloud-Pfad wählen (SaaS vs Self-hosted)
→ Identity + Residency klären
→ Netzwerk zu Sources
→ RACI Vendor vs Platform
→ Auth/Secrets (Teil 9) + Betrieb (Teil 10)
→ 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.
• Netzwerk: 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 7 (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 10).

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 9).
2. Netzwerkpfad zu Sources (Private Link, Firewall Rules, Allowlists).
3. Stewardship: Domains, Glossary, Verantwortung — siehe openmetadata-governance.
4. Auswahl der ersten Quelle und ihres Testumfangs — 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 11 (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.

Den gewählten Cloud-Weg einrichten

Beim gehosteten Angebot:

1. Die erhaltene Einladung öffnen, Konto aktivieren und die tatsächliche Instanzadresse aufrufen. Bei fehlender Einladung Geschäftsadresse und Organisation prüfen.
2. Mit der vorgesehenen Identität anmelden. Bei zentraler Firmenanmeldung die Provider-Konfiguration aus Teil 9 verwenden; Rücksprungadresse und Gruppen müssen zu dieser Instanz passen.
3. Ein kleines Testobjekt suchen beziehungsweise anlegen und mit einer normalen Leseridentität öffnen. Administratorrechte nicht als Leserprüfung verwenden.
4. Für einen Connector prüfen, wo dessen Laufzeit betrieben wird. Der Runner benötigt einen Netzweg zur Quelle und deren passenden Lesezugang. Ein funktionierender Browserzugriff ersetzt diesen Weg nicht.

Self-hosted in der Cloud: Verwende den Serverweg aus Teil 7. Stelle zusätzlich Cloud-Netz, persistente Disks, Datenbank-/Suchdienstzugänge und die vorgesehene HTTPS-Adresse bereit. Prüfe danach Startzustand, Anmeldung und Neustart wie dort beschrieben.

Bei Zugangsproblemen Einladung, Identität und Organisation prüfen. Bei einem Verbindungsfehler zur Quelle aus der Runner-Umgebung testen. Die konkreten Anbietermenüs entnimmst du der Dokumentation des gebuchten Angebots.

Checkliste

• SaaS vs Self-hosted schriftlich entschieden?
• Ist klar, welche Komponenten ihr und welche der Anbieter konfiguriert?
• SSO und Residency geklärt?
• Private Connectivity zu kritischen Sources getestet?
• Erster Non-Produktion-Kurztest in der Cloud-Umgebung grün?
• Ausstieg/Export und Backup-Grenzen gelesen und akzeptiert?

Einrichtung abschließen

Die richtige Instanz ist erreichbar, Anmeldung und Leserzugriff funktionieren. Bei eingerichteter Quellenanbindung ist auch der Testlauf erfolgreich. Notiere Adresse und Konfigurationsstand bei Bedarf in den Installationsnotizen. Den laufenden Betrieb mit Sicherung und Updates behandelt Teil 10.

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-Kurztest nach Cloud-Deploy.
• OpenMetadata Deployment — Cloud-/Managed-Deploy-Hinweise.

Ressourcen

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