Die Cloud für Entwickler

Cloud-Lösungen im Überblick

Was gibt es eigentlich und wo liegen die Vor- und Nachteile? Eine grobe Übersicht der Anbieter und Möglichkeiten von Christoph Landsky kommentiert.

Über den Wolken...

Wie Reinhard Mey bereits 1974 chantierte, muss "über den Wolken die Freiheit wohl grenzenlos sein". Ist dies wirklich so? Wie gelangt man dorthin? Welche Vor- und Nachteile kann dies mit sich bringen?

Als ich vor etwa einem Jahr anfing, mich intensiv mit dem Thema zu beschäftigen, stand ich sprichwörtlich "wie der Ochs' vor'm Berge". Die Cloud war für mich so etwas wie ein magischer Ort, an dem alle Wünsche wahr werden können. Zumindest aus der Perspektive eines Softwareentwicklers. Damals machte ich mir auch noch keine Gedanken darüber, was das ganze dann einmal kosten würde, wie ich mein Sicherheitskonzept aufbaue, oder wie ich meine Software auch wirklich nachhaltig "in der Wolke" entwickeln kann. Geblendet von der schieren Anzahl an Features machte ich mich also auf, um dieses Mysterium zu ergründen. Doch dabei stieß ich schnell an meine Grenzen. Um alle Aspekte der Cloud zu verstehen, bedarf es mehr als nur eine grobe Ahnung und ein wenig "geklicke" in den bunten Konfigurationsmasken. Um zu verstehen, was ich in der Cloud machen kann und daraus resultierend auch machen will, musste ein wenig Theorie her.

Schaut man sich einmal die Definition der Cloud an, fällt sehr schnell auf, dass der Begriff an sich erstmal sehr schwammig ist. Grob kann man nämlich sagen, dass alle Ressourcen, die man von einem externen Anbieter bezieht und welche über das Internet, zum Beispiel über eine Web-Konfigurationsmaske oder eine API angesprochen werden können, bereits als Cloud gelten. Das schließt das bloße Hosting einer VM bei einem externen Anbieter bereits mit ein. Der Unterschied zu vielen klassischen IT-Dienstleistern liegt eher darin, dass Self-Service in fast allen Fällen eher dem Standard entspricht. Natürlich gibt es auch kleine Unternehmen, die für mich meine Cloud verwalten können, aber dies ändert im Grunde nichts an der Richtigkeit der Aussage. Also was ist denn nun eigentlich die Cloud und was möchte ich dort machen? Hier mal ein paar Beispiele was Cloud bereits ist:

  • Ein Virtual private Server (VPS) bei einem externen Anbieter, welchen ich über eine Webseite verwalten kann
  • Ein Deployment auf einer Entwicklerplattform wie Heroku
  • Das Nutzen eines IdentityProviders, wie etwa den Google Single-SignOn
  • Ein Repository auf GitHub, GitLab oder ähnlichem
  • Ein Online-Storage, in dem ich meine Urlaubsfotos ablege

Auf den allerersten Blick scheinen diese Themen nicht sonderlich viel miteinander zu tun zu haben. Ein paar Dinge, wie zum Beispiel Google Drive, GitHub, die Apple-Cloud etc. nutzen wir ja auch privat und das zuweilen sogar jeden Tag. Dazu kommt, dass ich einen VPS ja auch klassisch bei einem IT-Dienstleister bestellen kann. Also was bringt mir das denn nun alles? Wie kann ich auf eine Anfrage, eine Cloud-App zu entwickeln, reagieren und was muss ich dafür implementieren? Fragen über Fragen.

Am besten distanzieren wir uns an der Stelle einmal vom Begriff Cloud und schauen unter die Haube der einzelnen Services. Bei den gängigen Cloudanbietern werden die Cloud-Ressourcen nämlich in mehrere Segmente unterteilt, wobei der Übergang zwischen ihnen fließend und nicht klar voneinander trennbar sein kann. Das bedeutet, dass wir uns bei Amazon, Google und co. später nicht mehr für "Cloud", sondern detaillierter für einzelne Serviceschichten entscheiden werden.

Infrastructure-as-a-Service (IaaS)

