Cloud Bursting – Wie man mit Kubernetes die Hybrid Cloud zum Platzen bringt

In den vergangenen sechs Monaten haben wir uns im Rahmen einer Masterarbeit mit dem Thema Hybrid Cloud auseinandergesetzt. Ziel war es, eine Hybrid Cloud mit Kubernetes und Cloud Bursting für eine Beispielanwendung umzusetzen.
Doch was genau bedeutet denn nun Cloud Bursting? Der Begriff stammt aus dem Englischen „to burst“ – zu Deutsch „platzen“. Es geht darum, Anwendungen im privaten Teil einer Hybrid Cloud bei steigender Last durch Public-Cloud-Ressourcen zu erweitern. Die Private Cloud platzt also auf und wird – wenn man so will – von der Public Cloud aufgefangen.

Die Hybrid Cloud ist eine Lösung, die eine Private Cloud mit einem oder mehreren Public Cloud Services kombiniert und mittels proprietärer Software eine Kommunikation zwischen unterschiedlichen Services ermöglicht. Hybrid Cloud Services sind leistungsfähig, weil sie Unternehmen eine bessere Kontrolle ihrer privaten Daten ermöglichen. Eine Organisation kann vertrauliche Daten in einer Private Cloud oder in einem lokalen Rechenzentrum speichern und gleichzeitig von den robusten Rechenressourcen einer verwalteten Public Cloud profitieren. https://www.citrix.com/de-de/glossary/what-is-hybrid-cloud.html

Für welche Anwendungen ist das interessant? Es ist hauptsächlich dann spannend, wenn die Last stark schwankt. Eine gewisse Grundlast wird durch die private Cloud abgedeckt und die Spitzen skalieren automatisch in die Public Cloud. So fallen dort auch nur Kosten an, wenn die Ressourcen benötigt werden.

Lastzeiten
Abbildung 1: Lastzeiten – eigene Darstellung

Use Case Machine Learning

Machine Learning (kurz ML) kann ziemlich viel Ressourcen und Zeit in Anspruch nehmen. Neuronale Netze zur Bilderkennung, welche für das ImageNet Projekt trainiert wurden, benötigen mittlerweile nur noch wenige Minuten Trainingszeit. Dafür müssen jedoch mehrere Knoten mit jeweils mehreren GPUs zur Beschleunigung eingesetzt werden1 . Gleichzeitig unterscheidet sich die Auslastung beispielsweise von der eines Web-Servers. Während dieser potenziell unendlich lange läuft, ist das Training eines neuronalen Netzes irgendwann abgeschlossen. Beim maschinellen Lernen können deshalb erhebliche Schwankungen entstehen.

In der Beispielanwendung sollen Trainingsdaten auf eine hybride Cloud-Plattform hochgeladen werden. Das Training erfolgt mit der Python-Bibliothek Keras, welche über eine einfache API verfügt und verschiedene Beispiele bereitstellt. Es können jedoch auch andere Frameworks oder Bibliotheken genutzt werden. Zu Beginn des Trainings werden die Trainingsdaten von der Plattform heruntergeladen. Daraufhin wird das eigentliche Learning ausgeführt. Zum Schluss wird das fertige Modell auf die Plattform hochgeladen. Ob das Training nun im privaten oder im öffentlichen Teil stattfindet, muss automatisch von der Hybrid Cloud entschieden werden.

Technische Hürden: Kommunikation einzelner Services

Innerhalb eines Kubernetes Clusters können einzelne Services miteinander kommunizieren. Jeder Service bekommt dazu seinen eigenen clusterinternen DNS-Eintrag. In der Regel besteht ein Cluster aus mehreren Knoten. Auf welchem ein Container ausgeführt wird, wird von Kubernetes entschieden. In einer Hybrid Cloud existieren mindestens zwei Cluster. Idealerweise verhalten sich diese wie ein großer Cluster. Daraus entstehen folgende Herausforderungen:

  1. Cross-Cluster-Kommunikation: Services können über Clustergrenzen hinweg untereinander kommunizieren, als wären sie alle im selben Cluster.
  2. Multicluster-Scheduling: Kubernetes Pods werden automatisch in einem freien Cluster platziert.

 

Technische Umsetzung durch Cross-Cluster Kommunikation und Multicluster-Scheduling

