Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Function as a Service

323 views

Published on

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)

Published in: Data & Analytics
  • Überprüfen Sie die Quelle ⇒ www.WritersHilfe.com ⇐ . Diese Seite hat mir geholfen, eine Diplomarbeit zu schreiben.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Function as a Service

  1. 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.

×