Die Anfangszeit oder „Prä-Cloud Hosting“
Alles begann Anfang der 90er Jahre mit der Entwicklung des Internets. Spätestens 1993 war der kommerzielle Durchbruch geschafft, was größtenteils mit der Veröffentlichung des Webbrowsers „Mosaik“ einherging, der die Inhalte des WWW erstmals grafisch darstellen konnte. Ab sofort war eine Präsenz im Web für das eigene Geschäft in der beginnenden digitalen Welt ein Muss. Nach und nach wurde das Angebot an Webdiensten und Onlineshops zahlreicher und immer vielfältiger. Das Hosting dieser Dienste passierte jedoch auf den eigenen Maschinen, die je nach Größe und nötiger Verfügbarkeit der Dienste entweder unter dem Tisch des Entwicklers im Büro standen oder im klimatisierten Keller als kleine Rechnerfarm lebten. Wartung, Instandhaltung, Deployment, Backupstrategie und Ausfallschutz – all das lag im Aufgabenbereich der Administratoren. Die Risiken und auch die Kosten waren nicht unerheblich, da nebst den Materialkosten auch erweiterte Personalkosten für z. B. Bereitschaftsdienst aufgewendet werden mussten (Abb. 1).
IaaS oder „Der Startschuss in die Cloud“
Die Schmerzen, die durch das Hosting der eigenen Dienste verursacht wurden, waren rund um das Jahr 2000 endgültig verstanden und erhört worden. Nach und nach kamen Anbieter auf den Markt, die sich um die eigenen infrastrukturellen Herausforderungen kümmern wollten und somit das Hosting übernahmen. IaaS war geboren. Nun war es möglich, Hardware für die eigenen Dienste zu mieten, um so die physische Wartung und Instandhaltung der Maschinen vom Betreiber erledigen zu lassen. Man musste also „nur“ noch die Maschinen entsprechend aufsetzen und konfigurieren, wofür erstmals Virtualisierungsmechanismen zum Einsatz kamen – dann die eigentlichen Dienste bzw. Services installieren und verfügbar machen – fertig! Es war also nach wie vor komplexe Arbeit nötig, aber der Aufwand auf Maschinenebene fiel gänzlich weg.
Das war also der erste Schritt in die neue Welt. In den folgenden Jahren wurde IaaS breit angenommen und das Angebot stetig erweitert. Auch die Virtualisierungen waren erwachsen geworden und wurden industriell wie kommerziell als Standardwerkzeug eingesetzt. So war der Nährboden für den nächsten (R)Evolutionsschritt bereitet.
PaaS oder „Software as a Baukasten“
Was IaaS mit der Hardwareebene anstellte und somit Administratoren das Leben einfacher machte, wollte PaaS auf Softwareebene für die Entwickler tun. Und das mit enormem Erfolg.
Die Plattform bietet vorkonfigurierte Dienste mit definiertem Funktionsumfang an, die miteinander verknüpfbar sind und sich auch in bestehende Systemlandschaften integrieren lassen. Benötigt eine Anwendung beispielsweise zur Persistierung (objekt)relationaler Daten eine Datenbank, bietet die Plattform einen Baustein in einer Grundkonfiguration, der sofort zur Verfügung steht. Bei Bedarf kann die Konfiguration natürlich noch justiert werden.
So stehen in dieser Form Bausteine für die verschiedensten Anforderungen zur Verfügung (Application Services, Storage, Event Queues, API Gateways, Media Services, Machine-Learning-Instanzen und zahllose mehr), die im Zusammenspiel eine Softwarelösung bereitstellen oder als einzelnes Feature in einer Anwendung zum Einsatz kommen.
Aber Vorsicht! Mit diesen neuen Möglichkeiten der Anwendungsentwicklung verändern sich auch die darunterliegenden Mechanismen. Neue Softwareentwicklungsmuster entstehen und alte werden in Rente geschickt. Konnte man mit IaaS noch ein „Lift & Shift“ (Die Migration von Applikationen, bei der man die bisherige Ausprägung ohne Anpassungen direkt in der Cloud-Plattform abbildet) von Anwendungen in die Cloud betreiben, steht man bei PaaS oft vor einer Neustrukturierung der Anwendungslogik, um das Potenzial der Plattform auch nutzen zu können.
Nun muss man sich also nicht mehr um Hardware kümmern, dank der Mühen von IaaS. Und PaaS macht es möglich, die Dienste klug und nach Bedarf zu kombinieren, um damit die gewünschte Anwendung zu formen bzw. bestehende zu erweitern. Sind wir nun bereits am Ende der Komfortskala angekommen, was die moderne und Cloud-basierte Anwendungsentwicklung angeht? Man mag es erahnen: noch lange nicht!
Neue Softwareentwicklungsmuster entstehen und alte werden in Rente geschickt.
FaaS oder „Kleinvieh macht auch Mist“
Seit etwa Mitte des Jahres 2014 ist eine neue Begrifflichkeit auf den Plan getreten und verspricht – vor allem den Entwicklern unter uns – den nächsten Entwicklungsschritt in der Cloud. Funktionen sollen als flexibler Klebstoff die PaaS-Welt dynamisch nutzbar gestalten.
Was ist an diesen Funktionen nun so neuartig ? Nutzt doch jeder Entwickler Funktionen in der Programmiersprache seiner Wahl täglich, um Businesslogik in Code zu gießen. Die Funktionen, um die es sich hier handelt, sind allerdings andere.
Sie sind Kleinstdienste, haben klar abgetrennte Aufgabenbereiche und arbeiten autonom und statuslos. Man kann sie wiederum auf schlaue Weise zusammenschließen und erhält am Ende eine lose gekoppelte Anwendungslogik, die auch in bzw. an Bestandssysteme ein- oder angehängt werden kann.
Vielleicht drängt sich nun unweigerlich der Gedanke „Microservices!“ auf, womit man keineswegs falsch liegt. Funktionen kann man als „Single-Purpose Services“ oder auch gerne als „Nanoservices“ beschreiben.
Nur Vorsicht vor Vermischung von Begrifflichkeiten. Die Architektur einer mit Funktionen realisierten Anwendung kann dem Microservices-Pattern folgen, aber die Idee geht darüber hinaus. Microservices beschreiben einen bestimmten Bauplan für eine Anwendung, wohingegen sich die Funktionen als das neue, mächtige – aber sehr kleinteilige – Werkzeug für den eigentlichen Bau verstehen.
Funktionen sollen als flexibler Klebstoff die PaaS-Welt dynamisch nutzbar gestalten.
Die Stärke der Funktionen liegt allerdings nicht in ihrem Formfaktor, sondern in dem Versprechen, dass die Betreiber der anbietenden Cloud-Plattform geben. Und hier kommt auch der Name ins Spiel, unter dem FaaS eher bekannt geworden ist: „Serverless Computing“ oder kurz „Serverless“.
Serverless oder „Weg mit den Maschinen“
Die Idee von Serverless Computing ist es, Dienste anzubieten, ohne einen einzigen Gedanken an Maschinen, Container, Betriebssysteme, Softwareversionen oder Skalierung der Instanzen – horizontal wie vertikal – zu verschwenden. Das ist natürlich etwas überspitzt formuliert, dennoch soll der „Serverless“-Weg genau zu diesem Ziel führen.
Und das ist auch das Versprechen der Plattformbetreiber: „100 % managed and operated“. Serverless Computing bietet also die Umgebung, um sich nahezu ausschließlich auf die Implementierung von Businesslogik konzentrieren zu können. Dabei muss diese in sinnvolle kleine und autonome Teile zerlegt werden. Jeder Teil wird als eine separate Funktion zur Verfügung gestellt, ausgeführt und skaliert.
Die Vorteile von „Serverless Computing“ wie Wartbarkeit, Skalierbarkeit und kurze Deploymentzyklen liegen auf der Hand und können auf diese Weise bereits auf Funktionsebene optimiert werden, was bislang nur auf Applikationsebene möglich war.
Aus großer Kraft folgt …
… große Verantwortung. Deshalb ein leises „Aber“ bzw. eine Ermahnung zur Vorsicht!
So verlockend es auch ist, Anwendungslogik frei nach dem Vorsatz „Separation of Concerns“ in kleinste Teile zu zerlegen, muss man stets mit Bedacht vorgehen und jedes Szenario für sich beleuchten. Denn sowohl die einst gefeierten Monolithen als auch die neuerdings gehuldigten Microservices haben uns beide noch nicht den heiligen Gral der glorreichen Systemarchitektur gebracht. Somit gilt auch hier der berühmte, immer richtige Satz der IT: „Es kommt drauf an“.
Spannende und Informative Sessions zum Thema finden Sie im Microservices & APIs Track der BASTA!
Manuela Rink auf der BASTA! Spring 2018
● Serverless Backends: Diät ohne Jojo-Effekt – mit Functions