Zum Glück gibt es für beide Probleme Lösungen aus der Kubernetes-Community. Für die Cross-Cluster-Kommunikation kann das Service Mesh Istio als Mulitcluster-Installation eingesetzt werden. Dies hat den schönen Nebeneffekt, dass automatisch sämtlicher Netzwerkverkehr über mutual TLS (mTLS) verschlüsselt wird. Andere Lösungen wie Cilium oder Linkerd verfügen über ähnliche Funktionen.

Das Multicluster-Scheduling kann über den gleichnamigen Multicluster Scheduler von Admiralty erreicht werden. Dessen Einsatz ist außerdem im Blogbeitrage Running Argo Workflows Across Multiple Kubernetes Clusters auf deren Website erläutert.

 Istio Multicluster Service Mesh
Abbildung 2: Istio Multicluster Service Mesh – eigene Darstellung

Was bedeutet dies nun für unseren Use Case? Durch den Einsatz von Istio können die Trainingsdaten aus jedem Cluster der Hybrid Cloud heruntergeladen werden, ohne dass dafür extra Freischaltungen nötig sind. Über den Ausführungsort des Machine Learnings entscheidet der Multicluster Scheduler.

Damit das Bursting auch funktioniert, muss in der Public Cloud das Autoscaling für den Kubernetes Cluster aktiviert werden. So werden bei steigender Last automatisch neu Konten zum Cluster hinzugefügt.

Test der Beispielumgebung

Natürlich haben wir die Beispielanwendung einem Test unterzogen. Dabei wurden in kurzer Zeit eine große Menge an ML-Jobs erstellt und ausgewertet in welchem Cluster sie ausgeführt wurden. Die Erwartung war, dass zunächst der private Cluster genutzt wird und im Anschluss der öffentliche. Im Test hat dies größtenteils auch funktioniert, allerdings wurden einzelne Jobs schon in die Public Cloud „geburstet“, als in der Private Cloud noch ausreichend Kapazität verfügbar war. Hier offenbart sich eine aktuelle Schwäche des Schedulers. Seine Entscheidungen lassen sich nur schwer nachvollziehen oder beeinflussen. Die Möglichkeit Cluster zu gewichten könnte Abhilfe schaffen. Dann könnte dem privaten Cluster eine höhere Priorität zugewiesen werden. Da sich das Projekt aber noch in der Beta-Phase befindet, ist eine Umsetzung in Zukunft in Betracht zu ziehen.

Fazit: Wie lässt sich Cloud Bursting implementieren 

Cloud Bursting lässt sich basierend auf Kubernetes, Istio und dem Multicluster Scheduler implementieren. Es kann helfen, die Cloud bei Lastschwankungen besser zu nutzen. Der Funktionsumfang des Schedulers lässt aktuell noch ein Feature zur Priorisierung von Clustern vermissen. Es sind einige weitere Projekte zur Mulitcluster-Verwaltung in der Entstehung. Dazu zählen z. B. Kubernetes Federation, Submariner oder Google Anthos. Es bleibt also weiterhin spannend.

Simon Mennig hat diesen Blogbeitrag im Rahmen seiner Thesis „Herausforderungen bei einer Hybrid Cloud“ verfasst.


1 https://www.fast.ai/2018/08/10/fastai-diu-imagenet/

Hochautomatisiertes Fahren findet auch in der Cloud statt

Vollautonomes Fahren ist in aller Munde. Die einen erwarten mehr Sicherheit im Straßenverkehr. Die anderen haben Angst vor der Autonomie künstlicher Intelligenzen und den ethischen Konsequenzen. Tatsächlich ist das vollautonome Fahren (Stufe 5 des autonomen Fahrens1 ) auf unseren Autobahnen noch Zukunftsmusik. Längst real hingegen sind die immer ausgereifteren Fahrerassistenzsysteme in modernen Fahrzeugen, die das Leben des Fahrers erleichtern und die Sicherheit verbessern sollen. Diese Assistenzsysteme nehmen aktuell die Hürde zur Stufe 3, dem hochautomatisierten Fahren (HAF). Und das findet nicht nur im Fahrzeug statt, sondern auch in der Cloud. Warum das so ist und was das für die Softwareentwicklung bedeutet, lest ihr hier.

Fahrzeugsensordaten reichen für hochautonomes Fahren nicht aus

