Fachposter, 2018: Erstellt von QAware in Zusammenarbeit mit mit Prof. Dr. Kratzke, Fachhochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM). Bestellbar unter https://www.sigs-datacom.de/order/poster/Cloud-Function-As-A-Service-Poster-2018.php (Dokument bitte herunterladen für bessere Lesbarkeit)

1. Function as a Service
Die Evolution hin zu Serverless-Architekturen Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck
Dr. Josef Adersberger, QAware
Serverless Architektur
Center of Excellence
FaaS – Function-as-a-Service
• FaaS ermöglicht es Backend-Code auszuführen, ohne sich über
Infrastruktur/Dimensionierung Gedanken machen zu müssen.
• FaaS Funktionen können in vielen Sprachen wie JavaScript,
Python, Java, Clojure und Scala entwickelt werden.
• Funktionen werden von Events getriggered (z. B. Dateiänderungen,
Zeitereignisse, Messages, HTTP Requests).
• Eine horizontale Skalierung der Funktionsinstanzen erfolgt
vollautomatisch durch den Provider.
• Funktionen sind zustandslos. Wird ein Zustand benötigt, muss
dies mittels Stateful Services realisiert werden (z. B. Redis).
• Funktionen haben Timeouts. Läuft ein Timeout ab, wird die Funk-
tionsausführung abgebrochen (bei AWS z. B. nach max. 5 Minuten).
• Antwortzeiten hängen von diversen Faktoren ab. Z. B. muss
der Provider bei seltenen Events oder Sudden Spikes weitere
Instanzen starten.
­
Vorteile
Timesharing der Infrastruktur ermöglicht Kostenvorteile
Vereinfachter Betrieb
Automatische Skalierung auf Basis des Request-Aufkommens
Reduzierung von Entwicklungs- und Deployment-Aufwänden
Verbessertes Time-to-Market
Einfaches Unit-Testing
Ggf. sogar „grüneres“ Computing durch bessere
Ressourcenauslastung
­
Nachteile
FaaS Dienste anfällig für Vendor Lock-In
FaaS ist (noch) nicht standardisiert
Sicherheitsbedenken (u.a. keine gut abgrenzbare Server-side
Applikation; dadurch größere Angriffsoberfläche)
Fehlender In-Server-State
Begrenzte und ggf. variierende Ausführungsdauern
Ungeeignet für lang laufende Berechnungen und bei sehr
hohen Echtzeitanforderungen
Aufwändigeres Integration-Testing
Use Cases
FaaS Frameworks
Beispielhafte Einsatzszenarien für Function-as-a-Service:
Event Handler
Eine Funktion reagiert auf ein bestimmtes Ereignis, oft aus einem IoT-Szenario.
Beispiel: Die Funktion wird ausgeführt, wenn ein bestimmter Sprachbefehl von
Amazon Alexa erkannt wird.
Integration Layer
Eine Funktion übersetzt einen API-Aufruf von außen in eine Reihe an Backend-
Aufrufen im Hintergrund. Das ist im Prinzip die Cloud-native Variante eines
ESBs (Enterprise Service Bus).
Beispiel: Die Funktion nimmt einen REST-Aufruf entgegen, holt Daten aus einem
SAP- und DB-System und gibt die Ergebnisse zurück.
Dekomposition bis auf Funktionsebene
Eine Anwendung soll nicht nur bis auf Komponentenebene (Microservices)
sondern bis auf Funktionsebene (Nanoservices) in Laufzeiteinheiten aufgeteilt
werden.
Beispiel: Die Funktion „Warenkorb bestellen“ wird als FaaS-Funktion implemen-
tiert, da sie gut isoliert sein sollte, sehr stark schwankend in ihrer Last ist und
häufig neu deployed wird.
Stream-orientiertes ETL
Eine Funktion transportiert einen Strom an Daten von einer Datenquelle hin zu
einer Datensenke.
Beispiel: Die Funktion wird bei jeder Message in einer Queue aufgerufen und
schreibt diese Message dann in eine Datenbank.
Wo sind all die Server hin?
Typische technische Auswahlkriterien:
• Was sind Serverless Architekturen?
• Serverless Architekturen beziehen sich auf Applikationen,
die Drittanbieter-Dienste einbinden und deren eigener Code als
zustandslose FaaS Funktionen realisiert sind.
• Weniger „Always-On“ Komponenten erforderlich
• Kostenreduktion bis zu 70% im Vergleich zu IaaS.
• Steigende Abhängigkeiten zu FaaS Providern und Drittanbieter-Diensten
• Drittanbieter-Dienste werden auch Backend as a Service (BaaS)
genannt (Beispiel: Auth0 für Authentikationsleistungen).
• Serverless Applikationslogik wird mittels statusloser Funktionen
auf FaaS-Plattformen betrieben (Beispiel: AWS Lambda).
• FaaS Funktionen werden auch als Nanoservices bezeichnet
(in Abgrenzung zu Microservices)
In nicht-virtualisierten Rechenzentren wurden Applikationen
häufig auf Dedicated Servern betrieben. Diese Server waren
für den Workload häufig überdimensioniert.
Aber auch Container fordern einen Anteil der Hostressourcen
(CPU, Memory) kontinuierlich an. Die Ressourceneffizienz
kann also weiter erhöht werden, wenn Containern nur dann
Ressourcen zugeteilt werden, wenn diese auch Requests
bearbeiten. Dieses Timesharing wird durch FaaS runtime
environments realisiert.
Machine-Virtualisierung wird genutzt um Applikationen auf
einem physischen Server zu konsolidieren. Die dafür erfor-
derlichen Deployment Units (Virtual Machine Images) sind
allerdings sehr groß.
Die Auslastung kann mittels Containern (z.B. Docker)
weiter erhöht werden. Container ermöglichen es mehrere
Applikationen als Self-Contained Deployment Units pro
(virtueller) Maschine zu betreiben, solange die Applikationen
dasselbe Betriebssystem teilen. Container starten schneller
als virtuelle Maschinen und Container Images sind kleiner.
Open Source FaaS
Sprachen Welche Programmiersprachen und Frameworks sollen unterstützt werden?
Event-Arten
Auf welche Event-Arten hin kann eine Funktion ausgeführt werden
(z. B. REST-Aufruf oder MQTT Message)
Latenzen
Welche Latenzen entstehen beim Deployment, beim Start und bei Aufruf
einer Funktion?
Services
Welche Services und Schnittstellen (APIs) stehen den Funktionen zur
Verfügung?
Tooling Welche Werkzeuge und Werkzeug-Integrationen stehen zur Verfügung?
Runtimes
Welche Laufzeitumgebungen werden unterstützt (z.B. Kubernetes, DC/OS,
CloudFoundry), welche API-Gateways?
Zustand Kann Zustand über Funktionsaufrufe hinweg gespeichert werden?
Workflows Können einzelne Funktionsaufrufe zu einem Workflow orchestriert werden?
Auto-Skalierung
Können die Knoten, auf denen das FaaS Framework läuft, bei Bedarf
automatisch skaliert werden?
Diagnostizierbarkeit
Welche Möglichkeiten stehen zur Verfügung, um die Ausführung von Funktio-
nen zu Überwachen und Fehler zu finden (auch nach Ende der Ausführung)?
Bare Metal Server
VM
A
VM
B
Bare Metal Server
VM
Container Engine
A
VM
B
Bare Metal ServerBare Metal Server
A B
Bare Metal Server
VM
Container Engine Time-Sharing
FaaS Runtime
A
B
…
…
A
…
VM
41 32
Die Serverless Evolution
Gängige Frameworks:
Native mobile
Applikation
Produkt-Datenbank
Bestell-Datenbank
Authentifizierungs-Service
Dieselbe Applikation als:
API Gateway
Bestell-Funktion
Such-Funktion
1
3
5
2 6
4
Querschnittslogik, wie z.B.
Authentifizierungslogik, kann
an Drittanbieter-Dienste delegiert
werden (z.B. Auth0).
1
Anteile der Applikations-
logik wandern in eine Client-
Applikation (z.B. eine native
Mobile-App oder eine Single-
Page-Web-Applikation).
2
Anwendungslogik kann auch im
Backend in Form einzelner Funktionen
gehalten werden. Insbesondere dann, wenn
diese Logik über mehrere Client-Arten
hinweg genutzt wird, sicherheitskritisch
und berechnungsintensiv ist oder auf große
Datenmengen zugreift (z.B. Such- oder
Klassifikationsfunktionen)
4
Aus Gründen wie z. B. Sicherheit oder um
Drittanbieter-Dienste oder Datenbanken
anzubinden, kann Funktionalität im „Server“
behalten werden (also serverless bereitge-
stellt werden).
5
Ein API Gateway ist ein Web Server der HTTP Requests an zugehörige
FaaS Funktionen oder Drittanbieter-Dienste weiterleitet.
6
Client-Applikationen können auf
Data Stores per API direkt zugreifen.
3
Klassische 3-Tier
Architektur (z. B.
E-Commerce-App)
Client (Browser)
Applikations-Server
Relationale-Datenbank
Für 3-Tier Architek-
turen müssen Clients
nicht sonderlich „intel-
ligent“ sein (es reichen
Browser).
Was ändern Server-
less Architekturen nun
an diesem Setting?
Public Cloud FaaS
• Amazon Lambda
• Azure Functions
• Google Cloud Functions
• Fission (Platform9)
• Fn (Oracle)
• Kubeless (Bitnami)
• OpenFaaS
• OpenWhisk (IBM)
• Riff (Pivotal)
IT-Probleme lösen. Digitale Zukunft gestalten.