Platform-as-a-Service (PaaS)
PaaS ist ein Cloud-Service-Modell, das verwaltete Laufzeit, Middleware und Plattformwerkzeuge bereitstellt, damit Entwickler Anwendungen ohne Infrastrukturmanagement erstellen und betreiben können.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Lock‑in und Migrationserfordernisse bei Anbieterwechsel.
- Sicherheitsverantwortlichkeiten müssen klar zugewiesen werden.
- Kosten können bei unerwarteter Skalierung steigen.
- Konfigurationsdrift vermeiden durch deklarative Deployments.
- Portabilität durch Standard-APIs und Abstraktionsschichten maximieren.
- Rollen und Verantwortlichkeiten für Sicherheit und Betrieb klar regeln.
I/O & Ressourcen
- Codebasis und Artefakte
- Konfigurations- und Geheimnisverwaltung
- Monitoring- und Logging-Integrationen
- Bereitgestellte, überwachte Anwendung
- Skalierungs- und Betriebsmetriken
- Service-Backups und Wiederherstellungspläne
Beschreibung
Platform-as-a-Service (PaaS) ist ein Cloud-Service-Modell, das Entwicklern eine verwaltete Laufzeit, Middleware und Plattformwerkzeuge bereitstellt, um Anwendungen ohne Infrastrukturmanagement zu bauen und zu betreiben. Es vereinfacht Deployment, Skalierung und Continuous Delivery, ist aber abstrahierend und bringt Anbieterabhängigkeit sowie zusätzliche Betriebsanforderungen mit.
✔Vorteile
- Schnellerer Time‑to‑Market durch reduzierte Betriebsaufgaben.
- Standardisierte Laufzeitumgebungen und Services.
- Skalierung und Hochverfügbarkeit werden vereinfacht.
✖Limitationen
- Eingeschränkte Kontrolle über Infrastruktur und Netzwerktopologie.
- Mögliche Anbieterabhängigkeit durch proprietäre Dienste.
- Beschränkte Anpassbarkeit von zugrunde liegenden Plattformkomponenten.
Trade-offs
Metriken
- Time to Deploy
Zeit von Commit bis zur produktiven Verfügbarkeit einer Version.
- Uptime/SLA‑Erfüllung
Prozentuale Verfügbarkeit der bereitgestellten Dienste innerhalb definierter SLAs.
- Kosten pro Transaktion
Betriebskosten relativiert an Nutzungsmetriken wie Requests oder Transaktionen.
Beispiele & Implementierungen
Cloud Foundry als Open‑Source‑PaaS
Cloud Foundry bietet Laufzeitmanagement, Buildpacks und Service-Integrationen für polyglotte Anwendungen.
Heroku für schnelle Entwickler-Workflows
Heroku abstrahiert Infrastruktur vollständig und ermöglicht Deployment per Git-Push mit integriertem Add-on-Ökosystem.
Google App Engine als managed PaaS
App Engine bietet skalierende Laufzeiten, automatische Skalierung und integrierte Dienste in der Google Cloud.
Implementierungsschritte
Ziele und Anforderungen definieren, passende PaaS-Kandidaten evaluieren.
Proof-of-Concept aufsetzen, grundlegende Services integrieren und testen.
Produktivsetzung mit Monitoring, Backup-Strategie und Exit-Plan.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Verwendung proprietärer Add‑ons ohne Portabilitätsstrategie.
- Fehlende Automatisierung beim Infrastruktur-Export für Migrationen.
- Nicht dokumentierte Betriebsroutinen, die bei Anbieterwechsel Probleme bereiten.
Bekannte Engpässe
Beispiele für Missbrauch
- Monolith ohne Refaktorierung direkt in PaaS deployen und dann performanceprobleme ignorieren.
- Sensible Daten in ungeeignete Managed-Services speichern ohne Compliance‑Prüfung.
- Optimierung nur für kurzfristige Kostenreduktion, langfristige Betriebskosten vernachlässigen.
Typische Fallen
- Anbieter versteckte Kosten für Add‑ons übersehen.
- Sicherheitsverantwortung fälschlich vollständig an Provider delegieren.
- Unklare SLA-Interpretation bei multi-region Deployments.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Einhaltung der Provider-SLA und Betriebszeiten
- • Kompatibilität von Legacy-Komponenten
- • Regulatorische Anforderungen an Datenhaltung