Servicemodelle in der Cloud

the next big thing Golo Roden  –  12 Kommentare

Der Begriff "Cloud" ist längst in die Alltagssprache eingezogen, doch die wenigsten können im Detail erklären, was genau damit gemeint ist. Tatsächlich gibt es eine Definition des NIST, die vier Servicemodelle beschreibt. Welche sind das?

Das US-amerikanische National Institute of Standards and Technology (NIST) hat eine Definition geschaffen, was unter "Cloud" zu verstehen ist. Darin sind unter anderem vier Servicemodelle beschrieben, die sich unter dem Begriff XaaS zusammenfassen lassen, was üblicherweise als Anything as a Service gelesen wird.

Das erste dieser Servicemodelle ist Infrastructure as a Service (IaaS). Es beschreibt das Geschäftsmodell, Infrastruktur zu vermieten, statt sie zu verkaufen. Für viele Unternehmen rechnet sich der Betrieb eigener Hardware in einem eigenen Rechenzentrum nämlich nicht, da das teuer und aufwendig ist und dafür in der Regel ein eigenes Team benötigt wird.

Anders als beim Webhosting in den 90er-Jahren geht es bei IaaS aber nicht mehr darum, Hardware physisch zu buchen, denn auch das ist langsam, aufwendig, umständlich und schlecht skalierbar. Stattdessen werden Server als virtuelle Maschinen angeboten und um andere virtualisierte Ressourcen ergänzt, beispielsweise virtuelle Netzwerke. Die gesamte Infrastruktur wird also softwaredefiniert bereitgestellt.

Weil das softwaredefiniert erfolgt, lässt sich Infrastruktur auch automatisiert und "on demand" per API aufsetzen. Die Abrechnung erfolgt dabei als Pay-per-Use-Modell, auf lange Vertragslaufzeiten wird verzichtet.

Bekannt ist dieses Modell unter anderem von Amazon, die mit AWS (Amazon Web Services) einen Dienst anbieten, über den sich Ressourcen aus den Rechenzentren von Amazon buchen lassen. Aber auch andere Anbieter bedienen diesen Markt, beispielsweise Digital Ocean, Microsoft Azure oder die Google Cloud Platform.

Insgesamt lässt sich sagen, dass IaaS damit die Grundlage für die Cloud darstellt, die sich nun aber in verschiedenen Schritten nach und nach abstrahieren lässt.

Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)

Auch wenn sich IaaS nicht mehr mit physischer Hardware befasst, ist das Servicemodell immer noch weit weg von der Anwendungsentwicklung. In der Entwicklung will man sich nicht zwingend mit Servern, Storage, Load-Balancing & Co. beschäftigen, sondern eher auf der Ebene des Betriebssystems und einer Laufzeitumgebung wie Node.js oder .NET Core arbeiten.

Genau das adressiert Platform as a Service (PaaS), was letzten Endes eine fertige Softwareumgebung zur Verfügung stellt, auf deren Basis man Anwendungen entwickeln und vor allem ausführen kann. Die Idee dabei ist, sich nicht mehr um die zugrunde liegende Hardware und das Deployment kümmern zu müssen. Auch das Einspielen von Updates für das Betriebssystem oder die Laufzeitumgebung entfällt. Um all diese Aspekte kümmert sich der PaaS-Anbieter.

Dadurch lässt sich der Fokus auf die eigentliche Anwendungsentwicklung legen, die Bereitstellung erfolgt anschließend automatisiert und transparent. Man legt nur noch fest, auf welcher Plattform die eigene Anwendung laufen soll, muss sich aber nicht mehr um das "wie" der Bereitstellung kümmern. Auch Aspekte wie Storage oder Netzwerk sind abstrahiert und können über APIs angesprochen werden.

Häufig werden darüber hinaus ergänzende Dienste wie Datenbanken oder Message Queues, die für die Anwendungsentwicklung unerlässlich sind, als Service bereitgestellt. Auch PaaS-Angebote lassen sich über APIs ansteuern, und auch hier erfolgt die Abrechnung On-Demand und als Pay-per-Use.

