Cloud Service Model
Modell zur Klassifizierung von Cloud-Diensten (IaaS, PaaS, SaaS) und ihrer Verantwortungs-, Betriebs- und Integrationsgrenzen.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Vendor Lock-in bei unsystematischer Nutzung von Plattform-APIs
- Fehlende SLA-Abgrenzung führt zu Betriebsrisiken
- Unscharfe Sicherheitsverantwortung zwischen Anbieter und Nutzer
- Verantwortlichkeiten in einem RACI-Modell klar dokumentieren.
- FinOps-Metriken etablieren, um Kosten laufend zu überwachen.
- Standardisierte Integrations- und Auth-Patterns verwenden.
I/O & Ressourcen
- Technische Anforderungen (Latenz, Durchsatz, SLA)
- Compliance- und Sicherheitsanforderungen
- Kosten- und Budgetrahmen
- Gewähltes Service-Modell mit Verantwortlichkeitsmatrix
- Architekturprinzipien und Migrationsplan
- SLA- und Betriebsvereinbarungen
Beschreibung
Das Cloud-Service-Modell klassifiziert Bereitstellungsarten wie IaaS, PaaS und SaaS sowie deren Verantwortungs- und Betriebsgrenzen. Es hilft Entscheidungsträgern, Abstraktionsgrad, Kontrolle und Betriebskosten von Diensten zu bewerten. Relevante Aspekte sind Multi-Tenancy, SLA-Verantwortung und Integration mit On-Premises-Systemen. Die Wahl des Modells beeinflusst Architektur, Compliance, Kostenmodellierung und Betriebsorganisation.
✔Vorteile
- Schnellere Bereitstellung durch Abstracted Services
- Kostentransparenz und flexiblere Skalierung je nach Modell
- Fokus der Teams auf Kernfunktionen statt Infrastrukturbetrieb
✖Limitationen
- Reduzierte Kontrolle über Unterbau bei höheren Abstraktionsstufen
- Mögliche Abhängigkeit von Anbieterfeatures und APIs
- Nicht alle legacy-Systeme eignen sich für direkte SaaS- oder PaaS-Migration
Trade-offs
Metriken
- Total Cost of Ownership (TCO)
Gesamtkosten über Laufzeit inklusive Betrieb, Lizenzen und Migration.
- Mean Time to Recovery (MTTR)
Durchschnittliche Zeit zur Wiederherstellung nach einem Ausfall unter dem gewählten Modell.
- Anteil wiederverwendeter Komponenten
Maß für Portabilität und Modularität über Anbietergrenzen hinweg.
Beispiele & Implementierungen
E-Commerce nutzt SaaS für CRM
CRM-Funktionen wurden als SaaS integriert, um Time-to-Market zu verkürzen; Integration über API-Gateways realisiert.
Analytics-Plattform auf PaaS
Plattformdienste (Datenbank, Batch-Runtime) wurden als PaaS genutzt, um Entwicklerfokus zu erhöhen.
Start-up betreibt Infrastruktur in IaaS
Jumpstart durch IaaS-VMs und Netzinfrastruktur; später schrittweise Migration auf PaaS-Komponenten geplant.
Implementierungsschritte
Anforderungen aufnehmen und Stakeholder-Kriterien definieren.
Service-Modelle (IaaS/PaaS/SaaS) gegen Kriterien evaluieren.
Proof-of-Concept für favorisiertes Modell durchführen.
Migrations- und Betriebsplan erstellen, SLAs verhandeln.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Direkte Abhängigkeit von proprietären Plattform-APIs ohne Abstraktion
- Unvollständige Dokumentation der Verantwortungs- und Betriebsaufgaben
- Legacy-Komponenten, die die vollständige Nutzung von PaaS verhindern
Bekannte Engpässe
Beispiele für Missbrauch
- Kritische Compliance-Daten in SaaS speichern ohne vertragliche Garantien
- PaaS als billige IaaS-Alternative nutzen und dafür wertvolle Plattformfunktionen ignorieren
- IaaS-Infrastruktur ohne Automatisierung manuell betreiben
Typische Fallen
- Unterschätzung von Integrationsaufwand zwischen Cloud und On-Prem
- Fehlende Beobachtbarkeit bei gemischten Service-Modellen
- Übersehene wiederkehrende Kosten durch Zusatzfeatures des Anbieters
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Regulatorische Vorgaben zu Datenhaltung
- • Vorhandene Legacy-Systeme und Integrationen
- • Budgetrestriktionen für Betrieb und Migration