Heutige Fahrerassistenzfunktionen basieren meist auf der Auswertung der Daten unterschiedlicher Sensoren und Systeme eines Fahrzeugs wie Kamera, Ultraschall, Lidar oder Radar. Diese erkennen jeweils Teilausschnitte der Umgebung und werden zu einem einheitlichen Umfeldmodell zusammengefügt. Dieses Umfeldmodell stellt verschiedenste Informationen zu bewegten Objekten, statischen Hindernissen, Straßenverläufen und mehr bereit. Das „Sichtfeld“ des Fahrzeugs ist auf dieses Umfeld eingeschränkt.

Das allerdings reicht nicht aus, um den Weg zum hochautomatisierten Fahren konsequent weiterzugehen. Vielmehr muss das bisherige Umfeldmodell zur Berechnung und Kontrolle des Fahrwegs deutlich erweitert werden. Dies geschieht mit Informationen, die von außerhalb der Sensorreichweite kommen. Mit ihnen lassen sich die Fahrfunktionen dynamisch verbessern und sogar ganz neue Fahrfunktionen entwickeln. Damit werden IT-Systeme, die sich außerhalb des Fahrzeugs befinden, erstmals Teil fahrdynamischer Fahrzeugfunktionen.

IT-Systeme außerhalb des Fahrzeugs werden Teil der Fahrerassistenzsysteme

Mit den neuen Fahrzeugvarianten vieler Hersteller kommen weitere Fahrzeugfunktionen auf die Straße, die durch IT-Systeme in der Cloud unterstützt und erweitert werden. Das Backend in der Cloud hält zum Beispiel das Kartenmaterial aktuell und liefert dynamische Informationen. Diese Informationen basieren sowohl auf externen Informationsquellen als auch aus aggregierten Sensordaten vieler Fahrzeuge. IT-Systeme im Hintergrund sammeln diese Daten aus unterschiedlichen Quellen, bereiten sie auf und liefern sie wieder an die Fahrzeuge aus.

Ein solches HAF-IT-System ermittelt zunächst, ob die jeweilige Information für ein Fahrzeug relevant ist. Der Standort des Fahrzeugs dient dabei als Basis, und alle im Umkreis dieses Standorts auftretenden Events sind potenziell für ein Fahrzeug relevant. Der Umkreis wird dabei abhängig von der Art des Events festgelegt. Da sich der Standort eines Fahrzeugs bei der Fahrt ständig ändert, ist es essentiell, dass nur die jeweils veränderte Information an das Fahrzeug übertragen wird.

Fahrzeug und HAF-System sind in ständigem Austausch

Das IT System stellt unterschiedliche Informationen über Umfeldbedingungen wie etwa Geschwindigkeitsbegrenzungen, Baustellen oder Ampelphasen zur Verfügung. Diese können als sogenannte Events an die Fahrzeuge übertragen werden. Die Fahrzeuge können sich für eine oder mehrere Eventarten anmelden, so dass sie Benachrichtigungen zu den jeweiligen Events erhalten.

Dabei kann es ganz unterschiedliche Arten von Events geben, an denen die Fahrzeuge beziehungsweise ihre Fahrer interessiert sein können, zum Beispiel Informationen zu variablen, elektronischen Geschwindigkeitsbegrenzungen. Diese können aufgrund von Verkehrsbedingungen, Baustellen oder anderen Gegebenheiten unterschiedliche Werte anzeigen. Eine weitere Eventart sind Warnungen vor gefährlichen Fahrbedingungen wie Glatteis. Solche frühzeitigen Warnungen sollen helfen Unfälle zu vermeiden.

Über Streckenfreigabe-Events kann dem Fahrzeug außerdem mitgeteilt werden, welche Teilabschnitte für autonomes Fahren geeignet sind. Außerdem sind RTTI-Informationen zur aktuellen Verkehrslage möglich sowie Events, die Daten zur Dauer von Ampelphasen übertragen. Mit letzteren ist es prinzipiell möglich, die Geschwindigkeit entsprechend zu ermitteln, um bei der nächsten Ampel bei grün anzukommen.

Ein IT-System für HAF bildet die die Grundlage für eine übergreifende Plattform, die weitere digitale Services in den Bereichen Gefahrenwarnung, Navigation, Verkehrsinformationen und Parken ermöglicht. Dabei gilt auch hier, dass die Automobilhersteller erst einen Teil dieser Eventarten umgesetzt haben und vieles noch Zukunftsmusik ist.

