Platform as a Service

von Christoph Huber

Ich möchte in mehreren Artikeln das Thema Platform as a Service (PaaS) angehen. Dieser erste Beitrag behandelt die Frage, was eine PaaS ist, und welche Vorteile sie welchen Organisationen bringen kann. Ich habe mich länger mit Cloud Foundry, eines der am weitesten verbreiteten PaaS, beschäftigt. Ich habe Schulungen für Entwickler zu dem Thema gegeben, aber auch geholfen, Cloud Foundry bei einem Kunden als on-premise Installation einzuführen. Diese persönlichen Erfahrungen möchte ich in diesem Blogpost einfliessen lassen.

Vielleicht haben Sie schon die bekannteren Begriffe Infrastructure as a Service (IaaS) oder Software as a Service (SaaS) gehört. Inwiefern unterscheidet sich eine PaaS von diesen Technologien? Neben den Vorteilen von PaaS möchte ich auch abgrenzen, was durch eine PaaS nicht gelöst werden kann. Dieser Artikel dient als Vorbereitung auf den in Kürze erscheinenden Beitrag, welcher sich mit verschiedenen Lösungen am Markt und deren Evaluierung beschäftigt.

Virtualisierung zwecks Automatisierung

Um den Nutzen von PaaS besser zu verstehen, hilft es, auf die Zeit vor der Cloud zurückzublicken. Damals wurde Software auf physischen Maschinen betrieben. Bevor neue Software betrieben werden konnte, musste zuerst Hardware angeschafft werden, dann das benötigte Betriebssystem und andere Abhängigkeiten installiert werden. Erst nach diesen aufwendigen und manuellen Prozessen konnte die Software in Betrieb genommen werden. Nun besteht ein System, wie zum Beispiel ein Websystem, immer aus mehreren Softwarekomponenten, so dass dieser Aufwand mehrfach anfiel – nicht nur beim Installieren, auch bei Änderungen an der Software.

Physischer Server
Eine Installation einer Webapplikation benötigt eine Vielzahl von funktionierenden Schichten.

Mit der Entwicklung eines Unternehmens wächst auch ihre Infrastruktur. Die Kosten für den Betrieb der angeschafften Hardware wachsen stark und das Management der manuellen Betriebsprozesse ist irgendeinmal nicht mehr möglich. Eine erste Entlastung dafür wurde durch die Virtualisierung von Maschinen geschaffen. Damit war es möglich, ein Rechenzentrum mit homogener und somit einfach wartbarer Hardware zu verwalten. Die oben beschriebenen Prozesse, wie die Installation eines Betriebssystems passieren nicht mehr manuell auf der Hardware, sondern in sogenannten virtuellen Maschinen (VMs). Der Lifecycle einer Maschine ist deshalb virtuell und damit komplett automatisierbar.

Auch mit virtuellen Maschinen muss noch ein eigenes Rechenzentrum betrieben werden. Die hohen Kosten für geeignete Räumlichkeiten und die notwendige Wartung der Hardware durch Menschen, sind insbesondere für kleine Organisationen, aber auch kleinere KMUs schwierig zu finanzieren. Zudem nimmt die Anzahl der von Organisationen benötigten Informationssysteme zu, so dass der Bedarf an Maschinen ständig steigt, man denke nur an Microservices. Es ist heute nicht ungewöhnlich für eine Organisation, mehrere tausend Maschinen zu betreiben. Möchte man diese nun auf eigener Hardware betreiben, so fallen zum einen regelmässig hohe Investitionen in Blech, und zum anderen Personalkosten an.

Amazon hat dies beispielsweise schon vor einigen Jahren erkannt und einen Service eingeführt, über welchen sich virtuelle Maschinen in ihrem Rechenzentrum automatisch erstellen lassen. Dieses Angebot an virtueller Infrastruktur nennt sich Infrastructure as a Service (IaaS) und ist die Basis von PaaS.

Container: Docker und Co.