Das erste Beispiel, der VPS, fällt unter die Begrifflichkeit Infrastructure as a Service (IaaS).
Unter IaaS versteht man hauptsächlich die Bereitstellung von physischen Ressourcen (z.b. Hardware, Server, Storage, Memory etc.). Darunter können allerdings auch virtuelle Maschinen, sowie Netzwerk-Infrastrukturen fallen. Im Grunde war dies das Kerngeschäft der meisten Anbieter. IaaS bietet den Vorteil, leistungsstarke Anwendungen zu betreiben, ohne den Aufwand leisten zu müssen, den ein eigenes Rechenzentrum mit sich bringt. Neben der bloßen Verfügbarkeit der Systeme bieten die Cloudanbieter Mechanismen an, um Hochverfügbarkeit, Skalierbarkeit und Sicherheit zu gewährleisten. Allein hierfür würde, bei eigenem Hosting, einiges an Know-How in Form eines geschulten Administratoren benötigt. Diese Aspekte sind per Default bereits in die meisten Cloudlösungen integriert.

Platform-as-a-Service (PaaS)

Das Beispiel Heroku zählt zu einem anderen Segment: Platform as a Service (PaaS).
Unter PaaS versteht man die Nutzung einer Entwicklungsplattform beim Cloudanbieter. Heroku stellt uns für unser Deployment u.a. Java-, Node.js- und Ruby-on-Rails-Plattformen zur Verfügung, welche ohne große Konfigurationsaufwände betrieben werden können. Die benötigten Infrastrukturen und Laufzeiten werden out-of-the-box mit  bereit gestellt. Das initiale Einrichten der Umgebung, wie es bei reinem Blech oder VMs der Fall wäre, fällt somit weg. Auch der Wartungsaufwand verringert sich immens, da die benötigten Abhängigkeiten vom Anbieter gepflegt und gewartet werden. Alles, woran der Entwickler arbeiten muss, ist der eigentliche Source-Code, sowie die benötigten Umgebungsvariablen.

Software-as-a-Service (SaaS)

GitHub, Google Drive, AWS Alexa und eine Online-IDE fallen unter den Begriff Software-as-a-Service (SaaS). Unter SaaS versteht man generell das Verwenden einer Software, welche online von einem Fremdanbieter betrieben wird.Im Grunde kann man sagen, dass alles, was man nicht mehr implementiert, sondern nur noch (online) konfiguriert oder mit Daten füllt (z.B. Google Drive) SaaS ist. Im Falle von Alexa ist der Übergang zwischen den Segmentenfließend, da eigene Module für Alexa implementiert werden können und Alexa in diesem Zusammenhang dann eher als PaaS zu verstehen ist.

Weitere Services

Neben diesen drei Grundkategorien gesellen sich noch ein paar Spezialfälle. So bieten fast alle Cloudanbieter auch Datenbanken-as-a-Service an. Softwaresysteme, welche auf Plattformebene zur Verfügung gestellt werden, werden häufig unter dem Begriff Provided-as-a-Service zusammengefasst.

Neben der blanken Infrastruktur können auch Serveless-Anwendungen verwendet werden. Diese Positionieren sich in etwa zwischen IaaS und PaaS und werden u.a. auch Functions-as-a-Service (FaaS), oder auch Event-Driven-Computing genannt. Mit Serverless ist in diesem Fall gemeint, dass die Erstellung und Verwaltung der benötigten Ressourcen (z.B. Autoscaling) vom Cloudanbieter selbst gemanagt wird. Dabei zahlt der Anwender auch nur genau das, was er auch wirklich verbraucht. Hierfür können sowohl Runtimes, wie z.B. Node.js oder Java, aber auch Docker-Container (Container-as-a-Service oder kurz CaaS) verwendet werden.

Dies soll uns jedoch fürs Erste an Theorie genügen.

Übersicht der einzelnen "Wolken"

Da die Begrifflichkeiten nun geklärt sind, kann ich anfangen, mich mit dem "wo" und dem "was" zu beschäftigen. Dies hängt natürlich stark vom Anwendungsfall ab. Möchte ich ein Docker-Image mit einem Webserver und Datenbank als Backend hosten, eine VM aufsetzen, oder doch lieber nur einzelne Funktionen zur Berechnung implementieren? All das sollte vorher bereits klar sein. Denn abhängig davon kann man sich bei den einzelnen Cloudanbietern informieren, was diese mir bieten können und was das Ganze dann kostet.

Hier erst einmal eine kleine Übersicht, welche Anbieter sich im hart umkämpften Markt der Cloud-Services tummeln.

  • AWS
  • Microsoft Azure
  • Google Cloud Platform
  • IBM Cloud
  • Oracle Cloud
  • Alibaba Cloud
  • Digital Ocean
  • Telekom Cloud / Magenta Cloud
  • Heroku (PaaS)
  • Diverse Managed Hosting Anbieter