Ein agiler cloudbasierter Ansatz ist Erfolgsfaktor für HAF-Systeme

Damit das hochautomatisierte Fahren mit Unterstützung eines IT-Systems im Hintergrund zuverlässig funktioniert und auch in Zukunft erweitert werden kann, sind die Anforderungen an die entwickelte Backend-Software hoch. Ausfallsicherheit und Performanz sind genauso sicherzustellen, wie die Skalierbarkeit für zukünftige Erweiterungen.

Zusammen mit Kunden und Partnern entwickelt doubleSlash HAF-Backendsysteme, die Informationen sammeln, auswerten und die daraus berechneten dynamischen Informationen an die Fahrzeugflotte verteilen. Bei der Entwicklung haben unsere Experten folgende Erfolgsfaktoren identifiziert:

Cloudbasierter Ansatz und Microservice Architektur

Das technologische Fundament einer HAF-Anwendung stellt die Kunden-Cloud dar. Die cloudbasierte Anwendung dient dazu, die Hochverfügbarkeit des Systems in allen Regionen zu garantieren und eine stetig wachsende Fahrzeugflotte bedienen zu können.

Das IT-System basiert auf einer flexiblen Microservice-Architektur mit fachlich getrennten, unabhängigen Services. Für Monitoring und Logging werden aktuelle Cloud-Technologien eingesetzt.

SAFe – agile Zusammenarbeit im großen Stil

Ein agiles Vorgehensmodell macht flexible Reaktionen auf Veränderungen möglich. Da das Projekt in einem größeren Gesamtkontext mit verschiedenen IT-Systemen im Bereich automatisiertes Fahren zu sehen ist, bietet sich hier das Modell SAFe („Scaled Agile Framework“) an.

Das agile Manifest ist die Grundlage für SAFe, daraus werden – wie für Scrum – die SAFe Prinzipien abgeleitet. SAFe geht jedoch noch einen Schritt weiter, denn das Rahmenwerk ist zur Koordination mehrerer agiler Teams und Projekte gedacht. Diese Scrum Teams arbeiten auf ein gemeinsames Ziel hin, ihre Projekte sind Teil eines größeren Produkts. Durch den Zusammenschluss der einzelnen Teams lassen sich Abhängigkeiten identifizieren und Redundanzen vermeiden. Ihre Sprints haben einen gemeinsamen Takt, und die Ergebnisse der einzelnen Teams werden durch eine übergreifende Planung auf der Program Increment Ebene aufeinander abgestimmt.2

 

Fazit

Für hochautomatisiertes Fahren (HAF) werden zahlreiche Informationen außerhalb der Sensorreichweite eines Fahrzeuges benötigt, damit das Fahrerassistenzsystem lernen kann. Dafür liefern IT-Systeme außerhalb des Fahrzeuges aufbereitete dynamische Informationen auf Basis unterschiedlichster Informationsquellen. Für solche Systeme gelten besonders hohe Anforderungen an Themen wie Performanz, Ausfallsicherheit und Skalierbarkeit. Um dies zu gewährleisten, setzen wir auf aktuelle Cloud-Technologien und ein agiles, aber skalierbares Vorgehensmodell. Mit letzterem lässt sich schnell und flexibel auf Veränderungen reagieren – ohne jedoch Abhängigkeiten zu anderen Projekten im Gesamtkontext außer Acht zu lassen.

 

Beispiel: Technolgy Stack auf Basis Amazon Webservices
Amazon Web Services (AWS)

  • Amazon Elastic Compute Cloud (EC2)
  • Amazon Elastic Kubernetes Service (EKS)
  • Amazon Relational Database Service (RDS)
  • Amazon Virtual Private Cloud (VPC)
  • AWS Security Groups
  • Amazon CloudWatch
  • Amazon Route 53
  • AWS Lambda
Kubernetes
Docker
Terraform
Grafana
Kibana
Agile Toolchain
Atlassian Confluence, Jira, Bitbucket
Gitlab
Mehr zum Technology Stack erfährst du hier

 

Mehr zum Thema autonomes Fahren:

Von Driver-Only bis Roboter-Taxi – die Herausforderungen beim automatisierten Fahren

 


Quellen:

1 https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/fahrerassistenzsysteme/

2 https://www.scaledagileframework.com/

Vendor Lock-In in der Cloud richtig erkennen