Einer der bekanntesten Anbieter in diesem Bereich ist Heroku, es gibt aber wie bei IaaS auch noch zahlreiche weitere Anbieter. Da PaaS auf IaaS basiert, sind häufig die Anbieter von IaaS auch im PaaS-Markt aktiv, beispielsweise Amazon mit AWS Elastic Beanstalk. Damit Anwendungen mit PaaS zusammenpassen, müssen sie allerdings einige Aspekte erfüllen, beispielsweise sollten die Regeln der 12 Factor Apps berücksichtigt werden.

Platform as a Service (PaaS)

Software as a Service (SaaS)

Das dritte Servicemodell, Software as a Service (SaaS), beschreibt schließlich die Bereitstellung vollständiger Anwendungen über die Cloud. Als UI wird häufig der Webbrowser genutzt, in nahezu jedem Fall gibt es auch bei SaaS wiederum APIs, über die sich die Anwendungen anbinden und integrieren lassen. Typische Beispiele für Cloud-Software sind unter anderem Office 365, Slack, Dropbox oder auch GitHub.

Analog zu IaaS und PaaS wird auch bei SaaS die Vermietung als Geschäftsmodell angestrebt: Software wird also nicht mehr gekauft, sondern im Abonnement erworben, wobei in aller Regel pro Anwenderin beziehungsweise pro Anwender monatlich abgerechnet wird.

Das bietet eine ganze Reihe von Vorteilen, beispielsweise Einfachheit und Flexibilität. Aufwendige und fehleranfällige Vorgänge wie Installation, Konfiguration, das Einspielen von Updates und Sicherheitspatches, oder die Skalierbarkeit entfallen, beziehungsweise werden vollständig in die Hände des Anbieters gelegt. Das ermöglicht es, sich stärker auf das eigene Kerngeschäft zu konzentrieren.

SaaS hat aber auch Nachteile, allen voran die Abhängigkeit von einem Anbieter (Vendor-Lock-In) und die in aller Regel geringe Anpassbarkeit der Software an die eigenen Bedürfnisse. Um den Vendor-Lock-In zu vermeiden, sind die Verwendung offener Standards und offener Formate essenziell wichtig. Außerdem ist bei SaaS mehr noch als bei IaaS und PaaS der Datenschutz zu beachten, es gilt also, sich mit Themen wie der DSGVO besonders gründlich auseinanderzusetzen.

Software as a Service (SaaS)

Function as a Service (FaaS)

Bei Function as a Service (FaaS) wird nochmals eine Abstraktionsschicht eingezogen. Die Infrastruktur, das Betriebssystem, die Laufzeitumgebung und sogar die eigentliche Anwendung sind bereits gegeben – es gilt, nur noch die Geschäftslogik zu ergänzen, quasi als eine Art "Plug-in". Das erfolgt in Form von einzelnen Funktionen, die in einen fertigen Anwendungsrahmen eingebunden werden, beispielsweise als Route in einen vorgefertigten Webserver.

Als Entwicklerin oder Entwickler muss man sich dann nur noch mit dem Schreiben ebendieser Route beziehungsweise der Funktion befassen, alles andere wird vom Cloud-Anbieter bereitgestellt und kann über APIs angesprochen werden. Da diese Funktionen üblicherweise zustandslos sind, lassen sie sich leicht skalieren.

Außerdem können sie sehr kostengünstig betrieben werden, da kein dedizierter Server vorgehalten werden muss: Die Funktion wird nach Aufrufen abgerechnet. Finden keine Aufrufe statt, fallen auch keine Kosten an. Das macht FaaS für viele Szenarien zu einer günstigen Alternative, zudem lassen sich die Funktionen auf Grund ihrer einfachen Struktur auch leicht warten und aktualisieren.