Aktuell ist Amazon der Marktführer und hat eine sehr breit aufgestellte Produktpalette. Dazu zählen über 200 Services u.a. in den Bereichen Computing, Network, Data Storage und Machine Learning. Diese können vom Kunden beliebig zusammengesteckt werden. Im Fokus Amazons stehen dabei die sogenannten EC2 Instanzen (VMs) und der S3 Cloud Storage, um welche herum viele der angebotenen Services aufgebaut sind, oder darauf basieren. Ähnliche Konzepte finden sich auch bei den anderen Anbietern wie z.B. Google und Microsoft. Die Services können sich jedoch in Nuancen voneinander unterscheiden. So bietet Microsoft beispielsweise eine enge Verzahnung mit seiner übrigen Produktpalette (z.B. Office und Windows).

Zu den "Big-Playern", also Amazon, Microsoft, Google und co. gesellen sich außerdem zahlreiche kleinere Cloudanbieter wie Heroku, Gitlab, etc. Zwar liefern nicht alle das gesamte Spektrum an Services, aber viele individuelle Probleme lassen sich auch in kleinerem Maßstab lösen. Neben den reinen Produktfeatures bieten die meisten Anbieter eine große Abdeckung an Hosting-Standorten (Regions), um geringe Latenzen und die Einhaltung national geltender Gesetze beim Kunden gewährleisten zu können. Darüber hinaus sind die meisten Regionen durch mehrere Verfügbarkeitszonen (Redundanzen) vor Ausfällen geschützt.

Entwicklung in der Wolke

Nachdem wir nun wissen, wer sich alles da oben in den Wolken tummelt, können wir direkt zur Tat schreiten, oder?

Leider ist dies dann doch nicht so einfach. Um zu verdeutlichen, was ich damit meine, liste ich hier mal ein paar Services auf (Auszüge)

Type AWS Google Cloud Azure
Iaas EC2 Compute Engine Azure Virtual Machine
  VPC Cloud Virtual Network Azure Net
PaaS Elastic
Beanstalk
App Engine Azure Cloud Services
  ApiGateway Apigee API Platform Azure API Management
Caas EKS Kubernetes
Engine
Azure Kubernetes Service (AKS)
  ECS   Azure Container Instances
Functions Lambda Cloud Functions Azure Functions
Databases S3 Cloud Storage Azure Blob Storage
  Aurora Cloud Spanner Azure SQL Database
  RDS Cloud SQL Azure Database for MySQL / PostgressSQL
... ... ... ...

Eine etwas vollständigere Übersicht findet sich hier.

Leute mit einem Fabel für Tabellen und Vergleichsmöglichkeiten werden hier ganz auf ihre Kosten kommen. Ich für meinen Teil fühle mich ein wenig erschlagen. Aber es hilft ja nichts. Ran an den Speck.

Wenn man dann nach intensiver Recherche einmal einen Überblick hat, was genau die Cloud ist, stellt sich natürlich erstmal die Frage: "Was verwende ich denn jetzt davon?". Um das Ganze ein wenig greifbarer zu machen, teile ich es einmal in vier unterschiedliche Herangehensweisen auf. Die Abstufungen der einzelnen Szenarios können im Realfall jedoch beliebig feingranular werden.

Szenario 1: Betreiben einer virtuellen Maschine

Der vermutlich simpelste Fall ist das einfache Betreiben und Managen einer virtuellen Maschine. Diese verhält sich nach der Ersteinrichtung genauso wie ein selbst gehosteter Server und kann mit allen Aufgaben (nach entsprechender Konfiguration) umgehen. Im Regelfall greift man per SSH auf diese Instanzen genauso zu, wie man es von seinen selbst gehosteten Maschinen gewohnt ist. Preislich ist diese Form des Hostings allerdings nicht sonderlich attraktiv. Je nach Performance-Model kann dies sehr schnell ins Geld gehen, da man (im Falle von AWS) stets für die Verfügbarkeit der VM selbst und nicht deren Last bezahlt. Möglich wäre dieses Konzept jedoch.

Vorteile:

  • Volle Kontrolle über die Maschine "wie Zuhause"
  • Performance as ordered
  • Freies Konfigurieren der Laufzeitumgebung
  • Keine verteilten Services

Nachteile:

  • Hoher Verwaltungs- und Managementaufwand
  • Vergleichsweise teuer
  • Benötigt Fachkundiges Personal (Admins)
  • Nicht mehr State-of-the-art

