Nach der Einleitung ins Thema Cloud Computing beim letzten Mal geht
es heute um die zentralen "Buzzwords" XaaS, Serverless und Edge
Computing in der einhundertneunzehnten Episode des
Anwendungsentwickler-Podcasts. TL;DR Bei Infrastructure as a
Service (IaaS) miete ich Infrastruktur, auf der ich meine Anwendung
betreibe; Platform as a Service (PaaS) stellt zusätzlich die
passende Laufzeitumgebung bereit. Mit Software as a Service (SaaS)
arbeitest du direkt mit fertiger Software, während Function as a
Service (FaaS) einzelne selbst entwickelte Funktionen ausführt und
nach Aufrufen abrechnet. Die Dienste übernehmen technische Aufgaben
und binden dich an das Angebot ihres Anbieters. Container machen
Laufzeitumgebungen kompakt und automatisierbar; Edge Computing
verarbeitet große Mengen an Sensordaten nahe an den Geräten, bevor
Ergebnisse in die Cloud gelangen. Kapitelmarken [00:00:00] Einstieg
und Rückblick auf virtuelle Maschinen [00:00:59] XaaS und
Infrastructure as a Service [00:02:44] Amazon EC2 und flexible
Rechenleistung [00:04:32] IaaS: Ressourcen anpassen und
Hardwarebetrieb abgeben [00:05:52] IaaS: Anbieterbindung und
Internetzugang [00:08:09] Betriebssysteme und IaaS-Anbieter
[00:09:11] Platform as a Service und fertige Laufzeitumgebungen
[00:10:49] PaaS: Entwickeln und zusätzliche Instanzen starten
[00:12:12] PaaS: Architektur und Anbieterbindung [00:13:45]
PaaS-Anbieter und Elastic Beanstalk [00:14:14] Container und
modulare Laufzeitumgebungen [00:17:10] Infrastructure as Code und
automatisierte Container [00:18:29] Container: Einstiegshürden und
Docker [00:19:43] Software as a Service und fertige Anwendungen
[00:21:57] SaaS: Kostenmodell und technischer Betrieb [00:22:49]
SaaS: Funktionsumfang und Anbieterbindung [00:23:32] Datenschutz
und Serverstandorte [00:24:48] Function as a Service und Serverless
Computing [00:27:50] Amazon Lambda und Azure Functions [00:28:44]
FaaS: Einzelne Funktionen skalieren und abrechnen [00:31:07] FaaS:
Anbieterbindung und zusätzliche Komplexität [00:33:22] Edge
Computing im Internet der Dinge [00:35:23] Sensordaten für ein
Dashboard vor Ort verarbeiten [00:36:44] Rückblick auf die
Cloud-Modelle [00:38:22] Ausblick auf Plattformwahl und
IHK-Prüfungsaufgaben Inhalt Infrastructure as a Service (IaaS) Um
den Wartungsaufwand für den Endkunden zu reduzieren, kamen
IaaS-Anbieter wie Amazon EC2 oder Microsoft Azure auf die Idee,
komplette VMs inkl. Betriebssystemen anzubieten. Vorteile Sehr
leicht zu skalieren. Wenig/kein Wartungsaufwand. Kann komplett ohne
eigene Hardware in der Cloud betrieben werden. Geringe
Anfangsinvestition. Nachteile Abhängigkeit vom konkreten Anbieter.
Nicht offline nutzbar. Betriebssystem ist ggfs. vorgegeben bzw.
nicht alle Betriebssysteme möglich. Beispiele: Amazon Web Services,
Microsoft Azure Platform as a Service (PaaS) In vielen Fällen
liefert die eigene Konfiguration der Infrastruktur keinen Mehrwert
für den Endkunden oder die Entwickler der Anwendung. Wer einfach
nur die Plattform zur Ausführung seiner Anwendung braucht, und sich
nicht um die Technik darunter kümmern will, der kann sich direkt
die nötige Plattform mieten. Vorteile Sehr einfach skalierbar.
Keinerlei Administration des Betriebssystems nötig. Fokus auf die
Entwicklung der eigentlichen Anwendung möglich. Nachteile Anwendung
muss Architekturkonzept der Plattform unterstützen. Es können nur
die angebotenen Infrastruktur-Dienste verwendet werden. Beispiele:
Microsoft Azure, Amazon Elastic Beanstalk. Container Um die
Konfiguration der Laufzeitumgebung und auch der verschiedenen
Komponenten wie Datenbank, Messaging usw. zu vereinfachen, kann man
Container-Dienste wie Docker nutzen. Vorteile Beschreibung der
Laufzeitumgebung als ausführbare Datei (Infrastructure as Code).
Komplett automatisierbar. Sehr einfach skalierbar. Nachteile
Initial hoher Aufwand. Nicht für alle Anwendungen geeignet.
Beispiele: Docker. Software as a Service (SaaS) Wer auch die
Anwendung selbst nicht mehr entwickeln will, kann sich fertige
Applikationen mieten. Vorteile Einfaches Abrechnungsmodell.
Keinerlei Administration mehr nötig. Fokus auf die Fachlickeit.
Nachteile Kaum Möglichkeiten der individuellen Anpassung. Starke
Bindung an den SaaS-Anbieter. Ggfs. Datenschutz-Probleme.
Beispiele: Google Docs, Office 365, Gmail, Salesforce. Function as
a Service (FaaS, Serverless Computing) Wer seine eigene Anwendung
aus kleinen funktionalen Bausteinen erstellen möchte, die
individuell skalierbar sind, ist mit einem FaaS-Anbieter gut
bedient. Vorteile Sogar einzelne Teile der Anwendung sind
individuell skalierbar. Neue Anwendungsfälle können schnell aus
bestehenden Diensten zusammengebaut werden. Transparente Abrechnung
nach konkreter Nutzung. Nachteile Sehr starke Abhängigkeit vom
FaaS-Anbieter. Evtl. komplizierte Architektur. Beispiele: Amazon
Lambda, Azure Functions. Edge Computing Gerade das aktuell stark
wachsende Internet der Dinge produziert eine enorme Menge an Daten.
Wenn diese komplett in die Cloud transferiert werden müssten, um
dort verarbeitet zu werden, würde es schnell zu Latenzproblemen
kommen. Daher wandert die (Vor-)Verarbeitung dieser Datenströme
zurück ins eigene Netz. Die Daten werden "am Rand" (=Edge) des
Netzwerkes aggregiert und erst danach in die Cloud geladen (z.B.
zur dauerhaften Speicherung oder als Datenbasis für Anwendungen).
Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts
Edge Computing Läutet Fog Computing das Ende der Cloud ein? Amazon
Elastic Beanstalk Tutorial – The ULTIMATE Guide Serverless FaaS
with AWS Lambda and Java Serverlos durch die Nacht: Wie gehen
Funktionen ohne Server? Zusammenfassung Infrastructure as a Service
(IaaS) Bei einem Anbieter wie Amazon miete ich eine virtuelle
Maschine, deren Rechenleistung ich nach Bedarf anpassen kann.
Dieses Modell heißt Infrastructure as a Service. Es gehört zu den
XaaS-Angeboten, bei denen "as a Service" bedeutet, dass ein
Anbieter eine Dienstleistung für dich übernimmt. Du bekommst
Infrastruktur einschließlich Betriebssystem und Netzwerk
bereitgestellt. Darauf installierst du deine Anwendung und die
benötigte Laufzeitumgebung. Der Anbieter kümmert sich um die
zugrunde liegende Hardware und deren ausfallsicheren Betrieb.
Amazon EC2, ausgeschrieben "Elastic Compute Cloud", ist ein
Beispiel: Für eine Instanz erhältst du eine bestimmte CPU-Leistung
und RAM. Wenn deine Anwendung mehr Ressourcen braucht, kannst du
eine größere Instanz bezahlen und später wieder heruntergehen. Weil
der Anbieter die Hardware betreibt, entfällt für dich deren
Wartung. Gerade kleine Unternehmen können mit geringen
Anfangsinvestitionen schnell starten. Welche Instanzen und
Betriebssysteme verfügbar bleiben, bestimmt der Anbieter.
Änderungen am Angebot oder an den Preisen betreffen deinen Betrieb.
Für den Zugriff brauchst du eine Internetverbindung. Wenn
Beschäftigte darüber mit ERP- oder CRM-Software arbeiten, muss die
Anbindung ausreichend schnell und gegebenenfalls redundant sein.
Eine Anwendung lässt sich zwischen gemieteten Windows-VMs
verschiedener Anbieter übertragen. Wie gut ein Angebot passt, hängt
auch davon ab, ob das benötigte Betriebssystem verfügbar ist. Große
Anbieter haben verschiedene Betriebssysteme im Angebot. Zu den
genannten Anbietern gehören Amazon Web Services und Microsoft Azure
sowie Google und IBM. Platform as a Service (PaaS) Für meine
Java-Anwendung kann ich eine fertige Laufzeitumgebung mieten und
dort eine JAR- oder WAR-Datei hochladen. Bei Platform as a Service
stellt der Anbieter die Plattform bereit, etwa mit JVM, .NET
Framework oder Ruby on Rails. Je nach Angebot kommen eine Datenbank
und ein Messaging-System hinzu. Damit übernimmt der Anbieter auch
Aufgaben wie das Einrichten und Patchen der Laufzeitumgebung. Als
Entwickler:in kannst du dich auf deinen Anwendungscode
konzentrieren. Beispiele sind Microsoft Azure und Amazon Elastic
Beanstalk, das etwa eine Umgebung mit Java-EE-Application-Server
bereitstellt. Zusätzliche Instanzen ermöglichen es, mehr Anfragen
zu verarbeiten. Dafür muss deine Anwendung entsprechend aufgebaut
sein: Anfragen sollen auf unterschiedlichen Knoten verarbeitet
werden können. Eine zustandslose Architektur unterstützt das, weil
einzelne Knoten keinen lokal gespeicherten Zustand für spätere
Anfragen voraussetzen. Durch anbieterspezifische Dienste entsteht
eine stärkere Bindung an die Plattform. Wenn deine Anwendung eng
mit deren Datenbanken oder Dateiablagen zusammenarbeitet, wird ein
Wechsel aufwendiger. Container und Infrastructure as Code Meine
Anwendung lässt sich zusammen mit der benötigten Laufzeitumgebung
in einen Container packen. So entsteht eine definierte Umgebung mit
wenig Overhead. Auf einem passenden System mit Containerdienst
kannst du sie übertragen und ausführen. Container lassen sich
modular aufbauen, sodass eine vorhandene Basis mit einer bestimmten
Laufzeitumgebung für weitere Anwendungen dienen kann. Sie brauchen
wenig Speicherplatz und starten sowie stoppen schnell. Als Beispiel
wird Docker genannt. Mit Infrastructure as Code beschreibst du die
Umgebung in einer Textdatei. Darin legst du beispielsweise fest,
welche Softwareversionen installiert werden sollen. Der
Containerdienst baut daraus die passende Umgebung. Diese
Beschreibung kannst du in Git ablegen und gemeinsam mit dem
Anwendungscode versionieren. Weitere Instanzen lassen sich über
Skripte automatisiert erstellen. Zu Beginn brauchst du Zeit, um
dich in Container einzuarbeiten und die Umgebung als Code zu
beschreiben. Ob sich eine konkrete Anwendung dafür eignet, hängt
von ihren Anforderungen ab. Software as a Service (SaaS) Mit
Software as a Service arbeite ich mit einer fertigen Anwendung,
etwa Google Docs, Office 365, Gmail oder Salesforce. Über einen
Zugang im Browser kannst du loslegen. Der Anbieter betreibt die
Software und kümmert sich um technische Aufgaben sowie die
benötigten Ressourcen. ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.