Besitzen Sie mehrere Apple-Produkte? Dann können Sie nicht einfach auf ein Samsung Smartphone umsteigen, da Ihnen so die Kompatibilität zu Ihrer Apple Watch verloren ginge. Sie müssten sich zusätzlich noch eine andere Smartwatch zulegen, die mit Ihrem neuen Smartphone kompatibel ist. Selbst wenn Sie gerne also ein Samsung Smartphone hätten, der komplette Umstieg auf eine andere Marke wäre teuer. Hindern Sie die abzusehenden Kosten an einem solchen Umstieg und Sie bleiben deshalb bei Ihrem iPhone, hat Apple Sie „eingelockt“ – man spricht hier auch von „Vendor Lock-In“. Wir zeigen Ihnen was Vendor Lock-In ist und wie Sie es richtig erkennen.

Vendor Lock-In ist die Abhängigkeit eines Anwenders/ Kunden/ Nutzers bezüglich eines oder mehrerer Produkte oder Services von einem bestimmten Hersteller. Diese Abhängigkeit entsteht dadurch, dass ein Wechsel zu einem alternativen Anbieter

  • aufgrund mangelnder Alternativen (z.B. fehlender Funktionen) nicht möglich oder
  • aufgrund zu hoher Transaktionskosten unwirtschaftlich ist.

Das klingt zunächst nach etwas, womit wir uns nur selten befassen müssen. Aber weit gefehlt – Vendor Lock-In kann nicht nur in unserem Alltag auftreten, sondern auch in der Cloud. Wie entsteht ein solcher Vendor Lock-In und wie können Sie ihn erkennen?

Vendor Lock-In der Cloud – was ist das?

Ein Vendor Lock-In in der Cloud entsteht dann, wenn die Kosten für eine Migration höher sind als ihr Nutzen.¹ Haben Sie sich für einen bestimmten Cloud-Anbieter entschieden, kann es verschiedene Gründe geben, dass ein Umstieg zu einem anderen Cloud-Anbieter – sollte dieser gewünscht oder notwendig sein – so teuer ist, dass diese Kosten die Vorteile der Migration überwiegen. Im Rahmen meiner Thesis habe ich ein Vorgehen entwickelt, um einen möglichen Vendor Lock-In in der Cloud frühzeitig erkennen und ihm vorbeugen zu können.

Vendor Lock-In am Beispiel von Serverless-Plattformen

Wie ein Vendor Lock-In in der Cloud entstehen kann, lässt sich sehr gut anhand verschiedener Serverless Plattformen zeigen. AWS Lambda und Google Cloud Functions ermöglichen beispielsweise beide das Erstellen von Functions. Functions sind in ihrer Funktion abgeschlossene Code-Einheiten, die bei Bedarf automatisiert ausgeführt werden. Vergleicht man AWS Lambda² mit Google Cloud Functions³, so fällt zunächst auf, dass nicht unbedingt die gleichen Programmiersprachen und Laufzeitumgebungen verwendet werden können. Von beiden Umgebungen werden Node.js, Python und Go unterstützt, seitens AWS Lambda zudem noch Java, C# und Ruby. Wurden nun Functions für AWS Lambda in Java erstellt, können diese nicht für die Google Cloud übernommen werden, da hier keine Java Functions unterstützt werden.

Weiterhin werden in den verschiedenen Cloud-Plattformen verschiedene proprietäre Bibliotheken verwendet. Eine Bibliothek ist eine vorgefertigte Sammlung von Programmcode, der für bestimmte Aufgaben eingesetzt werden kann. Für die betrachteten Plattformen gibt es zum Beispiel die folgenden Bibliotheken:

  • AWS – aws-lambda-java-core: Diese Bibliothek enthält unter anderem das Lambda-Context-Objekt, über das mit der AWS Lambda-Ausführungsumgebung interagiert wird.4
  • Azure – com.microsoft.azure.functions: Diese Bibliothek enthält unter anderem den ExecutionContext, durch den mit der Azure Functions-Ausführungsumgebung interagiert wird.5

Functions können also nicht immer einfach von einer Cloud in die andere übernommen werden, sondern müssen vorher möglicherweise angepasst oder komplett neu geschrieben werden.