Szenario 2: Betreiben der Anwendung in einem PaaS-Stack

Anstatt seine Laufzeit händisch einzurichten, kann man auch auf bereits vorhandene Laufzeitumgebungen zurückgreifen. Hierfür gibt es auch Alternativen abseits der großen Cloudanbieter. Dazu zählt z.B. Heroku. Der Code kann hier automatisiert aus Github in die Anwendungsumgebung importiert werden und benötigt kein weiteres Management, abgesehen von den Umgebungsvariablen der Software selbst. Oft werden in dem Zusammenhang auch Datenbanken mit angeboten, sodass man diese atomar mit seiner Anwendung verwalten kann. Ein Wehrmutstropfen bleibt. Braucht man eine nicht unterstützte Laufzeitumgebung, kann man dieses Prinzip nicht verwenden. Die Application-Server der finalen Anwendung stehen nämlich bereits fest. Es werden lediglich die Artefakte deployt. Im Fall von Heroku werden jedoch die gängigsten Web-Stacks unterstützt (Node.js, Spring Boot, Ruby on Rails, Django, Play-Framework etc...)

Vorteile:

  • Schnelles Hosting / Deployment
  • Kaum Wartungsaufwand auf technischer Ebene
  • Integrierte Services wie Datenbanken etc.
  • Häufig integrierte Build-Pipelines
  • Entwicklerfreundlich

Nachteile:

  • Abhängigkeit zu unterstützten Technologien
  • Keine benutzerdefinierten Laufzeitumgebungen
  • Enge Bindung an Cloudprovider

Szenario 3: Container

Ein Großteil der Cloudanbieter bieten einen Container-Service an, welcher das Betreiben von Docker-Containern ermöglicht. In den meisten Fällen werden dazu im Hintergrund VM-Instanzen erstellt, welche eine konfigurierte Clustermanagementumgebung besitzen. In diesen Clustern können nun per Konfiguration Container gestartet werden, welche aus den mitgelieferten Container-Registries geladen werden können. Die Steuerung, Konfiguration und Wartung obliegt dabei beim Cloudanbieter selbst und muss nicht selbst vorgenommen werden. Neben dem Cluster-Management über VM-Instanzen bieten einige Cloudanbieter auch Serverless-Lösungen, also dynamisch skalierende Services für die Container an.

Vorteile:

  • Umgebungsunabhängig durch Container
  • Kann Serverless betrieben werden
  • Volle Laufzeitkontrolle bei relativ geringem Konfigurationsaufwand

Nachteile:

  • Benötigt im Idealfall DevOps (Vorkenntnisse von Docker von Vorteil)
  • Abhängigkeit vom Cloudanbieter

Neben dieser Art der Container-Orchestrierung gibt es teilweise auch das Angebot der Orchestrierung über Kubernetes an. Das Container-Management funktioniert ähnlich. Der Unterschied hierbei liegt im Funktionsumfang und dem daraus resultierenden Konfigurationsaufwand. Während der simple Container-Service meist nur das Bereitstellen von Containern mit ein paar Extra-Funktionalitäten zur Verfügung stellt, ermöglichen die Kubernetes-Services das volle Ausschöpfen dieser Technologie. Dafür werden vom Cloudprovider das Clustermanagement und die konfigurierten Nodes gehostet.

Vorteile:

  • Umgebungsunabhängig durch Container
  • Volle Power von Kubernetes auf gehosteter Hardware
  • Provider unabhängige Konfiguration der Architektur

Nachteile:

  • Sehr hoher Konfigurationsaufwand
  • Benötigt DevOps (Kenntnisse Docker + Kubernetes)

Szenario 4: Cloud Native

Wenn man ehrlich ist, ist dies die Paradedisziplin der Cloudprovider. Hier kommt alles zusammen und fügt sich zu einem Bild zusammen. Darüber hinaus hat man hier erst die Möglichkeit, voll aus dem Produktportfolio der Anbieter zu schöpfen. Hierzu zählen:

  • Serverless Anwendungen
  • Functions as a Service
  • Machine Learning und AI Plattformen
  • API Gateways
  • Native Plattformen wie Amazon Alexa

Hier scheiden sich die Geister wohl am ehesten. Zum einen hat man eine enorme Auswahl an vorkonfigurierten Diensten, zum anderen ist man in der Implementierung komplett abhängig vom Anbieter. Eine nachträgliche Migration von einem Anbieter zum anderen ist dann kaum mehr möglich.

