[10]: https://git-scm.com/downloads
# Servicemodelle
[TOC]
## Servicemodelle in der Cloud
Der Begriff **Cloud** ist längst in die Alltagssprache eingezogen, doch die
wenigsten können im Detail erklären, was genau damit gemeint ist.
Das US-amerikanische **National Institute of Standards and Technology** (NIST) hat
eine [**Definition**](https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp) 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.
Die Cloud-Service-Modelle IaaS, PaaS und SaaS einfach erklärt anhand des Pizza-Prinzips"
### Das Pizza-Prinzip
Um die Cloud-Service-Modelle **IaaS**, **PaaS** und **SaaS** besser zu verstehen, hier ein Vergleich mit einem Beispiel aus dem Alltag:
Cloud-Service-Modelle | Pizza as a Servic
:-------------------------:|:-------------------------:
 | 
**IaaS (Infrastructure as a Service):**
IaaS ist wie der Kauf von Zutaten für eine Pizza im Supermarkt und das Backen zu Hause. Sie haben die Kontrolle über die Zubereitung, aber müssen sich um die gesamte Vorbereitung selbst kümmern.
**PaaS (Platform as a Service):**
PaaS entspricht dem Erhalt eines vorgefertigten Teigs und einer Auswahl von Belägen in einem Pizzarestaurant. Sie gestalten Ihre Pizza, ohne sich um die Basis oder Infrastruktur zu kümmern.
**SaaS (Software as a Service):**
SaaS ist wie das Bestellen einer fertigen Pizza bei einem Lieferdienst. Sie nutzen die Anwendung, ohne sich um die Details der Installation oder Wartung kümmern zu müssen.
**Zusammenfassung:**
IaaS, PaaS und SaaS bieten verschiedene Ebenen der Kontrolle, ähnlich der Wahl zwischen selbstgemachter Pizza, individueller Gestaltung oder sofortiger Nutzung.
## Infrastructure as a Service (IaaS)
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.
Youtube
## 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](https://www.youtube.com/watch?v=UBh8Rp2secQ) berücksichtigt werden.
 6:39 Min.
[](https://youtu.be/I7Oyr_SVJEA)
## 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.
## 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.
Youtube
## 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.
## 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
---
> [⇧ **Zurück zu KN00** (KN00)](../README.md)
---
> [⇧ **Zurück zur Hauptseite**](https://gitlab.com/ser-cal/M346)
---