Cloud-Modelle

Böse Zungen behaupten, Cloud bedeute nichts anderes als: Der Computer anderer Leute. So zynisch diese Sichtweise aber auch ist: Sie ist nicht falsch. Cloud bedeutet ganz allgemein, dass meine Anwendung - oder ein Teil meiner Anwendung - nicht in meinem eigenen Rechenzentrum, bzw. auf meinem lokalen Computer läuft. Neben dem geänderten physikalischen Ort der Leistungserbringung bedeutet Cloud aber auch ein geändertes Abrechnungsmodell. Während man bei traditionellen IT Systemen die Server, das Betriebssystem und eventuelle Software Lizenzen kaufen muss, mietet man im Cloud Kontext diese Dinge. In einigen Bereichen wird sogar alleine für die Nutzung von Ressourcen wie Speicherplatz oder Rechenleistung bezahlt - bei sekundengenauer Abrechnung. Cloud ist also nicht nur eine technische Veränderung der IT Landschaft, sondern auch eine buchhalterische!

Cloud kann auf verschiedenen Schichten einer Anwendungsarchitektur stattfinden und wird dann jeweils anders genannt. Die folgende Abbildung zeigt ein solches Schichtenmodell. Dieses Modell ist allerdings nicht das einzig Richtige. Cloud Dienste und Begriffe kommen und gehen im Monatsrhythmus. Ich habe versucht mich, auf die Dinge zu begrenzen, die in den letzten Jahren einigermaßen stabil waren. Wer nach einer umfangreicheren Sichtweise sucht, wird bei der  CNCF Cloud Native Interactive Landscape fündig. Dort listet die  Cloud Native Computing Foundation eine so große Anzahl von Cloud Diensten auf, dass man sich darin verlieren kann.

IaaS

Der Cloudkontext Infrastructure as a Service (IaaS) meint alles von der physikalischen Hardware wie den Servern, den Routern, dem Netzwerk, den Storage Appliances, etc. bis hinauf zur Virtualisierung über einen Hypervisor. Bei IaaS mietet man physikalische oder virtuelle Infrastruktur auf die dann weitere Komponenten einer Anwendung, beginnend mit dem Betriebssystem, aufgesetzt werden können.

Im Vergleich zu den kommenden Schichten ist eine Migration einer bestehenden Anwendung auf eine IaaS mit der Strategie  REHOST (Lift&Shift) relativ einfach. Ein  Vendor Lock-in ist auf dieser Schicht nur selten zu befürchten.

CaaS

Ein vergleichsweise moderner Cloudkontext ist Container Orchestration as a Service (CaaS). Er ist in den letzten Jahren mit zunehmender Bedeutung von ( Docker-)Containern aufgekommen. In diesem Kontext bietet der Cloudanbieter eine fertige Container-Orchestrierung (oft  Kubernetes) an, auf die eine Anwendung aufgesetzt wird.

Betreibt man im eigenen Rechenzentrum bereits containerbasierte Anwendungen, so ist der Weg in die Cloud per  REHOST hier besonders einfach. Auf Basis dieser Schicht kann auch eine Multicloudumgebung aufgesetzt werden, so dass eine Anwendung teilweise im eigenen und im Provider-Rechenzentrum läuft. Weiterhin können mehrere Provider-Clouds auf dieser Schicht verbunden werden um einen Vendor Lock-in bei einem einzigen Provider zu vermeiden.

Hat man eine Anwendung, die nicht auf Containern basiert, dann kann es zwischen wenig und sehr viel Aufwand bedeuten, diese in eine CaaS Cloud zu transformieren. Je nachdem wie nah die Anwendungsarchitektur an einer Containerarchitektur ist, kommt eine der Strategien  REPLATFORM,  REFACTOR oder  REBUILD zum Einsatz.

PaaS

Platform as a Service (PaaS) abstrahiert die existierende Hardware noch weiter als IaaS oder CaaS. Sollte kein CaaS im Stack des Providers sein, so spricht man ab der Betriebssystemebene und allem was darüber kommt von PaaS. Das kann die Laufzeitumgebung für Programmiersprachen oder Frameworks sein, aber auch eine Datenbank oder eine Dateiablage als Dienst.

Die größte Bedeutung und damit auch das größte Differenzierungsmerkmal aktueller Cloudprovider liegt in den Plattformdiensten. Das sind Dienste, die schlüsselfertig angeboten werden. Dabei kann es sich zum Beispiel um Identity Management as a Service handeln, Infrastrukturdienste wie Deploy Chains oder DNS, oder auch KI-Dienste wie Spracherkennung oder Bilderkennung. Je mehr man seine Anwendung auf diese Plattformdienste aufbaut, desto weniger flexibel ist man bei der Wahl seines Cloud-Providers und desto schwerer fällt ein Wechsel des Providers. Die Gefahr des Vendor Lock-in ist in dieser Schicht besonders groß!

Je nach Anwendung kommt man wieder mit einer der Strategien  REPLATFORM,  REFACTOR oder  REBUILD zum Ziel einer Transformation auf die Cloud.

FaaS

Function as a Service (FaaS) kam im Zuge von Serverless Architekturen auf. Es bedeutet keineswegs, dass in diesem Kontext keine Server mehr existieren - es bedeutet nur, dass man als Anwendungsentwickler keine mehr zu Gesicht bekommt. Die Funktionen einer Anwendung werden bei diesem Modell einzeln in eine FaaS Umgebung deployed und skalieren dort unabhängig voneinander. Da es in einem on-premise Kontext nur sehr wenige Anwendungen gibt, die auf einer Serverless Architektur aufbauen, muss für eine Cloud Transformation meistens die Strategie  REBUILD - also ein kompletter Neubau der Anwendung - angewandt werden.

Die verschiedenen FaaS-Plattformen wie Amazon Lambda, Azure Functions oder Google Cloud Functions sind auch nur begrenzt zueinander kompatibel. So dass eine Übertragung einer Anwendung zu einem anderen Cloudanbieter auf dieser Ebene schwierig ist.

SaaS

Im Kontext Software as a Service (SaaS) muss man sich als IT Verantwortlicher die wenigsten Sorgen machen, weil die vollständige Anwendung allein in der Cloud läuft. Der einzige Nachteil ist, dass auch alle Daten, die zur Anwendung gehören in der Cloud liegen. Ob das gewünscht oder möglich ist, muss im Einzelfall geklärt werden. Man kauft an dieser Stelle eine schlüsselfertige Anwendung, muss sich nur noch anmelden und los geht’s.

Eine Transformation einer bestehenden Anwendung in eine SaaS ist kaum möglich. Man kann lediglich eine on-premise-Anwendung durch eine SaaS Anwendung ersetzen (=  REPLACE) und dann die zugehörigen Daten ebenfalls in die SaaS-Anwendung übertragen. Ein Beispiel könnte eine lokal laufende  Confluence-Installation sein, die in Zukunft direkt aus der Atlassian-Cloud genutzt werden soll. Bei Anwendungen, die weniger standardisiert sind als ein Wiki, muss man meist die Geschäftsprozesse oder Arbeitsabläufe im Unternehmen anpassen, damit die Anwendung produktiv nutzbar wird.