Für ein paar Functions ist dies vielleicht kein großer Aufwand. Denken Sie jedoch daran, dass Ihre Anwendung vermutlich nicht ausschließlich aus Functions besteht. Sie müssen beispielsweise auch folgende Punkte genauer betrachten:

  • Sind Ihre Daten kompatibel mit der Zieldatenbank in der neuen Cloud?
  • Wie viel kostet der Export der Daten?
  • Was muss in der Anwendung angepasst werden, um proprietäre Cloud-Schnittstellen unterstützen zu können?
  • Und sind die benötigten Funktionalitäten überhaupt in der neuen Cloud verfügbar?

 

Vendor Lock-In richtig erkennen

Die Summe all dieser verschiedener Lock-In-Gefahren ist es, die am Ende einen Vendor Lock-In ausmachen können. Aus diesem Grund beschäftigte sich meine Thesis mit der Entwicklung einer Möglichkeit, einen Vendor Lock-In zu erkennen. Damit noch darauf reagiert werden kann, muss dies möglichst vor der Migration in eine Cloud oder vor der Neuentwicklung eines Cloud-Services geschehen.

Wie bereits erwähnt entsteht ein Vendor Lock-In dann, wenn die Kosten für eine Migration ihren Nutzen übersteigen. Es müssen also sowohl die Kosten einer Migration als auch ihr Nutzen identifiziert werden, um einen Vendor Lock-In erkennen zu können.

Da der tatsächliche Nutzen einer Migration erst in der Zukunft deutlich werden würde und somit nicht vorhersehbar ist, muss hierfür eine alternative Zahl herangezogen werden. Deshalb wird der Nutzen betrachtet, der bei der Wahl eines bestimmten (anstatt eines bestimmten anderen) Cloud-Anbieters entsteht. Beispielhaft ist dies hier mit fiktiven Zahlen zu sehen:

 

Berechnung eines Vendor Lock-Ins
Abbildung: Beispiel für die Berechnung eines Vendor Lock-Ins (anhand fiktiver Zahlen)

Im Beispiel fällt die Entscheidung auf die Cloud A. Betrachtet werden die Erstellungskosten, bei denen zunächst gegenüber der Wahl von Cloud B ein Nutzen von 10.000€ entsteht. Durch die günstigeren Nutzungskosten in einem bestimmten Betrachtungszeitraum entsteht hier außerdem ein Nutzen von zusätzlich 5.000€. Der Nutzen im Betrachtungszeitraum insgesamt liegt also bei 15.000€. Diesem muss man jedoch die zu erwartenden Migrationskosten gegenüberstellen, im Beispiel 30.000€. Da der Nutzen dann negativ wird, entstünde hier ein Vendor Lock-In.

 

Fazit:

Letztendlich besteht jedoch auch hier das Problem, dass sich in der Zukunft die Nutzungskosten und die zu erwartenden Migrationskosten verändern können. Entweder wird so eventuell ein Vendor Lock-In vorausgesagt, der dann doch nicht entsteht, oder ein Vendor Lock-In tritt wider Erwarten doch auf. Es kann also keine genaue, durch Zahlen belegte Aussage getroffen werden, ob bei einem Cloud-Anbieter mit Sicherheit ein Vendor Lock-In auftreten wird.

Trotzdem können die identifizierten Migrationskosten zumindest als Einschätzung herangezogen werden, an welchen Stellen in einer Cloud-Anwendung ein Vendor Lock-In entstehen könnte. In Verbindung mit Expertenwissen kann so eingeschätzt werden, ob einem möglichen Lock-In entgegengewirkt werden sollte und welche Maßnahmen hierzu herangezogen werden können.

 

Welche FaaS-Plattform ist für Ihren Anwendungsfall die geeignete?

 


Quellen:

1 angelehnt an: Justice Opara-Martins, Reza Sahandi und Feng Tian. „A Holistic Decision Framework to Avoid Vendor Lock-in for Cloud SaaS Migration. In: Computer and Information Science 10 (Juli 2017), S. 29. issn: 1913-8989. doi: 10.5539/cis.v10n3p29. (S.30)

2 https://docs.aws.amazon.com/de_de/lambda/latest/dg/lambda-runtimes.html

3 https://cloud.google.com/functions/docs/writing

4 https://docs.aws.amazon.com/de_de/lambda/latest/dg/java-programming-model.html

5 https://docs.microsoft.com/en-us/java/api/com.microsoft.azure.functions.executioncontext?view=azure-java-stable