Cloud-Dateninfrastruktur: Services, Kosten & Migration
Die Cloud hat die Datenarchitektur dauerhaft verändert. On-Premise-Dateninfrastruktur, also eigene Server, SAN-Storage, proprietäre Appliances, ist zunehmend eine Legacy-Entscheidung. Aber Cloud-Dateninfrastruktur ist nicht eine einzige Sache. Sie ist ein Spektrum an Services und Trade-offs, die bewusste Architekturentscheidungen erfordern.
Cloud-native Datenservices
Jeder große Cloud-Anbieter bietet einen kompletten Data Stack. Das ist jeweils enthalten:
AWS: S3 (Storage), Glue (ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →/Catalog), Redshift (Warehouse), Athena (serverless SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen → auf S3), EMR (Spark), SageMaker (ML), Kinesis (Streaming), Lake Formation (Governance).
Google Cloud: GCS (Storage), BigQuery (Warehouse + Lake hybrid), Dataflow (Streaming/Batch-ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →), Vertex AI (ML), Pub/Sub (Messaging), Dataplex (Governance).
Azure: ADLS Gen2 (Storage), Synapse Analytics (Warehouse + Lake), Data Factory (ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →), Azure ML, Event Hubs (Streaming), Microsoft Purview (Governance).
Cloud Data Architecture Patterns
Wissenscheck
1. Was ist laut Lektion die empfohlene praktische Antwort auf die Build-vs.-Buy-Entscheidung?
2. Warum sind offene Tabellenformate (Iceberg, Delta Lake) und offene Compute-Frameworks (Spark) laut Lektion wertvoll?
3. Was ist laut Lektion der häufigste tatsächliche Grund, aus dem Organisationen am Ende Multi-Cloud-Architekturen betreiben?
4. Wählen Sie ALLE Aussagen, die für das KAUFEN von Anbieter-Datenprodukten sprechen (im Gegensatz zum Bauen).
Wählen Sie alle richtigen Antworten aus.
5. Wählen Sie ALLE korrekten Aussagen über Cloud-Dateninfrastruktur, wie sie in der Lektion dargestellt wird.
Wählen Sie alle richtigen Antworten aus.
Die Build-vs.-Buy-Entscheidung
Jeder CDO steht immer wieder vor dieser Entscheidung: eigene Lösungen bauen oder Anbieterprodukte kaufen?
Für Buy spricht: Speed to Value. Eine Snowflake-Implementierung dauert Wochen, nicht Jahre. Der Anbieter kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ümmert sich um Infrastruktur, Performance-Tuning und Upgrades. Ihr Team beschäftigt sich mit Datenproblemen, nicht mit Infrastrukturproblemen.
Für Build spricht: Kontrolle. Sie besitzen den Code, das SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, die Optimierung. Kein Vendor Lock-in. Keine Überraschungen durch Pricing pro Query. Open Source (Spark, Iceberg, Airflow) gibt Ihnen volle Flexibilität.
Die praktische Antwort: Kaufen Sie die Commodity-Komponenten (Storage, Compute, Orchestrierungs-SaaS), bauen Sie das, was Ihr Geschäft differenziert (proprietäre Datenmodelle, eigene ML-Pipelines, domänenspezifische Features).
Multi-Cloud und cloud-agnostische Architektur
Multi-Cloud klingt attraktiv (kein Vendor Lock-in, Best-of-Breed-Services), hat aber echte Kosten: operative Komplexität, Datentransferkosten, Zersplitterung der Team-Skills. Die meisten Organisationen, die Multi-Cloud nutzen, tun das aus regulatorischen Gründen (Anforderungen an Data Residency) oder als Ergebnis von M&A-Aktivitäten, nicht aus bewusster Entscheidung.
Offene Tabellenformate (Apache Iceberg, Delta Lake) und offene Compute-Frameworks (Apache Spark) reduzieren Lock-in, ohne die Komplexität von Multi-Cloud zu erfordern. Nutzen Sie sie als Absicherung.
Kostenarchitektur in der Cloud
Cloud-Datenkosten sind nicht trivial und werden leicht unterschätzt. Die wichtigsten Kostentreiber:
- Storage: Günstig, skaliert aber mit der Aufbewahrungsdauer. Setzen Sie Lifecycle-Policies um, verschieben Sie Daten nach 90 Tagen in günstigere Tiers, archivieren Sie nach einem Jahr.
- Compute: Der wesentliche variable Kostenblock. Warehouse-Query-Kosten skalieren mit den gescannten Daten. Clustering und Partitionierung reduzieren die gescannten Daten und senken damit direkt die Kosten.
- Egress: Daten zwischen Regionen oder zurück ins On-Premise zu bewegen ist teuer. Konzipieren Sie so, dass regionenübergreifende Datenbewegung minimal bleibt.
- Tools und Lizenzen: Snowflake, Databricks und ähnliche Tools legen ihr Pricing auf die Cloud-Kosten obendrauf. Modellieren Sie die Gesamtkosten, bevor Sie sich festlegen.
Bei Spotify hat ein dediziertes Team für „Data Platform Cost Optimization" die Cloud-Ausgaben um 30 % gesenkt, ohne Funktionalität zu reduzieren, über Regeln zur Query-Optimierung, Data-Retention-Policies und Compute-Scheduling. Ein CDO, der die Kostenarchitektur nicht verantwortet, verantwortet die Datenplattform nicht wirklich.
Migrationsstrategie: On-Prem in die Cloud
Die meisten CDOs erben ein Stück On-Premise-Infrastruktur. Die Cloud-Migration ist fast immer die richtige Richtung, erfordert aber eine Reihenfolge:
1. Assessment und Inventar: Was existiert, was kostet es, was unterstützt es
2. Kandidaten mit geringem Risiko identifizieren: Historische Daten, Archivdaten, Reporting-Workloads
3. Zuerst Lift-and-Shift: Workloads verschieben, bevor sie optimiert werden; der Nachweis, dass die Cloud funktioniert, senkt organisatorischen Widerstand
4. Inkrementell refactoren: Nach der Stabilisierung auf cloud-native Patterns optimieren
5. Schrittweise abschalten: On-Premise erst abschalten, wenn die Cloud-Workloads stabil sind
Vermeiden Sie die Falle, alles auf einmal neu zu architektieren. Viele Cloud-Migrationen scheitern nicht an technischer Komplexität, sondern daran, dass der Scope zu ambitioniert ist.
Quizfragen
1. Was ist der wesentliche Grund, aus dem die meisten Organisationen Multi-Cloud einsetzen?
A) Um Kosten zu senken
B) Aus regulatorischen Gründen oder infolge von M&A
C) Um die Performance zu verbessern
D) Um die Architektur zu vereinfachen
Antwort: B
2. Was ist der wesentliche Vorteil offener Tabellenformate wie Apache Iceberg?
A) Sie sind schneller als proprietäre Lösungen
B) Sie senken die Storage-Kosten
C) Sie reduzieren Vendor Lock-in, ohne eine Multi-Cloud-Architektur zu erfordern
D) Sie werden von den Cloud-Anbietern gepflegt
Antwort: C
3. Welche Reihenfolge ist in der Cloud-Migrationsstrategie die richtige?
A) Zuerst refactoren, dann migrieren
B) Alles migrieren und gleichzeitig optimieren
C) Inventarisieren → einfache Fälle migrieren → Lift-and-Shift → refactoren → abschalten
D) On-Premise abschalten, bevor migriert wird
Antwort: C
Was Sie aus dieser Lektion umsetzen
Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.
- Migration in die Cloud: Inventar, Lift-and-Shift, dann schrittweises Refactoring
Verwandte Artikel
Aktuelle Blogartikel, die auf dieser Lektion aufbauen.
- DataCloud-Datenkosten senken, ohne die Analytics zu ruinierenCloud-Rechnungen für Dateninfrastruktur gehören inzwischen zu den am schnellsten wachsenden Posten in IT-Budgets von Unternehmen, und die meisten Organisationen zahlen zu viel, ohne es zu merken. Dieses Playbook gibt CDOs eine konkrete Abfolge von Maßnahmen, um die Ausgaben deutlich zu senken und die analytische Leistungsfähigkeit zu erhalten.
- DataWarum Ihre Datenarchitektur Sie belügt und was moderne CDOs dagegen tunDie meisten Unternehmen glauben, sie hätten eine Datenarchitektur. Was sie tatsächlich haben, ist eine Ansammlung historischer Zufälle, zusammengehalten von guten Absichten und teurer Middleware. So bauen die CDOs, die Wettbewerbsvorteile neu definieren, anders.