Zwar gibt es Tools, die native Konfigurationen abstrahieren können (z.B. Terraform), allerdings gewinnt dann die Konfiguration der zu entwickelnden Anwendung enorm an Komplexität. Hier muss gut abgewogen werden, ob sich der Aufwand lohnt und welche Services ich verwenden möchte.

Da viele der nativen SaaS eine REST-Api bieten, können diese zur Not auch innerhalb der anderen, bereits geschilderten Szenarien verwendet werden. Der Workflow ist dann allerdings ebenfalls etwas komplexer.

Vorteile:

  • Bietet das gesamte Spektrum des Cloudanbieters
  • Weniger Ops-Know-How erforderlich
  • Weniger Softwareimplementierung

Nachteile:

  • Sehr enge Bindung an den Cloudanbieter
  • oder hoher Konfigurationsaufwand (z.B. Terraform, REST-Apis, etc...)
  • Kosten können intransparent sein, da die Abrechnung meist pro Service pro Metrik (z.B. pro Sekunde * CPU-Faktor) geschieht
  • Benötigt Cloudarchitekten

 

Fazit

Nachdem ich mir ein Jahr lang einen groben Überblick verschaffen konnte, muss ich gestehen, dass ich weiterhin mit gemischten Gefühlen dastehe. Welches der oben genannten Szenarien das Beste ist, ist schwer zu sagen und hängt stark vom Anwendungsfall ab. Ein guter Cloudarchitekt kann jedoch solche Architekturen nachhaltig und sinnvoll entwerfen. Man kann aber vermutlich auch vieles falsch machen, denn alle Herangehensweisen haben klare Vor- und Nachteile. Natürlich bieten AWS und co. auch eine Sammlung von Best-Practices, aber inwiefern dies dann auch so umgesetzt werden kann, ist auch wieder abhängig von der gegebenen Komplexität.

Außerdem: Wie viele Abhängigkeiten zum Cloudanbieter man sich ins Projekt holt will gut überlegt sein. Grundsätzlich ist es nicht verkehrt, seine Architektur auf einen Anbieter festzulegen. Alle Cloudsysteme haben immense Vorteile, wie die hohe Anzahl an vorkonfigurierten Services, Scalability und Availability, jedoch sind diese Services auch nicht immer günstiger als alles selbst zu hosten. Sinnvollerweise trifft man solche Entscheidungen am besten anhand konkreter Projekte, da hier die einzelnen Technologien in der Tiefe miteinander verglichen werden können. Fest steht jedoch: Einfach nur mal eben ein kleines Projekt in der Cloud umzusetzen macht wenig Sinn. Die Synergien innerhalb der Cloud sind mit das Hauptverkaufsargument der Cloudanbieter und am Ende das, was das ganze Thema erst so richtig interessant macht. Von daher braucht man das Wissen über die Cloud idealerweise bereits in der Konzeptionsphase, oder eben einen Cloudarchitekten. Learning-by-Doing könnte schnell in einer Sackgasse enden.

Dies alles soll aber niemanden Abschrecken sich von der fabelhaften Welt der Services und Möglichkeiten ein eigenes Bild und darauf aufbauend seine ersten eigenen Lösungskonzepte zu machen. Denn dies macht das ganze Thema erst so unglaublich spannend.

Kommentar

"Ein weiterer Faktor ist die Herausgabe der Daten an externe Dienstleister. Nicht immer ist dies gewünscht. Zwar gelten, für die in Deutschland gehosteten Applikationen auch deutsches Recht, allerdings sind gerade sensible Daten besonders zu schützen. Darüber hinaus ist die Marktmacht der amerikanischen Silicon-Valley-Firmen generell schon ziemlich groß. Gaja, eine europäische Cloud-Lösung, steht zwar in den Startlöchern, muss sich jedoch erst in puncto Features, Performance und Sicherheit gegen die Giganten aus Übersee behaupten. Es bleibt also spannend.."

Jetzt teilen:

Kommentare

Einen Kommentar schreiben

Bitte addieren Sie 2 und 3.

Wir verarbeiten Ihre personenbezogenen Daten, soweit es für die Bereitstellung des Kommentars sowie zur Sicherstellung der Integrität unserer informationstechnischen Systeme erforderlich ist. Sie sind zur Bereitstellung dieser Daten nicht verpflichtet, eine Nutzung der Kommentarfunktion ist ohne die Bereitstellung jedoch nicht möglich. Weitere Hinweise zum Datenschutz finden Sie in der Datenschutzerklärung.