Es gibt eine Vielzahl von Blickwinkel, mit denen Cloud-Services betrachtet werden können – sei es anhand des Preismodells, der Skalierungsmöglichkeiten oder anderer Kriterien. Für mich ist vor allem der Blick auf die Flughöhe interessant. Ich unterscheide grob zwischen Low-Level- und High-Level-Service.
Flughöhe von Cloud-Services
Ein Low-Level-Service setzt viel technisches Wissen voraus, bewegt sich nah an Hardware oder benötigt eine Menge händischer Konfiguration. Diese Services bieten eine große Flexibilität, die Verwendung kann jedoch durchaus komplex sein. Oft dienen sie als grundlegende Bausteine, aus denen sich alles Weitere in der Cloud zusammensetzt.
Ein High-Level-Service stellt das Gegenteil dar. Der Nutzer wird von Hardware und anderen technischen Details abgeschirmt. Mögliche Einstellungen begrenzen sich auf das nötige Minimum und werden pauschal voreingestellt. Der Anwendungszweck des Service ist deutlich fokussierter und dementsprechend auch weniger flexibel als bei Low-Level-Services. Die Verwendung hingegen ist deutlich vereinfacht. Zwar sind Low-Level- und High-Level-Services keine feststehenden Begriffe, dennoch hilft die gedankliche Einteilung bei der Bewertung von Cloud-Services. Wann ein Service als low level oder high level gelten könnte, zeigt sich bei der Betrachtung von Services bei Amazon Web Services (AWS). EC2 als Service zur Bereitstellung von virtuellen Maschinen ist wohl ein naheliegender Kandidat für einen Low-Level-Service.
Der Nutzer muss sich sowohl über die Ausstattung der Maschine (CPU, RAM usw.) als auch über das Betriebssystem Gedanken machen. Wichtige Details, die jedoch für das Ziel, eine laufende Anwendung produktiv bereitzustellen, durchaus nachrangig sein könnten. Um dieses Ziel zu erreichen, bedarf es noch weiterer Schritte (oder gar anderer Services). EC2 stellt also eher einen Baustein als eine fertige Lösung dar.
AWS Lambda (Serverless Functions) hingegen ermöglicht es, mit deutlich weniger Konfiguration eine Anwendung produktiv bereitzustellen – ohne dabei allzu sehr über Betriebssysteme, Skalierung oder Ähnliches nachdenken zu müssen. Die Flughöhe ist im Vergleich zu EC2 deutlich höher. AWS Lambda ist also eher als High-Level-Service zu betrachten.
Aber auch ein Vergleich von RDS (SQL-Datenbank) mit DynamoDB (serverless NoSQL-Datenbank) zeigt, dass selbst Services wie RDS, die ihrerseits bereits eine Abstraktion darstellen, vergleichsweise low level sein können. Zwar wird dem Nutzer eine Menge Arbeit beim Betrieb einer SQL-Datenbank abgenommen, aber technische Details wie RAM, CPU oder die Anzahl der Maschinen spielen immer noch eine Rolle. In DynamoDB hingegen erfolgt die Konfiguration auf deutlich höherem Level – wie etwa der erwarteten Anzahl von Lese-/Schreib-Anfragen; ob und welche Maschinen im Hintergrund zum Einsatz kommen, kann dem Nutzer gänzlich egal sein.
Die Bedeutung für die Cloud-Strategie
Gerade bei der Migration von Bestandssoftware in die Cloud kommen Low-Level-Services eine besondere Rolle zu. Der erste Schritt ist nicht selten ein Lift & Shift. Die bestehende Anwendung wird ohne Anpassungen für die Cloud quasi Maschine für Maschine migriert. Um möglichst die Infrastruktur des eigenen Rechenzentrums nachzuempfinden, kommen Low-Level-Services zur Bereitstellung von virtuellen Maschinen oder zur Erstellung des (virtuellen) Netzwerks zum Einsatz. High-Level-Services wie etwa Serverless Functions spielen in diesem ersten – relativ mechanischen Schritt – der Migration noch keine Rolle.
Viele Cloud-Anbieter unterscheiden sich bei Low-Level-Services auf den ersten Blick kaum. So bietet fast jeder Anbieter einen Service zur Bereitstellung virtueller Maschinen. Für Lift & Shift ist die Wahl des Anbieters also nahezu unerheblich. Da dies idealerweise nur den ersten Schritt der Cloud-Strategie darstellt, lohnt frühzeitig ein Blick auf die High-Level-Services der verschiedenen Anbieter. Cloud-Anbieter wie die Hetzner Cloud bieten zwar preiswerte Low-Level-Services an, steht im Rahmen der Cloud-Strategie jedoch später die Migration auf High-Level-Services an, handelt es sich wohl eher um die falsche Wahl.
Bei Green-Field-Projekten hingegen rücken die High-Level-Services deutlich früher in den Fokus. Der in Bestandsprojekten so übliche technische Ballast spielt hier keine Rolle. Stattdessen kann frei auf Serverless-Angebote, NoSQL-Datenbanken und ähnliche High-Level-Services gesetzt werden. Da die Architektur der Anwendung noch sehr formbar ist, kann sie auf genau diese Services abgestimmt werden. Bei neuen Projekten ist der Wille, den oft hohen Preis (durchaus wörtlich) dieser Services zu zahlen, deutlich größer. Insbesondere dann, wenn dadurch Vorteile wie eine schnellere Time to Market, bessere Skalierung oder Ähnliches erkauft werden. Etwaige Kompromisse etwa in der Architektur werden daher durchaus hingenommen.
Einen behäbigen Monolithen hingegen mal eben auf AWS Lambda und DynamoDB (NoSQL) zu migrieren, stellt eine Mammutaufgabe dar. Diese lässt sich, anders als bei der Neuentwicklung, nur punktuell und schrittweise bewältigen und kommt nahezu immer mit größeren architekturellen Veränderungen daher. Ob sich dieser Aufwand (mit dem zugehörigen Risiko) lohnt, bedarf häufig einer genaueren Analyse.
Kontrollverlust im High-Level
Zu wissen, dass Software nicht auf eigenen Maschinen läuft, führt bei vielen zu dem Gefühl des Kontrollverlustes. Dieses zu überwinden, gelingt zum Glück den meisten angesichts der möglichen Vorteile der Cloud. Aber zu wissen, dass ein Service verwendet wird, der von einem selbst so gar nicht im eigenen Rechenzentrum betrieben werden könnte, stellt für viele – mich eingeschlossen! – durchaus eine Überwindung dar. Der Softwareentwickler in mir hat den Drang, die Dinge bis ins Detail verstehen oder sogar kontrollieren zu können. Das ist aber gerade bei vielen High-Level-Services – häufig bewusst – gar nicht möglich. Um von diesen Services profitieren zu können, muss also ein gewisser Kontrollverlust in Kauf genommen werden.
Ein hoher Grad an Abstraktion kann auch schnell dazu führen, dass eine Art Vendor-Lock-in entsteht. Dabei muss das nicht notwendigerweise bedeuten, dass eine Migration von AWS zur Google Cloud erschwert wird, sondern auch die Migration zurück zum eigenen Rechenzentrum. Es kommt insofern zum Kontrollverlust, dass die eigene Software nur noch mithilfe von Services Dritter funktioniert.
Bei Low-Level-Services wie etwa EC2 (VMs in der Cloud) ist die Gefahr recht klein, da eine ähnliche Virtualisierung in eigenen Rechenzentren möglich ist; hier droht nur der Verlust der vermeintlich endlosen Skalierung. Setzt die Anwendung jedoch auf High-Level-Services wie etwa AWS Step Functions (quasi eine Serverless Workflow Engine), ist die Migration zurück zu eigenen Maschinen deutlich schwieriger und bedeutet einen größeren Umbau – oft mit großem Einfluss auf die Architektur.
Aus Sicht des Betriebs sehen die zahlreichen High-Level-Services natürlich attraktiv aus, viele der üblichen Aufgaben entfallen – gerade solche, die im Zweifel Spezialwissen benötigen. So kann etwa das ganze Thema Netzwerk bei der Verwendung von AWS Lambda zu großen Teilen ignoriert werden, auch um die automatische Skalierung anhand von Metriken (wie CPU oder Speicherverbrauch) kümmert sich AWS. Wenn die Dinge jedoch nicht so funktionieren, wie erwartet, fehlt oft der Handlungsspielraum. Im Zweifel bleibt nichts anderes übrig, als mit dem unerwünschten Verhalten zu leben (meist mithilfe von Workarounds) – nicht selten ohne bitteren Beigeschmack.
High-Level-Services als Differenzierungsmerkmal
Ein Vergleich der zahlreichen Cloud-Provider zeigt, dass diese sich bei den Low-Level-Services kaum voneinander unterscheiden – mal von unterschiedlichen Preisen, nutzerfreundlicher API und besonderer Hardware abgesehen. So richtig abheben voneinander können sich Cloud-Anbieter erst mit High-Level-Services. Ein einzelner Service kann durchaus darüber entscheiden, ob sich ein Cloud-Anbieter gegenüber dem Konkurrenten durchsetzt. So war AWS im Bereich Serverless sicherlich die erste Wahl, als AWS Lambda das Licht der Welt erblickte. Inzwischen ist Serverless Computing häufig Teil des Standardangebots eines Cloud-Anbieters. Dennoch bieten sich immer noch zahlreiche Wege, wie Anbieter sich im Bereich der High-Level-Services voneinander abgrenzen können – häufig durch eine weitere Vereinfachung der Benutzung und des Betriebs.
Nicht nur können sich Cloud-Anbieter durch diese High-Level-Services besser voneinander abgrenzen, gleichzeitig erschweren sie so ihren Kunden eine Migration zum Konkurrenten (oder wie bereits gesagt: ins eigene Rechenzentrum). Für den Anbieter erhöht dies natürlich die Kundenbindung – wenn auch nicht zugunsten des Kunden.
Neue High-Level-Services müssen aber in der Praxis nicht immer von Erfolg gekrönt sein. So hat AWS mit Elastic Container Service (ECS) eine vereinfachte Alternative zu Kubernetes im Angebot, konnte jedoch aufgrund gesteigerter Akzeptanz des offenen Kubernetes nicht mithalten und gestand sich mit Elastic Kubernetes Service (EKS) gewissermaßen eine Niederlage ein. Managed Kubernetes als solches lässt sich im Vergleich tatsächlich eher als Low-Level-Service verstehen – mal von möglichen Add-ons der Cloud-Anbieter angesehen.
Dennoch zeigt sich, dass auch kleinere Cloud-Anbieter sich in jüngster Zeit deutlich mehr auf High-Level-Services konzentrieren, um so mit den anderen Anbietern mitzuhalten. Der durchaus bekannte Cloud-Anbieter Digital Ocean etwa fügte jüngst ein Serverless-Angebot hinzu. Andere Anbieter belegen bewusst spezielle Nischen, um auch mit den großen Anbietern mithalten zu können, gute Beispiele sind hier etwa Fly.io oder früher auch Heruko. Die Simplizität eines einzelnen Service kann so hoch sein, dass selbst die Fülle an Funktionalität großer Cloud-Anbieter nebensächlich wirkt – zumindest dann, wenn der Service eben genau das Problem des Kunden löst.
Wo geht die Reise hin?
Low-Level-Services der Cloud-Anbieter werden in der Zukunft sicher nicht komplett entfallen. In vielen Fällen bilden sie immer noch die notwendige Basis für viele Anwendungen. Nicht alles lässt sich mal etwa eben so im Serverless-Paradigma abbilden – auch wenn das gerne so dargestellt wird. Dennoch scheinen sich insbesondere High-Level-Services mit einem hohen Abstraktionsgrad einer großen Beliebtheit erfreuen. Als jemand, der Kunden im Bereich Cloud berät und unterstützt, muss ich selbst natürlich auch zur Kenntnis nehmen, dass es heutzutage schwer ist, jemandem – gerade bei Neuentwicklungen – zur direkten Verwendung von Low-Level-Services wie EC2 und Co. zu raten. Selbst für Kubernetes muss es gute Gründe geben (im klassischen Enterprise-Umfeld zum Glück durchaus häufig der Fall).
Aber es kann regelrecht absurd wirken, wie viele Schritte bei vielen Cloud-Anbietern notwendig sind, um tatsächlich mal etwas vorzeigen zu können – zumindest dann, wenn man eher konservativ ist und die klassischen Low-Level-Services setzt. Aus dem Blickwinkel wirkt die Cloud eben nicht „einfach“. Hat eine Kunde einmal gesehen, wie einfach mit AWS AppRunner (o. Ä.) eine Anwendung für den produktiven Einsatz – inklusive Skalierung, Monitoring und Co. – bereitgestellt werden kann, lässt sich dieser nur schwer von aufwendigen, selbst gestrickten Deployment-Pipelines und komplexer Infrastruktur überzeugen; selbst dann, wenn diese abhängig vom Anwendungsfall durchaus ihre Berechtigung hat. Mal eben AWS Zugriff auf ein Git-Repo geben, sodass bei jedem Push die neue Version live geht, beeindruckt hingegen stets aufs Neue. Für viele ist heutzutage genau das eben Cloud – die einfache Nutzung, ohne auf Vorzüge wie Skalierung, einfacher Betrieb und Co. zu verzichten. Eine Folge des ganzen Trends Richtung High-Level-Services ist die zunehmend wachsende Schere zwischen Cloud und eigenem Rechenzentrum. Während die Cloud in der Vergangenheit vieles lediglich vereinfacht hat, werden wir in Zukunft viel öfter auf Services stoßen, deren Nachbildung mit eigenen Maschinen praktisch unmöglich ist. Ob sich ein Unternehmen dann noch erlauben kann, die Frage „Wollen wir in die Cloud?“ zu stellen, ist fraglich. Offen gesagt ein Gedanke, der mir durchaus auch ein wenig Bauchschmerzen bereitet.
