Cloud Deployment Model
Beschreibt Muster zur Bereitstellung von IT-Ressourcen in Public, Private, Hybrid oder Community Clouds sowie SaaS/PaaS/IaaS-Varianten.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Betriebsfähigkeiten führen zu hohen Betriebskosten
- Falsche Datenlokation kann rechtliche und Compliance-Risiken erzeugen
- Unklare Verantwortlichkeiten zwischen Cloud-Provider und Kunden
- Frühzeitige Einbindung von Compliance- und Sicherheitsverantwortlichen
- Automatisierung für Bereitstellung, Sicherheit und Monitoring
- Kostentransparenz durch Tagging und Budget-Reporting
I/O & Ressourcen
- Anwendungsanforderungen und SLOs
- Datenklassifikation und rechtliche Vorgaben
- Budgetrahmen und vorhandene Infrastruktur
- Empfohlenes Deployment-Modell
- Konsequenzen für Betrieb und Sicherheit
- Migrations- und Integrationsplan
Beschreibung
Das Cloud-Deployment-Modell beschreibt Muster zur Bereitstellung von IT-Ressourcen in Public, Private, Hybrid oder Community Clouds sowie SaaS/PaaS/IaaS-Varianten. Es hilft Architekturentscheidungen zu treffen, Governance, Betrieb und Compliance-Anforderungen zuzuordnen. Entscheidungskriterien sind Kosten, Sicherheit, Kontrolle, Skalierbarkeit und betriebliche Fähigkeiten.
✔Vorteile
- Ermöglicht gezielte Abwägungen zwischen Flexibilität und Kontrolle
- Unterstützt Compliance durch bewusste Datenlokation und Isolationsprinzipien
- Verbessert Kostentransparenz durch Zuordnung zu Service-Modellen
✖Limitationen
- Kein Allheilmittel: jedes Modell bringt spezifische Restriktionen mit
- Hybrid-Lösungen erhöhen oft Komplexität und Integrationsaufwand
- Vendor-spezifische Dienste können Portabilität einschränken
Trade-offs
Metriken
- Gesamtkosten (TCO)
Messung aller direkten und indirekten Kosten über Lebenszyklus
- Verfügbarkeit / Uptime
Prozentuale Zeit, in der die Dienstleistung verfügbar ist
- Mean Time to Recovery (MTTR)
Mittlere Zeit zur Wiederherstellung nach Ausfall
Beispiele & Implementierungen
Globales SaaS-Startup
Produkt lief initial komplett in Public Cloud; später Einführung von regionalen privaten Tenants für Rechtssicherheit.
Finanzinstitut mit Private Cloud
Kritische Kernbank-Systeme in Private Cloud, weniger kritische Dienste als SaaS betrieben.
Hybrid-Architektur einer Universität
Forschung und sensible Daten on‑premise, Lehrplattformen in Public Cloud für Skalierung.
Implementierungsschritte
Anforderungsaufnahme und Datenklassifikation durchführen
Deployment-Optionen evaluieren und Trade-offs dokumentieren
Pilotprojekt in ausgewähltem Modell durchführen
Betriebskonzepte, SLAs und Notfallpläne implementieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Monolithische Anwendungen ohne Cloud-Native-Design
- Manuelle Provisionierung und fehlende IaC-Artefakte
- Unzureichende Observability und Alerting-Konfiguration
Bekannte Engpässe
Beispiele für Missbrauch
- Sensible personenbezogene Daten in Public Cloud ohne Verschlüsselung speichern
- Private Cloud bauen, aber keine Betriebsprozesse definieren
- Hybrid-Integration ohne klare Netzwerktrennung und Authentifizierung
Typische Fallen
- Unterschätzung des Integrationsaufwands zwischen Clouds
- Nichtberücksichtigung versteckter laufender Kosten
- Fehlende SLA‑Abstimmung zwischen Provider und Kunde
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Regulatorische Anforderungen an Datenlokation
- • Vorhandene Legacy-Systeme mit begrenzter Portabilität
- • Budget- und Personalrestriktionen für Eigenbetrieb