Weil man mit dem eigentlichen Server in diesem Fall nicht mehr in Berührung kommt, hat sich für FaaS auch der Begriff Serverless eingebürgert, was aber letzten Endes falsch ist, da dieser Begriff impliziert, dass es keinen Server mehr gäbe – dem ist aber selbstverständlich nicht so.

Verwendet wird FaaS häufig, um Anwendungen miteinander zu verbinden, oder als einfaches Backend für Single-Page-Anwendungen (SPA). Bekannte Angebote hierfür sind beispielsweise AWS Lambda von Amazon und Azure Functions von Microsoft. Der größte Nachteil ist auch hier wieder der Vendor-Lock-In, was nochmals die Relevanz von offenen Formaten und offenen Standards unterstreicht.

Function as a Service (FaaS)

X as a Service (XaaS)

Selbstverständlich ist über diese vier vom NIST definierten Servicemodelle noch mehr möglich. Dementsprechend haben sich zahlreiche Angebote entwickelt, die sich nicht klar einer der vier zuvor genannten Varianten zuordnen lassen. Dabei handelt es sich häufig um Aspekte, die orthogonal zur eigentlichen Anwendungsentwicklung stehen und somit Cross-Cutting-Concerns darstellen, beispielsweise das Bereitstellen von Datenbanken (DBaaS) oder Message-Queues (MQaaS).

Doch neben produktbezogenen Angeboten gibt es auch servicebasierte Angebote, die einen bestimmten Funktionsbereich übernehmen, zum Beispiel Identity as a Service, Logging as a Service oder Content as a Service. Die Grenze zu SaaS ist dabei allerdings fließend. Eine Hilfe zur Einordnung könnte sein, dass sich diese Angebote eher an Entwicklerinnen und Entwickler richten, wohingegen "echtes" SaaS eher auf nicht in der Entwicklung tätige Anwenderinnen und Anwender abzielt.

Eine wichtige Kategorie in diesen übrigen Angeboten ist Backend as a Service (BaaS), die sich zwischen PaaS und SaaS bewegt. BaaS bietet mehr als nur die reine Plattform, ist also größer als PaaS, es handelt sich aber um keine vollständige Anwendung, ist daher also weniger als SaaS. Das Ziel ist, die Fachlichkeit einer Anwendung als API bereitzustellen, weshalb man gelegentlich auch dem Begriff API as a Service begegnet. Im Vergleich zu FaaS adressiert BaaS komplexere Geschäftslogik und umfangreiche Prozesse, die aufwändiger sind als nur einzelne Funktionen.

Mit wolkenkit entwickelt the native web, das Unternehmen des Autors, ein Framework, das unter anderem auch als Open Source zur Verfügung gestellt wird, dessen Ziel die Entwicklung skalierbarer und verteilter Web- und Cloud-Dienste ist. Der Fokus liegt dabei auf der Implementierung der fachlichen Prozesse und Abläufe, der technische Unterbau wird von wolkenkit zur Verfügung gestellt. Das Framework ist auf den Betrieb in der Cloud vorbereitet, lässt sich aber auch lokal betreiben, beispielsweise auf der Basis von Docker und Kubernetes.

X as a Service (XaaS)

Fazit

Die Cloud hat die Art, wie Software entwickelt und vor allem bereitgestellt wird, in den vergangenen zehn Jahren gravierend verändert. Trotzdem hat sie die lokale Ausführung von Software nicht überflüssig gemacht. Es ist daher kein "entweder oder", sondern vielmehr ein "sowohl als auch". Es ist also ratsam, die Cloud als Erweiterung des bisherigen Werkzeugkastens zu sehen und nicht als Ersatz.

Dabei ist allerdings zu beachten, dass – wie mehrfach betont – offene Formate und offene Standards essenziell sind, um einen Vendor-Lock-In zu vermeiden. Nur wer unabhängig vom jeweiligen Cloud-Anbieter denkt und Lösungen entwickelt, die unabhängig von einem konkreten Angebot funktionieren, behält sich langfristig die Möglichkeit bei, zwischen verschiedenen Anbietern wechseln zu können.