Der nächste Schritt der Virtualisierung waren Container. Im Gegensatz zu virtuellen Maschinen brauchen Container kein eigenes Betriebssystem. Somit können mehrere Container auf einer virtuellen Maschine laufen, was Ressourcen spart und Automatisierung effizienter und flexibler macht. Container können mit Hilfe einer Software Stack Konfiguration automatisiert und in kurzer Zeit erstellt werden. Ist einmal eine Konfiguration geschrieben, können damit beliebig viele Container hochgefahren werden, was dem Betrieb erlaubt, eine Applikation schnell zu skalieren. Damit ist diese Technologie der Grundstein für Qualitäten wie Verfügbarkeit und Performance.

Für die Verwaltung von Containern gibt es Werkzeuge wie Kubernetes. Diese werden auch Containers as a Service (CaaS) genannt und bieten bereits einen wichtigen Teil davon, was auch von einer PaaS angeboten wird. Die Services, die CaaS anbietet, sind folgende:

  • Verwaltung von Software Stack Konfigurationen
  • Ausrollen von Instanzen (Container) auf Grund dieser Konfigurationen
  • Skalieren von Applikationen
  • Loadbalancing zwischen mehreren Instanzen einer Applikation
  • Serviceabstraktion mit vereinfachter Anbindung an den Service (Service Discovery)

Der Hauptfokus von CaaS liegt auf der Verwaltung von den Containern. Mit diesen lässt sich der ganze Software Stack einer Webanwendung automatisieren, indem die Entwicklung die Konfiguration ihrer Container pflegt und dem Service übergibt. In diesen Konfigurationen lassen sich auch gewünschte Services angeben, welche von der Applikation verwendet werden. Bei einem Zugriff auf einen solchen Service, zum Beispiel eine Datenbank, übernimmt das CaaS das Routing und Loadbalancing zu einer Instanz dieses Services.

Die Plattform

PaaS vs. IaaS&SaaS
PaaS baut auf CaaS und IaaS auf.

PaaS setzt auf Infrastructure und Container as a Service auf und bietet zusätzliche Funktionen speziell für Webapplikationen an. Das Ziel einer PaaS ist es, dass Entwickler ihren Programmcode direkt an die Plattform schicken können, welche alles automatisiert, was ursprünglich vom Betrieb übernommen wurde. Der Betrieb hingegen muss sich nur noch um die Plattform kümmern, die Betreuung der Applikationen selber ist nicht mehr nötig. Natürlich sind Anfragen wie “Warum läuft diese Applikation so langsam?” immer noch möglich, worauf der Betrieb dann die Applikationsinstanzen genauer anschauen muss. Falls die Plattform aber stabil ist, und somit andere Applikationen normale Werte aufweisen, kann das Problem meiner Erfahrung nach besser von der Entwicklung analysiert werden, da es wahrscheinlich im Code selber oder an eingesetzten Schnittstellen liegt.

Mit PaaS ist die Auslieferung von Software per Mausklick möglich. Dasselbe gilt für das Skalieren von Applikationen. Steht ein System unter unerwartet hoher Last, wäre ein Ausfall, und damit verpasster Umsatz oder ein Reputationsschaden, ohne automatische Skalierung wahrscheinlich. Mit PaaS hingegen kann der Applikation auf der Plattform sofort oder sogar automatisch mehr Ressourcen zur Verfügung gestellt werden, so dass die Last besser verteilt werden kann. Je nach PaaS gibt es Services, welche die CPU und Memory Auslastung von Applikationsinstanzen überwachen. Überschreiten diese einen definierten Schwellwert, wird automatisch eine neue Instanz gestartet.

Ein weiterer Effekt, der durch PaaS erreicht werden kann, ist eine deutliche Verringerung der Time-to-Market. Das liegt vor allem daran, dass Webapplikationen viel schneller und ohne manuelle Prozesse live geschaltet werden können. Auch sind schnelle Updates ohne Aufwand möglich (Continuous Delivery) – und dies, ohne dass eine Applikation auch nur kurz offline wäre. Ohne PaaS ist Continuous Delivery auch möglich, dies ist aber oft aufwendig und fehleranfällig, da man alle Funktionen, die eine PaaS bietet, selber umsetzen muss. Ich habe vor allem gesehen, dass in diesem Fall aufwendige Deployment Skripte gebaut werden, welche in einem Continuous Integration Server ausgeführt werden. Und dies meist mit manuell angelegten virtuellen Maschinen. Zudem müssen Schnittstellen wie Loadbalancing, Monitoring oder Backupsysteme zusätzlich angepasst werden. Ein solches Vorgehen ist unflexibel und kostet viel. In diesem Fall macht zumindest ein leichtgewichtiges Containers as a Service Sinn.

Die meisten PaaS unterstützen unzählige Betriebssysteme, Programmiersprachen, Laufzeitumgebungen und Webserver. Zudem bieten sie Abstraktionen für Services an. Ein Beispiel für einen solchen Service ist eine Datenbank. Den Entwicklern wird es leicht gemacht, zum Testen ihrer Software eine Datenbankinstanz zu erstellen. Der Applikation werden alle nötigen Konfigurationen zur Verfügung gestellt, so dass sich diese automatisch mit dem Service verbinden kann, sobald eine Instanz erstellt wurde. Dass diese Angebote in PaaS “Services” genannt werden, ist etwas verwirrlich, da PaaS selber ja auch ein Service ist, bzw. eine Vielzahl von Services anbietet. Auch gibt es eine Serviceabstraktion bereits in CaaS. Dort muss diese aber selber definiert werden, während eine PaaS typischerweise einen dedizierten Service per API zur Verfügung stellen kann.

Das verwalten von sämtlichen Systemkomponenten in einer Plattform führt zu einer Homogenisierung, die nicht nur die Effizienz, sondern auch die Sicherheit steigern kann. Früher war es oft so, dass Sicherheitsupdates in Betriebssystemen, Laufzeitumgebungen oder Webservern einzeln eingespielt wurden mussten. Systemkomponenten alter Applikationen wurden dabei meist vergessen, so dass Webapplikationen über längere Zeit mit grossen und bekannten Sicherheitslücken weiter liefen. Mit PaaS sind auch Updates des ganzen Stacks schnell möglich, so dass garantiert alle Applikationen davon betroffen sind.

Vergleich von Services
Die einzelnen Schichten von Cloud Services bestimmen, welche Schichten einer Webapplikation von der Plattform verwaltet werden. Bei PaaS ist das fast alles ausser der Applikation mit der Geschäftslogik.

Was PaaS nicht kann

Eine PaaS eignet sich zur Optimierung der Entwicklung von Webapplikationen. Software von einem externen Anbieter lässt sich auch darauf betreiben. Sollte der Anbieter die Software als Service direkt anbieten (Software as a Service – SaaS), könnte dies aber mehr Sinn machen. Der Anbieter kann seine Plattform auf diese bestimmte Software besser abstimmen und das Benutzen von solchen Services ist meist günstig, auch weil es keinen Initialaufwand bedeutet.

Auch laufen nicht alle Applikationen auf der PaaS. Eine Applikation muss hierfür das Qualitätsmodell einer “Cloud-native App” vorweisen können. Beispielsweise muss der Storage State in einem Service ausserhalb der Applikation gespeichert werden. Ansonsten führt das horizontale Skalieren der Applikation zu Inkonsistenzen, da jede Instanz einen unterschiedlichen Zustand aufweist. Dies ist in der Regel kein Problem für Neuentwicklungen, aber bestehende Services müssen vor ihrem Umzug auf eine PaaS individuell geprüft werden.

Meine Erfahrung hat gezeigt, dass PaaS klassische Probleme von Webapplikationen löst. Zustandsbehaftete Services sind aber weniger flexibel als Cloud-native Apps. So ist es einfach, Apps automatisch skalieren zu lassen. Bei Services ist dies aber nicht immer möglich, da diese Fähigkeit sowohl von der Service Implementation selber, wie auch vom eingesetzten Produkt abhängt. PaaS garantiert also Skalierbarkeit von Services nicht. Es ist jedem Service Provider selber überlassen, wie er seine Services anbietet.

Organisation und PaaS

Die Einführung von PaaS kommt oft nicht ohne Organisationstransformation aus. Alte Prozesse und Regeln passen nicht mit PaaS zusammen. Die Abbildung unten zeigt ein Beispiel von Prozessschritten, die nötig sind, um eine Webapplikation installieren zu können, wobei Betriebsthemen wie Logging, Monitoring oder Backups noch nicht enthalten sind. Dabei ist es in der klassischen IT nicht selten, dass jeder Schritt von einem anderen Team abgearbeitet werden muss. Da PaaS nun alle diese Schritte obsolet macht, braucht es die Akzeptanz aller involvierten Teams, dies auch möglich zu machen. Gibt es im Team, welches Zertifikate beschafft, eine Regel, dass keine Wildcard Zertifikate zur Verfügung gestellt werden können, funktionieren neue Applikationen nicht, bevor manuell ein neues Zertifikat erstellt wurde. Kann das Firewall Team nicht alle IPs der PaaS freigeben, können die Applikationen gar nicht funktionieren. Diese bisherigen Geschäftspraktiken müssen angepasst werden, bevor PaaS Sinn macht.

Prozess für eine neue Applikation
Prozessschritte bei der Einführung einer neuen Webapplikation.

Auch ist es nötig, dass sich die Laufzeitumgebungen, auf denen die PaaS Applikationen laufen, homogenisieren lassen. Die Vorteile der PaaS gehen verloren, wenn sich Entwickler verschiedener Applikationen nicht auf eine Java Version einigen können oder ein Entwicklungsteam mit einer relationalen Datenbank arbeiten will, für die es keinen PaaS Service gibt. Differenzen sollten so weit wie möglich vor der Einführung von PaaS beigelegt werden, damit die Standard Software Stacks festgelegt werden können.

Fazit

Platform as a Service steigert Time-to-Market, Qualitäten von Webapplikationen und ermöglicht automatisierte Test- und Go-Live Prozesse. Mit PaaS lassen sich die Betriebskosten auch viel besser kontrollieren. Bei einem externen Anbieter wird meist nach einfachen Kriterien wie Kosten pro Applikationsinstanz abgerechnet. Bei on-premise Installationen kostet einfach die Plattform, egal was darauf läuft. Beides ist viel transparenter als bei heterogenen Systemlandschaften, in denen kaum ersichtlich ist, wo jetzt welche Kosten anfallen.

Ein gutes PaaS bietet folgende Services und Features:

  • Installation von Webapplikationen, indem nur der Code eingereicht werden muss – den Rest macht die Plattform.
  • Horizontale und vertikale Skalierung. Ersteres ist die Erhöhung der Anzahl Instanzen einer Applikation. Letzteres ist das Aufbessern der Instanzen, oft indem mehr Speicher gegeben wird.
  • Serviceabstraktion, so dass Datenbanken, Nachrichtensysteme, Suchindexe und unzählige andere Services einfach von einer Applikation konsumiert werden können.
  • Routing, Loadbalancing und Sicherheitskonzept für Webapplikationen.
  • Monitoring von Applikationen. Fällt eine Applikationsinstanz aus, wird automatisch eine neue gestartet.
  • Meist lässt sich eine PaaS auch in Organisationen aufteilen, so dass eine Organisation nur seine eigenen Applikationen verwalten kann.
  • Verwaltung von einer Vielzahl von Software Stacks mit unterschiedlichen Betriebssystemen und Laufzeitumgebungen. Diese Stacks können so aktualisiert werden, dass auch alle Applikationen, die auf dem Stack laufen, die Änderungen übernehmen.

In der Schweiz ist PaaS noch kein Standard. Viele Unternehmen sind heute erst bei IaaS angekommen, während weiter viele Organisationen noch auf Lösungen ohne Virtualisierung setzen. Auf der IaaS Schicht muss der Betrieb und die Entwicklung immer noch selber eigene Automatisierungen entwickeln oder Prozesse manuell abbilden, was eine PaaS besser und standardisiert lösen könnte. Wer noch nicht IaaS hat, profitiert mit der Einführung von PaaS noch mehr, da gleich die ganze IaaS Thematik übersprungen wird. IaaS ist in diesem Fall vom PaaS Anbieter zu betreiben, ein PaaS Benutzer muss sich nicht um diese Abstraktion kümmern.

Kontaktieren Sie uns, falls Sie den Wechsel auf eine PaaS in Betracht ziehen oder Fragen dazu haben. Wir bewerten Ihre Services und helfen Ihnen, die richtige Technologie zu wählen.

Im nächsten Artikel werden die Kriterien diskutiert, nach denen PaaS Lösungen evaluiert werden können. Dann stellen wir die bekanntesten Lösungen vor und vergleichen diese.

Eine Antwort auf „Platform as a Service“

Kommentar verfassen