Gitops Basiertes Continuous Delivery Für Serverless Anwendungen

Institut für Architektur von Anwendungssystemen

Universität Stuttgart Universitätsstraße 38 D–70569 Stuttgart

Masterarbeit

GitOps basiertes Continuous Delivery für Serverless Anwendungen

Müslüm Sahin

Studiengang: Softwaretechnik

Prüfer/in: Prof. Dr. Dr. h. c. Frank Leymann

Betreuer/in: Michael Wurster, M.Sc.

Beginn am: 3. September 2018

Beendet am: 4. März 2019

Kurzfassung

Das Ziel dieser Masterarbeit ist ein Konzept für eine anbieterunabhängige Continuous Delivery Lösung für Serverless Anwendungen zu entwickeln und prototypisch umzusetzten. Serverless bezeichnet ein Paradigma, bei dem die Infrastruktur komplett vom Entwickler verborgen bleibt und vom Cloud Anbieter verwaltet wird. Function-as-a-Service (FaaS) beschreibt ein Serverless Cloud-Service mit der kleine, kurzlebige und ereignisgesteuerte Funktionen bereitgestellt werden. Aufgrund der feinen Granularität von Business Services erhöht sich die Komplexität für Deployment und Management der Anwendung. Daher sind automatisierte DevOps Methoden durch Continuous Delivery und Infrastructure-as-Code (IaC) essentiell für eine zuverlässige, sichere und schnellere Softwareauslieferung. Dies wird bereits von einigen Cloud Providern mit eigenen Cloud-Services unterstützt, was jedoch zu einem Vendor Lock-in führt, da individuelle Imple- mentierungen und DevOps-Prozesse vom Anbieter abhängig sind. Daher untersucht diese Arbeit den Stand der Technik im Bereich Herausforderungen, Konzepte, Technologien im gemeinsamen Kontext von Serverless, Continuous Delivery und Multi-Cloud. Hierfür wird eine systematische Literaturrecherche (SLR) verwendet. Statistische Analysen der SLR und weitere Recherchen haben ergeben, dass die Einschränkungen von proprietären FaaS-Plattformen durch Abstraktionen und Multi-Cloud Tools ein alternatives Konzept ergeben, der Vendor Lock-in aber immer noch existiert. Ein Pseudo-Algorithmus wurde entwickelt, um das geeignete Infrastructure-as-Code (IaC) Modell für das Vendor Lock-in Problem zu finden, solange keine Standards für Serverless Anwendungen existieren. Auf Basis weiterer Recherchen wurde ein Konzept für eine GitOps basierte Continuous Delivery Pipeline entwickelt. Um das Konzept zu zeigen wurde eine prototypische CI/CD Pipeline anhand einer Beispielanwendung implementiert. Das Konzept bietet eine Isolierung der Plattform- Anbieter und ist anbieterunabhängig. Das Ergebnis der Arbeit hat gezeigt, dass die Technologie noch jung im Bezug auf Tooling-Support, Standardisierung und Forschung ist. Weiterhin wird zu erwarten sein, dass sich die Lücke zwischen Serverless und Container-Orchestrierung irgendwann schließen wird.

Inhaltsverzeichnis

1. Einleitung 17 1.1. Forschungsmethode ...... 19 1.2. Gliederung ...... 19

2. Grundlagen 21 2.1. Serverless und Function-as-a-Service ...... 21 2.2. Continuous Delivery für Serverless Anwendungen ...... 26 2.3. Der Vendor Lock-in und Function-as-a-Service ...... 29

3. Verwandte Arbeiten 33

4. Stand der Technik: Eine Systematische Literaturrecherche 35 4.1. Planung der Recherche: Das Review-Protokoll ...... 35 4.2. Durchführung der Recherche ...... 40 4.3. Ergebnisse der Recherche ...... 42 4.4. Fazit der SLR ...... 46

5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen 49 5.1. Infrastructure-as-Code für Serverless Anwendungen ...... 49 5.2. Alternatives Konzept: Abstraktionen durch Serverless Framework und Tools .. 51 5.3. Alternatives Konzept: Multi-Cloud Orchestrierung ...... 54 5.4. Fazit der Alternative ...... 55

6. Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen 57 6.1. Cloud-agnostisches FaaS durch Container-Orchestrierung ...... 57 6.2. Continuous Delivery mit GitOps ...... 57 6.3. Architektur des Konzepts ...... 59

7. Prototypische Implementierung 63 7.1. Verwendete Technologien ...... 63 7.2. Komponenten der Implementierung ...... 66 7.3. Beispiel einer FaaS Anwendung: Wettervorhersage mit der OpenWeatherMap . 72 7.4. Fazit der Implementierung ...... 74

8. Zusammenfassung und Ausblick 75

Literaturverzeichnis 77

A. Datenextraktion der Studien 87

B. Synthetisieren der Daten 111

5 C. Suchphrasen der SLR 115

6 Abbildungsverzeichnis

1.1. Serverless im Trend (2014-2019) Quelle: [Goo] ...... 18 1.2. Gewünschte Architektur (vereinfacht) für von Serverless-Anwendungen Quelle: inspiriert durch [Zima] ...... 19

2.1. Monolith, Microservices und Serverless Funktionen (inspiriert durch: [Ang]) .. 22 2.2. Funktionsweise von FaaS(inspiriert durch: [Gan17]) ...... 23 2.3. Serverless und andere Cloud-native Technologien Quelle: [Cnc18]) ...... 24 2.4. Allgemeine Continuous Delivery Pipeline ...... 27 2.5. CI/CD Pipeline einer Serverless Anwendung in AWS - Quelle: inspiriert durch ([LB16]) ...... 31

4.1. Suchphrase (Beispiel) ...... 37 4.2. SLR Ergebnisse ...... 41 4.3. Probleme/Herausforderungen im CI/CD in Serverless/FaaS ...... 43 4.4. Konzepte für CI/CD in Serverless/FaaS ...... 44 4.5. Technologien für CI/CD in Serverless/FaaS ...... 45 4.6. Konzepte für CI/CD in Multi-Cloud ...... 46 4.7. Technologien für CI/CD in Multi-Cloud ...... 47

5.1. Allgemeine Deployment-Pipeline mit dem Serverless Framework Quelle: Eigene Darstellungs ...... 53 5.2. Allgemeine Deployment-Pipeline mit Multi-Cloud IaC Tool Terraform Quelle: Eigene Darstellung ...... 55

6.1. Abstraktes Multi-Cloud FaaS durch Container-Orchestrierung Quelle: Eigene Dar- stellung ...... 58 6.2. GitOps Pipeline: Push-Modell Quelle: [Wea] ...... 59 6.3. GitOps Pipeline: Pull-Modell Quelle: [Wea] ...... 59 6.4. Abstrakte CD-Pipeline von containerisierten Serverless Anwendungen Quelle: Eigene Darstellung ...... 60 6.5. Gesamt-Architektur des Konzepts: GitOps basiertes Continuous Delivery Quelle: Eigene Darstellung ...... 61

7.1. OpenFaaS Komponenten Quelle: [Ope19] ...... 65 7.2. GitHub Commit Logs (Build Status) mit Travis CI Integration - Quelle: [Sah19] . 67 7.3. Architektur der prototypischen Continuous Delivery Pipeline Quelle: Eigene Dar- stellung ...... 69

C.1. Suchphrase 1 (FF1) ...... 115 C.2. Suchphrase 2 (FF1) ...... 116

7 C.3. Suchphrase 3 (FF1) ...... 116 C.4. Suchphrase 4 (FF1) ...... 116 C.5. Suchphrase 5 (FF1) ...... 117 C.6. Suchphrase 6 (FF2) ...... 117 C.7. Suchphrase 7 (FF3) ...... 117 C.8. Suchphrase 8 (FF3) ...... 118

8 Tabellenverzeichnis

2.1. Vergleich der Cloud-spezifischen Features von AWS Lambda, Google Cloud Func- tions und Azure Functions ...... 30

4.1. Suchterme mit Abkürzungen und Synonymen ...... 37 4.2. Formular zur Datenextraktion ...... 39 4.3. Synthese-Formular für FF1 ...... 39 4.4. Synthese-Formular für FF2 ...... 39 4.5. Synthese-Formular für FF3 ...... 39 4.6. Die SLR-Studien nach Quelle ...... 41

A.1. Datenextraktion für [AC17] ...... 87 A.2. Datenextraktion für [SJ17] ...... 88 A.3. Datenextraktion für [FCSS15] ...... 88 A.4. Datenextraktion für [DMB18] ...... 89 A.5. Datenextraktion für [FSR+14] ...... 89 A.6. Datenextraktion für [FCS+18] ...... 90 A.7. Datenextraktion für [BGK+13] ...... 90 A.8. Datenextraktion für [FCR+13] ...... 91 A.9. Datenextraktion für [GCGA15] ...... 91 A.10.Datenextraktion für [VJ14] ...... 92 A.11.Datenextraktion für [AKC+15] ...... 92 A.12.Datenextraktion für [Ren16] ...... 93 A.13.Datenextraktion für [BIS+14] ...... 93 A.14.Datenextraktion für [SZD+15] ...... 94 A.15.Datenextraktion für [Elg15] ...... 94 A.16.Datenextraktion für [MJB+17] ...... 95 A.17.Datenextraktion für [MB17] ...... 95 A.18.Datenextraktion für [SS18] ...... 96 A.19.Datenextraktion für [JY18] ...... 96 A.20.Datenextraktion für [MPF18] ...... 97 A.21.Datenextraktion für [LRLE17] ...... 98 A.22.Datenextraktion für [HB13] ...... 99 A.23.Datenextraktion für [PM13] ...... 99 A.24.Datenextraktion für [FRC+13] ...... 100 A.25.Datenextraktion für [CFN+14] ...... 101 A.26.Datenextraktion für [PTD+15b] ...... 101 A.27.Datenextraktion für [CDR+17] ...... 102 A.28.Datenextraktion für [PTD+15b] ...... 102 A.29.Datenextraktion für [BPR16] ...... 103

9 A.30.Datenextraktion für [BSG+18] ...... 103 A.31.Datenextraktion für [SIV17] ...... 104 A.32.Datenextraktion für [PMM15] ...... 104 A.33.Datenextraktion für [GG18] ...... 105 A.34.Datenextraktion für [YG16] ...... 105 A.35.Datenextraktion für [EBM16] ...... 106 A.36.Datenextraktion für [DAFP15] ...... 106 A.37.Datenextraktion für [ALKH17] ...... 107 A.38.Datenextraktion für [TPM+17] ...... 107 A.39.Datenextraktion für [PLB+17] ...... 108 A.40.Datenextraktion für [PICP16] ...... 108 A.41.Datenextraktion für [PRS17] ...... 109 A.42.Datenextraktion für [MGZ+17] ...... 109

B.1. Synthetisieren der Daten für FF1 ...... 111 B.2. Synthetisieren der Daten für FF2 ...... 112 B.3. Synthetisieren der Daten für FF3 ...... 113

10 Verzeichnis der Listings

2.1. HelloWorld Java Handler in AWS Lambda - LambdaMethodHandler.java .... 23 2.2. Beispiel einer Funktionsdefinition in AWS SAM - app-spec.yaml ...... 29 5.1. Beispiel einer Funktionsdefinition mit Serverless Framework - serverless.yml .. 53 5.2. Beispiel einer Funktionsdefinition mit dem Terraform Tool -lambda.tf ...... 54 7.1. TravisCI Build Skript - .travis.yml ...... 71 7.2. Lokale Tests in der temporären OpenFaaS Umgebung - weather-forecast.sh .... 72 7.3. OpenFaaS Function Description (IaC) - weather-forecast.yml ...... 72 7.4. Java OpenFaaS Weather Forecast Serverless Anwendung - Handler.java ..... 73

Verzeichnis der Algorithmen

5.1. Selection Algorithmn for IaC Tooling and Pattern ...... 50

Akronyme

AWS Amazon Web Services. 22

BaaS Backend-as-a-Service. 21

CaaS Container-as-a-Service. 17

CI/CD Continuous Integration/Continuous Delivery. 17

CNCF Cloud Native Computing Foundation. 26

CRD Custom Resources Definitions. 64

DP Delivery Pipeline/Deployment Pipeline. 18

EKS Elastic Kubernetes Service. 44

FaaS Function-as-a-Service. 17

GCF Google Cloud Functions. 26

GCP Google Cloud Platform. 29

GKE Google Kubernetes Engine. 44

HCL HashiCorp Configuration Language. 54

IaaS Infrastructure-as-a-Service. 17

IaC Infrastructure-as-Code. 3

JSON JavaScript Object Notation. 31

K8s Kubernetes. 44 kind Kubernetes in Docker. 64

MDE Model-Driven Engineering. 45

PaaS Platform-as-a-Service. 17

PR Pull Request. 58

SAM Serverless Application Model. 29

SLR Systematische Literraturrecherche. 19

SQS Simple Queue Service. 51

TOSCA Topology and Orchestration Specification for Cloud Applications. 45

YAML YAML Ain’t Markup Language. 31

1. Einleitung

Die Zeit der großen On-Premise Software-Monolithen auf eigenen Rechenzentren ist vorbei. Mo- derne verteilte Systeme mit Cloud-nativen Architekturen wie Microservices und leichtgewichtige, selbstständige Container lösen die meisten dieser Einzelsysteme heute ab [BCC+17][FIMS17] [JY18]. Doch trotz des Aufstiegs von Cloud Computing dreht sich die Welt immer noch um Server [Fro12]. Dabei ist es irrelevant, ob Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) oder Container-as-a-Service (CaaS) verwendet wird. Der Nutzer muss abhängig vom Servicemodell bestimmte Verantwortung für das Management von Infrastruktur, Konfigurationen und Deployments eines Servers übernehmen. In den letzten Jahren erfahren Serverless Computing und Function-as-a-Service (FaaS) bedeutend Aufmerksamkeit [JSS+19]. Abbildung 1.1 zeigt eine Statistik von Google Trends über dem welt- weiten Interesse der Technologie in den letzten fünf Jahren (2014 - 2019). Das stark wachsende Interesse an Serverless zeigt die Grafik deutlich. Laut einer Studie von „The New Stack“ setzen43 Prozent der Unternehmen Serverlose Technologien wie FaaS ein. Untersucht wurden Unternehmen, die über eine beträchtliche Anzahl strategischer Workloads verfügen und diese in der Public Cloud dynamisch verwaltet werden können [Law17]. Serverless Computing (oder einfach Serverless) bezeichnet ein Paradigma, bei dem die Infrastruktur komplett vom Entwickler abstrahiert wird [BCC+17][MPF18]. Der Ausdruck Serverless bedeutet nicht, dass Server nicht mehr beteiligt sind. Laut Fromm wird das Denken der Entwickler Ser- verless da der Anbieter die volle Kontrolle und Verantwortung des Servers besitzt [Fro12]. FaaS ist eine Variante von Serverless, bei dem kleine, kurzlebige und ereignisgesteuerte Funktionen auf einer Plattform bereitgestellt werden [BCC+17]. Durch dieses Ausführungsmodell entstehen große Vorteile wie schneller Markteinstieg, niedrige Kosten durch effiziente Ressourcennutzung und produktivere Entwicklung [Rob18][SS18]. FaaS Implementierungen bringen neben den Vorteilen auch Kompromisse ein, die der Entwickler akzeptieren muss. Die Komplexität für Deployment und Management steigt deutlich, da Busi- ness Services in viele kleine Funktionen unterteilt sind [JSS+19]. Aufgrund der ereignisbasierten Architektur und der dynamischen Laufzeit ist das Debuggen von Anwendungen im Vergleich zu IaaS oder PaaS schwieriger [BCC+17][FIMS17]. Für die automatisierte Bereitstellung und die Reproduzierbarkeit des Deployments von Serverless Anwendungen ist es deshalb wichtig, dass Konzepte wie Continuous Integration/Continuous Delivery (CI/CD) ihre Anwendung finden. Continuous Delivery wird von einzelnen Cloud Providern mit eigenen Toolchains schon unterstützt [LB16], was jedoch in einem Vendor Lock-in resultiert. Continuous Delivery Umgebungen sind zudem auf Microservices und Container ausgelegt, da diese als isolierte und zuverlässige Artefakte für cloud-native Anwendungen geeignet sind [JY18]. Die unterschiedlichen FaaS Plattformen haben prinzipiell das gemeinsame Ziel, können aber unterschiedlich in Schnittstellen, Ereignisformaten und Protokollen implementiert sein. Darüber hinaus werden in FaaS Cloud-spezifische Services für Deployment von Serverless Anwendungen verwendet. Das Serverless Ökosystem fehlt es an

17 1. Einleitung

Interesse im zeitlichen Verlauf Serverless Computing: (Weltweit) 100 90 80 70 60 50 40 30 20 10 0 23.02.2014 23.02.2015 23.02.2016 23.02.2017 23.02.2018

Abbildung 1.1.: Serverless im Trend (2014-2019) Quelle: [Goo]

Reife und Standardisierung [FIMS17][JSS+19]. Der Mangel an Tools macht sich im Serverless Bereich ebenso bemerkbar [Rob18][SJ17]. Der Wunsch eines Entwicklers für moderne Serverless Workloads könnte eine Architektur wie die in 1.2 sein. Hier soll einfach nur eine definierte Serverless Anwendung in ein Repository gepusht werden und ein Multi-Cloud Service Bus würde das Manage- ment bedienen, unabhängig davon welche Ereignistypen, Build-Prozesse oder Deployment-Tools die Cloud Anbieter verwenden. Die Anwendung soll isoliert sein von den Anbietern und unabhängig davon bereitgestellt werden können [SS18][Zima]. Es wird im weiteren Verlauf der Arbeit gezeigt, wie so eine Multi-Cloud Deployment Lösung entstehen kann. Ziel dieser Arbeit ist folglich ein Konzept für eine einheitliche und anbieterunabhängige Continuous Delivery Lösung für Serverless Anwendungen zu entwickeln und prototypisch umzusetzen. Da- bei werden Eigenschaften, Gemeinsamkeiten sowie Unterschiede von Serverless und Containern eingeführt. Die Konzepte und Phasen des Continuous Delivery wird als integraler Bestandteil von DevOps grundlegend erklärt. Als Ergebnis der Arbeit wird ein Überblick über den Stand der Technik in Serverless bezüglich DevOps gegeben. Darauf anschließend ein Konzept und Prototyp einer anbieterunabhängigen Delivery Pipeline/Deployment Pipeline (DP) anhand des GitOps Pattern entwickelt.

18 1.1. Forschungsmethode

Source Control

implement push Public Clouds

Developer deploy FaaS Services deﬁne services

Multi-Cloud Service Bus (Event Triggers, Build, Deployment, deploy Skalierung, Monitoring, Debugging, FaaS Services On-Premise Komposition ...)

deploy deploy FaaS Services

Abbildung 1.2.: Gewünschte Architektur (vereinfacht) für von Serverless-Anwendungen Quelle: inspiriert durch [Zima]

1.1. Forschungsmethode

Für die Untersuchung von Stand der Technik im Bereich Serverless Computing, DevOps und Multi- Cloud wird die Systematische Literraturrecherche (SLR) von Kitchenham et al. verwendet. Diese besteht aus den drei Phasen Planung, Durchführung und Berichterstattung [Kit04][KBB+09]. Die Planungsphase beschreibt klar definiertes Review-Protokoll, das für die Durchführung verwendet wird. In diesem Protokoll sind die Forschungsfragen, Suchstrategie und zu durchsuchenden wissenschaftlichen Datenbanken festgelegt. Die SLR besteht aus drei Forschungsfragen (siehe 4.1.2). Hierbei werden Herausforderungen, Probleme, Konzepte, Technologien im Bereich CI/CD, Serverless/FaaS und Multi-Cloud untersucht. Das Ziel der SLR ist es die Forschungsfragen in 4.1.2 zu beantworten, um darauf aufbauend ein Konzept für eine anbieterunabhängige CI/CD-Pipeline für FaaS Anwendungen zu entwickeln. In der letzten Phase werden die Ergebnisse dann in einem Bericht aggregiert, interpretiert und daraus ein Fazit geschlossen.

1.2. Gliederung

Hier werden die Motivationsgründe zur Auswahl des Themas gegeben sowie die Struktur und Froschungsmethode der Arbeit vorgestellt. Im folgenden Kapitel 2 werden die Grundlagen für das weitere Verständnis der Arbeit eingeführt. Anschließend wird in Kapitel 3 eine verwandte Arbeit aufgeführt und in Kapitel 4 der Stand der Technik durch die SLR untersucht. Basierend aus den Ergebnissen aus der SLR werden Alternative Konzepte (Kapitel 5), Hauptkonzept der Arbeit (Kapitel 6) und die prototypische Implementierung in Kapitel 7 vorgestellt. Ein Fazit über die Forschung, das Ergebnis sowie ein kritischer Rückblick schließt die Arbeit mit dem Kapitel 8 ab.

2 Grundlagen Grundlagen im Bereich Serverless, FaaS und CI/CD

19 1. Einleitung

3 Verwandte Arbeiten Ähnliche Arbeiten bezüglich des Themas DevOps, CI/CD und Serverless

4 Stand der Technik: Eine Systematische Literaturrecherche Untersuchung von Stand der Technik in DevOps, FaaS und Multi-Cloud Deployments

5 Alternative Konzepte für Continuous Delivery von Serverless Anwendungen Vorschlag für alternative CI/CD Konzepte und Implementierungen

6 Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen Ausarbei- tung des Konzepts für die Reduzierung des Vendor Lock-in Problems in CI/CD von Server- less/FaaS Anwendungen

7 Prototypische Implementierung Eine prototypische Implementierung des Konzepts anhand einer DP und FaaS-Anwendung

8 Zusammenfassung und Ausblick Ein Fazit und Diskussion für die Zukunft von CI/CD- Methoden und Lösungen im Bereich FaaS.

20 2. Grundlagen

Dieses Kapitel führt die Grundlagen von Serverless Architekturen, FaaS und CI/CD ein, um die Domäne der Arbeit kennenzulernen. Zunächst werden Eigenschaften von Serverless und FaaS Anwendungen vorgestellt. Anschließend werden die Grundlagen von CI/CD im Kontext des FaaS erläutert. Zum Schluss wird das Vendor Lock-in Problem bezüglich CI/CD und FaaS-Applikationen näher erklärt.

2.1. Serverless und Function-as-a-Service

2.1.1. Einführung in Serverless

Serverless beschreibt das Konzept, Anwendungen zu erstellen und auszuführen, wobei keine Server- verwaltung erforderlich ist. Aufgaben wie Bereitstellung, Wartung, Aktualisierung, Skalierung und Kapazitätsplanung des Servers werden von der Serverless Plattform übernommen [Cnc18]. Das Denken der Anwendungsentwickler wird dadurch Serverless, da die Backend-Infrastruktur für den Entwickler abstrahiert wird. Man muss sich nicht mehr darum kümmern, wie und wo der Code ausge- führt wird [Fro12]. Serverless beschreibt zwei Kategorien von Anwendungen: Backend-as-a-Service (BaaS) und FaaS [Rob18][JY18][Iva18][BCC+17].

BaaS API-basierte Cloud-Services von Drittanbietern, die serverseitige Logik und Zustand verwalten. Sie ersetzen typische Backend-Services, die von einer Anwendung verwendet werden, ohne sich um die Serververwaltung wie Skalierung und Transparenz zu kümmern. Beispiele sind Cloud-basierte Datenbanken wie Firebase1 oder Authentifizierungs-Services wie Auth02 [JSS+19].

FaaS benutzerdefinierte, zustandslose Funktionen, die in ephemeren3 Containern auf einer Platt- form ausgeführt und durch bestimmte Ereignisse aufgerufen werden [Rob18]. Im weiteren Verlauf dieser Arbeit wird Serverless gleichbedeutend mit FaaS verwendet, da BaaS als vollständig verwaltete Drittanbieter-Services sind und nicht zum CI/CD Kontext passen. Für diese Arbeit wird daher nur FaaS als Serverless Technologie betrachtet. Eine Relation vom Monolithen bis zu FaaS wird in Abbildung 2.1 dargestellt. Moderne verteilte Microservices aus plattformneutralen, isolierten Containern ersetzen die mo- nolithischen großen Einzelsysteme. Ziel ist es, solche Anwendungen effektiv für die Cloud zu entwickeln [JY18]. Diese lose gekoppelten Komponenten bieten mehr Agilität und unterstützen

1Google Firebase: https://firebase.google.com/ 2Auth0: https://auth0.com/ 3ephemer = kurzlebig, flüchtig, rasch vorübergehend

21 2. Grundlagen

Funktion

Microservice

Funktion

Monolithische Microservice Anwendung

Funktion

Microservice

Funktion

Abbildung 2.1.: Monolith, Microservices und Serverless Funktionen (inspiriert durch: [Ang])

DevOps- und vor allem CI/CD Prozesse, da sie unabhängig voneinander entwickelt und bereitgestellt werden können [LRC+18]. Serverless Anwendungen bestehen aus noch kleineren Funktionen, die zu Microservices zusammengesetzt werden können. Im nächsten Abschnitt wird eine allgemeine FaaS-Architektur aufgezeigt, um den Aufbau solcher Anwendungen verstehen zu können.

2.1.2. FaaS-Architektur

Generell besteht eine FaaS-Plattform aus drei grundlegenden Komponenten: Ereignisquelle, Funkti- on und Service. In Abbildung 2.2 wird die Funktionsweise von FaaS und die Relation zwischen den einzelnen Komponenten veranschaulicht.

Event Source Ein Ereignis, das aus unterschiedlichen Quellen stammen kann: Datenbankeinträge, Datei-Uploads in einen Cloud-Speicher, HTTP-Ereignis durch API-Gateway oder Messaging- Bus über Streaming-Plattformen wie Amazon Web Services (AWS) Kinesis [Cnc18][Rob18].

Function Eine Funktion, die zustandslos ist, ereignisgesteuert aufgerufen wird und vom FaaS- Provider in ephemeren Laufzeiten (normalerweise Container) bereitgestellt wird. Sie kann in den Sprachen implementiert werden, welche die FaaS-Plattform unterstützt [Cnc18][Rob18].

Services Cloud-Services, die durch eine Funktion angestoßen bzw. aufgerufen werden. Diese können wiederum benutzerdefinierte Services (auch erneute Funktionsaufrufe möglich) oder BaaS-Services sein wie z.B. eine Authentifizierung oder Datenbankänderung [Cnc18] [Rob18]. Die Funktionen werden jeweils nach den Spezifikationen der FaaS-Plattform in den entsprechenden Formaten definiert und implementiert. Diese werden als Paket/Archiv an die Plattform übergeben, welche dann für das Kompilieren, Testen und Deployment der Funktion verantwortlich ist[Cnc18]. Der Signatur des simplen Handlers einer HelloWorld-Funktion in AWS Lambda wird in 2.1 gezeigt.

22 2.1. Serverless und Function-as-a-Service

Event Function Services Source

call Trigger

call

Abbildung 2.2.: Funktionsweise von FaaS(inspiriert durch: [Gan17])

Listing 2.1 HelloWorld Java Handler in AWS Lambda - LambdaMethodHandler.java 1 public class LambdaMethodHandler { 2 public String handleRequest(String input, Context context) { 3 context.getLogger().log("Input: " + input); 4 return "Hello World - " + input; 5 } 6 }

Die Methode der Funktion bekommt als Argumente die Eingabe als String-Objekt und ein Context- Objekt, welches Metadaten über die Funktion enthält, an den Handler übergeben werden, sobald AWS Lambda die Funktion ausführt.

2.1.3. Abgrenzung zu anderen Cloud-nativen Technologien

Zur Entwicklung von cloud-nativen Software gibt es drei Entwicklungs-/Deployment-Modelle: Container-Orchestrierung oder CaaS, PaaS und Serverless (FaaS). CaaS Plattformen wie Kubernetes oder Docker Swarm bieten volle Kontrolle über Infrastruktur und maximale Portabilität, Flexibilität, Wiederverwendbarkeit und einfache Integration von containerisierter Anwendungen in die Cloud [Cnc18][JSS+19][PRS17]. PaaS Plattformen wie Cloud Foundry oder Heroku ermöglichen den Entwickler sich lediglich auf die Anwendung zu konzentrieren. Den Großteil wie automatisches Skalieren und Konfigurieren der Services erledigt die PaaS-Plattform [Cnc18]. Der Unterschied zwischen PaaS und FaaS liegt darin, dass es sehr einfach für den Entwickler ist eine Anwendung zu deployen, er aber dennoch über Server, Skalierungsstrategien oder Verfügbarkeit Bescheid wissen muss [BCC+17]. Weiterhin laufen Anwendungen in PaaS immer, in FaaS jedoch werden sie ereignisgesteuert aufgerufen. Abbildung 2.3 zeigt, wie diese Technologien bezüglich Fokus auf Geschäftslogik und der Kontrolle über das Gesamtsystem zueinander stehen.

23 2. Grundlagen

Abbildung 2.3.: Serverless und andere Cloud-native Technologien Quelle: [Cnc18])

Daraus lässt sich schließen, dass CaaS die größte Kontrolle über das gesamte System gibt, jedoch zu viel Verantwortung und Kontrolle dem Nutzer überlassen wird. In Serverless-Architekturen konzentriert sich der Nutzer lediglich auf die Logik und Anwendung, wobei eine große Abhängigkeit zur Plattform besteht. In den zwei kommenden Kapiteln werden die Vor- und Nachteile von Serverless Anwendungen beschrieben.

2.1.4. Vorteile von Serverless Anwendungen

Nach wesentlichen Eigenschaften und der Architektur von Serverless Anwendungen, werden einige Vor- und Nachteile beschrieben.

Kosten On-Demand (bei Bedarf) Ausführung, effizientes Ressourcenmanagement und integrierte Elastizität bringen dem Nutzer erhöhte Verfügbarkeit, Zuverlässigkeit und niedrige Betriebs- kosten [Zimb][MPF18]. Die Bezahlung erfolgt bei Cloud-Anbietern nur nach Ausführungs- dauer.

Produktivität Einfaches Programmiermodell: Implementierung des Codes für die Geschäftslogik. Keine Bereitstellung von Middleware, Laufzeiten oder Server. Dies wird vom Anbieter übernommen.

24 2.1. Serverless und Function-as-a-Service

Flexible Skalierung Völlig automatische Skalierung oder durch Anpassung von Parametern wie Arbeitsspeicher.

Schneller Markteinstieg Durch das einfache Programmiermodell sind Anforderungen für einen bestimmten Bereich sehr schnell implementiert und bereitgestellt.

2.1.5. Nachteile von Serverless Anwendungen

Hier noch einige entscheidende Herausforderungen und Probleme von Serverless Anwendungen:

Komplexität Die feine Granularität von Komponenten senkt die Komplexität dieser einzelner Funktionen, wächst jedoch stark an in Microservices durch Komposition multipler Funktionen. Eine erhebliche Komplexität entsteht zusätzlich im Deployment durch Infrastruktur und Konfigurationen der AnwendungFIMS17 [ ][BCC+17][JSS+19].

Vendor Lock-in FaaS-Anbieter sind unterschiedlich in der Unterstützung von Sprachen und den spezifischen Services des Anbieters und der restlichen Architektur. Ereignisquellen können ebenso unterschiedlich sein. Ein API-Gateway oder Messaging-Bus kann individuell implementiert sein, auch wenn sie zum großen Teil ähnlich aufgebaut sind. Die maximale Dauer der Ausführung von Funktionen oder die Größe des Deployment-Artefakte können auch variieren. Weitere herstellerabhängige Tools sind Monitoring und andere Debugging-Tools [FIMS17] [BCC+17][AC17][MPF18].

Mangelndes Tooling Da viele Techniken und Technologien im Serverless-Umfeld neu sind, ist Tooling weiterhin ein Problem. Es existieren bereits einige Tools und Frameworks für das vereinfachte Bereitstellen von FaaS Anwendungen, dennoch sind viele unreif [SJ17].

Lokales Testen und Debugging Da die Komplexität von Architekturen steigen, wird das lokale Testen ebenso schwieriger, da Sie keine komplette Cloud-Umgebung simulieren. Weiter- hin sind Integrationstests ein Problem, da Entwickler aufgrund der feinen Granularität von Funktionen stark darauf angewiesen sind. Debugging ist aufgrund der ereignisgesteuerten Architektur von FaaS Anwendungen schwierig [AC17].

2.1.6. Anwendungsfälle von Serverless

Serverless Anwendungen passen zu unterschiedliche Workloads. Asynchrone, nebenläufige einfach parallelisierbare und unabhängige Funktionalitäten sind ein Beispiel dafür. Weiterhin eignen sich seltene oder sporadische Nachfragen mit unvorhersehbarer Abweichung in den Skalierungsanfor- derungen gut, da in Serverless nur für die Aufrufszeit bezahlt werden muss. Weiterhin sollten Serverless Anwendungen zustandslos, kurzlebig sein und Kaltstarts tolerieren. Zuletzt könnte die Entwicklergeschwindigkeit durch dynamisch ändernde Business-Anforderungen beschleunigt werden, da der Entwickler sich nur auf die Anwendung konzentrieren muss [Cnc18]. Beispiele für Anwendungsfälle von FaaS sind Single-Page Anwendungen, rechenintensive Komponenten im Machine Learning oder IoT-Applikationen in Mobile Computing Umfeld [FIMS17]. Serverless Anwendungen sind zwar günstiger in der Nutzung, die Komplexität wächst jedoch erheblich an [Zimb]. Daher ist CI/CD für FaaS Anwendungen von großer Bedeutung. Die Grundlagen von CI/CD

25 2. Grundlagen und die Anpassung durch das Anwenden davon im Serverless-Aspekt werden daher im folgenden Kapitel eingeführt. Die SLR in 4 wird hier einen Überblick über Probleme und Lösungen in diesem Bereich aufzeigen.

2.1.7. Serverless Anwendungsmodelle

Durch Serverless entstehen neue Anwendungsmodelle für Cloud-native Anwendungen. Das Cloud Native Landscape-Projekt kategorisiert Projekte und Produktangebote im Cloud-Bereich. Es wurde von der Cloud Native Computing Foundation (CNCF) und dem Investitionsunternehmen Redpoint Ventures4 gegründet [Cnc18]. Im Serverless-Bereich wurden die vier Anwendungsmodelle Tools, Security, Framework und Platform festgelegt. Plattformen sind unterteilt in gehostete und installierbare Serverless-Plattformen. Die meisten installierbaren Plattformen sind Open Source. AWS Lambda, Google Cloud Functions (GCF) und Azure Functions sind gehostete Plattformen, während OpenFaaS5 und Fission6 installierbare Open Source Plattformen sind. Im kommenden Kapitel wird CI/CD als wichtiger DevOps-Prozess für Cloud-native Anwendungen eingeführt. Es werden zuerst die Grundlagen von CI/CD und anschließend im Kontext von Serverless bzw. FaaS Anwendungen erläutert.

2.2. Continuous Delivery für Serverless Anwendungen

Wie bereits in 2.1.5 erwähnt, können Serverless Anwendungen ziemlich komplex werden. Die Komplexität steigt vor allem im Deployment, wenn man an Deployment-Skripte, Konfigurations- management und Infrastruktur denkt. Auch das Serverless Framework deckt hier nicht alles ab [Zimb]. Daher ist CI/CD ein wichtiges Konzept, das für FaaS Anwendungen angewendet werden sollte. Jedoch führt dies zu einem Vendor Lock-in (auch Lock-in-Effekt). In Diesem Kapitel wird zunächst grundlegendes Verständnis von CI/CD übermittelt und der Bezug von CI/CD zu FaaS erklärt. Abschließend wird der Vendor Lock-in näher erläutert. Dieses Problem ist die Grundlage der Recherche.

2.2.1. Einführung in Continuous Delivery

Das Testen und Deployment in komplexen Umgebungen mit Servern und weiteren Schnittstel- len zu externen Systemen kann zeitaufwendig und komplex sein [HRN06]. Automatisierung des Softwareentwicklungsprozesses ist der Schlüssel für zuverlässige und schnelle Auslieferung von Software. Hierbei entstehen qualitativ hochwertigere Software und kürzere Release-Zyklen, was den Markteinstieg beschleunigt [LKO15]. Das automatische Erstellen, Testen und Deployen bei Codeänderungen durch eine Reihe von Verfahren und Tools wird als Continuous Delivery bezeichnet [DMB18][Eri18]. Cloud-native Architekturen wie Microservices durch CaaS oder Serverless mit FaaS sind ideal geeignet für DevOps Konzepte wie CI/CD. Im weiteren Verlauf des Kapitels und

4Redpoint Ventures: https://www.redpoint.com/ 5OpenFaaS: https://github.com/openfaas/faas 6Fission: https://github.com/fission/fission

26 2.2. Continuous Delivery für Serverless Anwendungen

Pipeline Start Pipeline End

Pre-Commit Automated Deploy to Deploy to Commit Changes Build & Unit Tests Tests Acceptance Tests Staging Production

CONTINUOUS INTEGRATION

CONTINUOUS DELIVERY

CONTINUOUS DEPLOYMENT

Abbildung 2.4.: Allgemeine Continuous Delivery Pipeline der Arbeit wird Continuous Delivery bezüglich Serverless Anwendungen und FaaS betrachtet. Das Manifest für die Implementierung von CI/CD ist die DP [HF10]. In Abbildung 2.4 werden die Phasen einer DP dargestellt. Im DevOps Umfeld wird zwischen drei Automatisierungsgraden unterschieden:

Continuous Integration beschreibt das automatische Erstellen, Testen und Bereitstellen in einer Integrationsumgebung. Es dient in erster Linie dazu, die Vorbereitung eines Releases zu erleichtern [HF10].

Continuous Delivery erweitert Continuous Integration, indem es den Release-Prozess ebenfalls automatisiert. Hierbei ist das Deployment in die Ausführung von Akzeptanztests und das Deployment an die Staging Umgebung gemeint. Das Deployment in die Produktivumgebung wird manuell ausgelöst.

Continuous Deployment ist die voll automatisierte Pipeline von der Versionskontrolle bis zum Anwender und braucht keine manuelle Genehmigung mehr für das Deployment ins Produk- tivsystem [HF10].

Die allgemeine DP enthält folgende Schritte:

Pre-Commit (Optional) Diese Phase wird in lokalen Umgebungen durchgeführt, z. B. auf dem Computer von Entwicklern. Externe Systeme werden durch Stubs und Mocking-Objekte ersetzt. Die Erstellung von Mock-Services ist daher Voraussetzung für das Software-Engineering. Weiterhin werden nur begrenzte und schreibgeschützte externe Systeme zum Testen verwendet. Bis der Check-in die Commit-Tests kompiliert und bestanden hat, sollten Entwickler keine neue Aufgabe starten [HF10].

27 2. Grundlagen

Commit Erst wenn die Commit-Tests erfolgreich sind, ist das System bereit, die Änderungen in das Versionskontrollsystem zu übertragen [HF10].

Build & Unit Tests Ab hier beginnt dann die Automatisierung durch CI-Systeme wie Jenkins7 oder Travis CI. In dieser Phase wird der Quellcode kompiliert und Unit Tests durchgeführt. Anschließend wird die Komponente gebaut und in ein VM-Image oder Container gepackt, der anschließend nicht mehr geändert wird.

Deployment in Staging Umgebung Je nach Umgebung werden Integrationstests durchgeführt und dann in der Staging-Umgebung bereitgestellt. Diese Staging-Umgebung soll so gut es geht der Produktivumgebung ähneln.

Automatisierte Akzeptanztests In dieser Phase werden bestimmte Akzeptanztests wie Last- oder Stresstests mit Tools wie JMeter durchgeführt.

Deployment zu Produktiv Umgebung Sobald alle Tests erfolgreich sind, kann die Bereitstellung der Software ins Produktivsystem angestoßen werden.

2.2.2. Continuous Delivery und Function-as-a-Service

Warum ist CI/CD so wichtig in FaaS Anwendungen? Wie bereits angemerkt, ist FaaS cloud-nativ. Funktionen sind die Einheit für Deployment und Skalierung. Die Annahme ist verlockend, dass ohne Bedenken an Infrastruktur FaaS Anwendungen entwickelt und bereitgestellt werden können. Jedoch bekommt die Infrastruktur in FaaS eine andere Bedeutung. Das Management von vielen Funktionen und die Definition von weiteren Komponenten Ereignisquellen wie HTTP-Endpunkte oder Messaging-Queues erhöhen die Komplexität der Architektur einer FaaS Anwendung [JY18]. Ebenso werden weitere Cloud-spezifische Services wie der IAM-Berechtigungen, Speicher Amazon S3 oder Amazon DynamoDB genutzt. Die Komplexität steigt in der Konfiguration, Verbindung und Komposition von Funktionen. Das Testen, Debugging wird aufgrund der schnell steigenden Komplexität und hohen Granularität zu einer Herausforderung [SS18][LRLE17]. Um daher automatisiert, zuverlässig und schnell FaaS Anwendungen auszuliefern, sind CI/CD Konzepte wie IaC wichtig [Cnc18][Zimb].

Continuous Delivery in AWS Lambda

AWS bietet eine Reihe von Produkten an, die die Erstellung von Implementierungspipelines erleichtern:

AWS CodePipeline8 ist ein vollständig verwalteter Continuous Delivery Service, mit dem man automatisierte eine DP implementieren kann.

AWS CodeBuild9 ist ein Tool für Continuous Integration und dient zum Erstellen, Testen von Code mit fortlaufender Skalierung.

AWS CodeCommit10 ist ein Service für das Hosten von sicherer und skalierbarer Quellcodekon- trolle.

7https://jenkins.io/

28 2.3. Der Vendor Lock-in und Function-as-a-Service

Listing 2.2 Beispiel einer Funktionsdefinition in AWS SAM - app-spec.yaml 1 AWSTemplateFormatVersion: '2010-09-09' 2 Transform: 'AWS::Serverless-2016-10-31' 3 Description: A starter AWS Lambda function. 4 Parameters: 5 IdentityNameParameter: 6 Type: String 7 Resources: 8 helloworld: 9 Type: 'AWS::Serverless::Function' 10 Properties: 11 Handler: index.handler 12 Runtime: nodejs6.10 13 CodeUri: . 14 Description: A starter AWS Lambda function. 15 MemorySize: 128 16 Timeout: 3 17 Policies: 18 - SESSendBouncePolicy: 19 IdentityName: !Ref IdentityNameParameter

Eine AWS Infrastruktur kann durch AWS CloudFormation11 deklarativ beschrieben werden. Server- less Application Model (SAM)12 baut auf CloudFormation auf und ist ein Open Source-Framework, das zum Erstellen von Serverless Anwendungen verwendet wird. Durch AWS SAM kann mit einfacher Syntax eine Lambda-Funktion, APIs, Berechtigungen, Konfigurationen und Ereignisse beschrieben werden. Somit ist AWS SAM die IaC Lösung für Serverless Anwendungen auf AWS. Ein Beispiel für eine einfache SAM-Definition wird im Quelltext 2.2 dargestellt. Eine DP einer Serverless Anwendung in AWS mit Lambda ist in Abbildung 2.5 zu sehen. Hier werden die einzelnen Phasen dargestellt. Das Beispiel verwendet cloud-spezifischen CI/CD Services. Man kann für die Versionskontrolle aber auch GitHub anknüpfen oder Jenkins als Build-System nutzen. Einige der Cloud-Services wie AWS CloudFormation sind aber notwendig für das Erstellen einer DP in AWS und das produziert wiederum einen Vendor Lock-in. Man ist abhängig von Cloud- spezifischen Tools und Services, wenn man CI/CD betreiben möchte [BCC+17][Rob18][AC17] [SS18][JY18][MPF18]. Das folgende Kapitel 2.3 beschreibt dieses Problem genauer.

2.3. Der Vendor Lock-in und Function-as-a-Service

Die großen Anbieter wie AWS, Azure oder Google Cloud Platform (GCP) nutzen ihre eigenen Tools um CI/CD für FaaS Anwendungen zu betreiben. Die Tabelle 2.1 zeigt cloud-spezifische Features der FaaS Plattformen AWS Lambda, GCF und Azure Functions die vom Vendor Lock-in bzw. Herstellerabhängigkeit bezüglich CI/CD betroffen sind.

11https://aws.amazon.com/de/cloudformation/ 12https://github.com/awslabs/serverless-application-model

29 2. Grundlagen

Features AWS Lambda Google Cloud Func- Azure Functions (1.x tion und 2.x) Infrastructure as Code CloudFormation, Ser- Cloud Deployment Resource Manager (IaC) verless Application Manager Model (SAM) Event Source Support Amazon S3, Amazon HTTP, Cloud Storage, Blob Storage, Cos- DynamoDB, Amazon Cloud Pub/Sub, mos DB, Event Kinesis Data Streams, Cloud Firestore, Grid, Event Hubs, Amazon Simple Firebase (Realtime Externe Datei, Ex- Notification Service, Database, Storage, terne Tabelle, HTTP, Amazon Simple Analytics, Auth), Microsoft Graph, Email Service, Ama- Stackdriver Logging Excel-Tabellen, zon Simple Queue [Plab] Microsoft Graph, Service, Amazon OneDrive-Dateien, Cognito, AWS Cloud- Microsoft Graph, Formation, Amazon Outlook-E-Mail, CloudWatch Logs, Microsoft Graph, Amazon CloudWatch- Ereignis, Microsoft Ereignisse, AWS Graph, Authentifizie- CodeCommit [Serd] rungstoken, Mobile Apps, Notification Hubs, Queue Storage, SendGrid, Service Bus, Tabellenspei- cherung, Zeitgeber, Twilio, Webhooks [Cra] Authentifizierung AWS Account root IAM roles Azure App Service user, IAM user, IAM Authentication roles Unterstützte Sprachen Node.js, Java, C#, Go Node.js, Python C#, JavaScript, F#, und Python [Serc] [Plaa] Java, Python (Ex- perimental: Python, TypeScript, PHP, Batch (.cmd, .bat), Bash, PowerShell) [ggab] Limits Siehe [Serb] Siehe [Plac] Siehe [ggaa] CLI-Tools AWS CLI Azure CLI gcloud

Tabelle 2.1.: Vergleich der Cloud-spezifischen Features von AWS Lambda, Google Cloud Functions und Azure Functions

30 2.3. Der Vendor Lock-in und Function-as-a-Service

IaC app-sam.yaml Source Build DeployTests Beta Gamma Production Deployment

Builds Sync implement git push app-build.zip Lambda function

buildspec.yml AWS CodeDeploy AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodeDeploy AWS CodeDeploy

Business Logic App-src.zip

Lambda Function Lambda Function Lambda Function

CI/CD Pipeline AWS CodePipeline

Abbildung 2.5.: CI/CD Pipeline einer Serverless Anwendung in AWS - Quelle: inspiriert durch ([LB16])

Daraus ist zu erkennen, dass die Anbieter unterschiedliche Sprachen sowie Ereignisquellen für ihre FaaS Implementierungen haben. Die CNCF arbeitet hier bereits an einem Community Projekt CloudEvents13, einer Spezifikation zur Beschreibung von Ereignissen auf eine gemeinsame Weise. Dies könnte zur Interoperabilität zwischen Services und Reduzierung des Vendor Lock-ins von Cloud-Anbietern beitragen ist jedoch noch aktiv in der Entwicklung. Auch bei deklarativer Infra- struktur durch IaC implementieren die Anbieter ihre eigenen Lösungen, nutzen jedoch meistens die Formate YAML Ain’t Markup Language (YAML) oder JavaScript Object Notation (JSON). Der Vendor Lock-in entsteht bei Serverless Anwendungen, da sie stark von der Plattform abhängig sind. Die FaaS Plattformen bieten alles von der Authentifizierung bis zu Konfigurationsmanagement, Ska- lierung und Monitoring. Daher ist die FaaS Anwendung eng an die anderen Services der Plattform gekoppelt [AC17]. Die Grenzen und Einschränkungen der FaaS sind ebenso unterschiedlich in den Plattformen. Aus dem Problem des Lock-in-Effekts lässt sich sagen, dass neue Ansätze, Konzepte und Methoden für anbieterunabhängiges CI/CD im Bereich Serverless Anwendungen notwendig sind. Im nächsten Kapitel 4 wird eine SLR durchgeführt um Probleme, Herausforderungen, Kon- zepte, Methoden, Technologien über DevOps, Serverless und Multi-Cloud zu untersuchen. Die genauen Forschungsfragen werden in Kapitel 4.1.2 eingeführt.

13CloudEvents-Spezifikation: https://cloudevents.io/

3. Verwandte Arbeiten

In diesem Kapitel wird die Master Thesis [Iva18] kurz vorgestellt, die ein ähnliches Problem behandelt und daher als verwandte Arbeit betrachtet wird. Der Author hat bereits deutlich gemacht, dass durch Serverless der Entwickler-Workflow und die Infrastruktur eine andere Bedeutung bekommen. Serverless erfordert eine neue Ansicht auf CI/CD. Das Ergebnis der Arbeit ist eine DevOps-Pipeline für Serverless Anwendungen. Ivanov beschreibt das CALMS-Framework1, welches die Grundprin- zipien von DevOps aufzeigt. Er hat bestehende Technologien für IaC wie Terraform2 oder AWS CloudFormation verglichen und sich daraufhin für das Serverless Framework3 entschieden, die er für seine Implementierung einsetzt. Diese basiert auf Abstraktionen über Cloud-Anbietern und bietet eine schnelle Bereitstellung von Serverless Anwendungen auf unterschiedlichen FaaS-Services wie AWS Lambda oder Azure Functions. Jedoch haben bereits Experten erkannt, dass das Framework den Vendor Lock-in nicht behebt, sondern die Infrastruktur der FaaS Plattformen automatisch und unter der Haube konfiguriert. Die Arbeit hat einen großen Teil im Bereich DevOps bezogen auf Serverless Anwendungen abgedeckt. Sie hat gezeigt, welche Eigenschaften DevOps hat, wie sie auf Serverless Anwendungen einzusetzen sind und welche Vor-/Nachteile dadurch entstehen. Er hat ebenfalls das Vendor Lock-in angesprochen und in seinem Ausblick beschrieben, dass dieses weiterhin ein großes Problem ist. Er hat ein paar Alternativen kurz erwähnt, wodurch das Vendor Lock-in behoben werden könnte und genau an diesem Teil beginnt der Beitrag dieser Arbeit. Diese Masterarbeit wird die Grundlagen von Serverless sowie CI/CD vorstellen und auf das Problem des Vendor Lock-in eingehen. Eine SLR wird detailliertere Untersuchungen von Problemen, Heraus- forderungen sowie Konzepte, Methoden und Technologien untersuchen um CI/CD für Serverless Anwendungen durchzuführen. Weiterhin wird es Methoden und Technologien für das Deployment in Multi-Cloud Umgebungen untersuchen. Der Fokus dieser Arbeit liegt darauf, eine Lösung für anbieterunabhängiges CI/CD in Serverless Anwendungen zu finden. Diese Arbeit stellt ihnen ein Konzept und Prototyp vor um diese Aufgabe zu bewältigen. Durch eine DP und einer Beispielan- wendung wird anschließend gezeigt, wie man CI/CD für Serverless Anwendungen betreiben kann und das Problem des Vendor Lock-in reduziert werden kann.

1CALMS definiert: Culture, Automation, Lean, Measurement und Sharing 2https://www.terraform.io/ 3https://serverless.com/

4. Stand der Technik: Eine Systematische Literaturrecherche

In diesem Kapitel wird die durchgeführte SLR nach den Richtlinien von Kitchenham et al. beschrieben [KBB+09]. Die SLR soll den aktuellen Stand der Technik im Bereich DevOps, Serverless/Function-as-a-Service und Multi-Cloud Deployment untersuchen. Die Recherche besteht aus den drei Phasen: Planung, Durchführung und Ergebnisse der Recherche. Die Planungsphase besteht aus den Forschungsfragen und dem darauf aufbauenden, fundamentalen Review-Protokoll. Ziel der Durchführungsphase ist anhand einer wohldefinierten Suchstrategie so viel relevante Pri- märstudien wie möglich aufgefunden, gefiltert und analysiert. Im letzten Schritt der SLR findet eine Berichterstattung statt. In dieser werden die Ergebnisse der Recherche zusammengetragen, interpretiert und anhand dieser die Beantwortung der Forschungsfragen diskutiert. Zusätzlich, da das Thema Serverless in der Praxis immer mehr an Bedeutung zunimmt, werden Recherchen auf infoQ und medium betrieben, die eine große Menge an begutachteten (Peer-Review) Artikel- und Blogbeiträge von professionellen Software-Ingenieuren, Entwicklern und Autoren enthalten. Vor allem werden hier Erfahrungen, Eigenschaften und Analysen von innovativen, aktuellen Techno- logien und Praktiken aus der Industrie geteilt. Hier sind vor allem gute Einstiegspunkte für das Thema Serverless und DevOps wiederzufinden. Diese ergeben sich jedoch anschließend aus den Ergebnissen der SLR und sind nicht Teil der systematischen Literaturrecherche.

4.1. Planung der Recherche: Das Review-Protokoll

Die Planung der Recherche ist ein wesentlicher Bestandteil der SLR und dient als Leitfaden der Durchführung. Hier werden die Forschungsfragen und das daraus resultierende Review-Protokoll beschrieben.

4.1.1. Hintergrund

Der Hintergrund der systematischen Literaturrecherche ergibt sich aus der Anforderung den Stand der Technik über Konzepte, Best Practices und Technologien für das Continuous Delivery (CD) von Serverless Anwendungen zu überprüfen. Das Thema ist neu und es existieren bereits viele kommerzielle Produkte sowie OpenSource Software, die entwickelt werden. Da sich der Trend des Serverless Paradigmas zukünftig fortführen wird, sollen hier Methoden, Ansätze und Tools verglichen werden. Hierbei liegt der Fokus auf FaaS, bei der Business Services in viele kleine Funktionen unterteilt ist. Die Komplexität für Deployment und Management ist hier deutlich höher und sollte daher in einen Continuous Delivery Prozess integriert werden. Da viele Cloud Anbieter ihre eigenen Lösungen hierfür einsetzen, sollte das Ziel dieser SLR sein, einen Überblick über dieses Themengebiet zu geben.

35 4. Stand der Technik: Eine Systematische Literaturrecherche

4.1.2. Die Forschungsfragen

Die Forschungsfragen bestimmten den wichtigsten Teil der SLR. Aus diesen Fragen werden die Suchstrategie und deren Suchphrasen abgeleitet, die für die Durchführung der Recherche wesentlich sind. Die Forschungsfragen sollen Herausforderungen, Konzepte, Tools und Frameworks bezüglich Continuous Delivery in Serverless/FaaS Anwendungen untersuchen. Folgende vier Forschungsfragen werden für die Recherche verwendet:

FF1 Wie ist der Stand der Technik in DevOps, CI/CD-Ansätzen im Serverless/FaaS Umfeld? Diese Frage soll Entwicklung/Fortschritt des Deployment-Prozesses von FaaS-Anwendungen untersuchen, seit dem der Serverless Begriff erstmals eingeführt wurde.

FF2 Welche Probleme und Herausforderungen existieren im CI/CD von Serverless/FaaS Anwen- dungen? Diese Frage soll auf die Herausforderungen und Probleme eingehen, die das Deployment von FaaS Anwendungen betreffen, da in Serverless Anwendungen der Begriff Infrastruktur eine andere Bedeutung aufnimmt als in herkömmlichen Paradigmen und Artefakte feinkörniger Natur sind.

FF3 Welche Konzepte und Technologien existieren in der Forschung um Continuous Delivery (CD) in Multi-Cloud (anbieterunabhängig) Umgebungen zu betreiben ? Diese Frage dient zur Untersuchung von Ideen, Ansätzen und Lösungen über CI/CD in Multi-Cloud Applikationen.

4.1.3. Die Suchstrategie

Die Suchstrategie definiert eine automatischen Recherche mit strikten Vorgaben. Für die automatische Suche werden Suchphrasen verwendet, die aus den Forschungsfragen abgeleitet sind und die Suchmittel, die in 4.1.3 bestimmt sind. Die Suchstrategie besteht zum einen aus den Suchbegriffen und Suchphrasen, die aus den For- schungsfragen abgeleitet sind. Weiterhin definiert sie die Quellenauswahl wie digitale Bibliotheken und bestimmte Zeitschriften oder anderen wissenschaftlichen Datenbanken. Die Suchstrategie ist deshalb so wichtig, da Leser dieser Recherche diese Suche nachvollziehen können sollen. Sie sollten auf dieselben Suchergebnisse kommen. Es wird für die Strategie eine automatische und manuelle Suche durchgeführt, weil die Wissenschaft und Forschung in diesem Gebiet noch sehr jung ist. Die automatische Suche wird durch Suchphrasen in bestimmten Bibliotheken und Suchmaschinen durchgeführt. Weitere manuelle Recherchen werden während der Arbeit außerhalb der SLR vorge- nommen. Der Mangel an Forschung im Bereich Serverless und DevOps ist der Grund für weitere Recherchen.

Suchmittel

Für die automatische Suche werden die digitalen Bibliotheken ACM Digital Library, IEEE Xplo- re Digital Library und Science Direct verwendet. Diese Quellen werden auch von Kitchenham vorgeschlagen [KBB+09]:

36 4.1. Planung der Recherche: Das Review-Protokoll

Tabelle 4.1.: Suchterme mit Abkürzungen und Synonymen Term Abkürzungen/Synonyme/ähnliche Begriffe „Function-as-a-Service“ FaaS, Serverless „Continuous Delivery“ „CI/CD“, deployment, DevOps concepts methods, approaches, models technologies tools, frameworks, platforms challenges problems, hints, issues multi-cloud cloud-agnostic, cloud-neutral „Deployment Pipeline“ „delivery pipeline“, „DevOps Pipeline“ „Infrastructure as Code“ „infrastructure management“, IaC „configuration management“ configuration

Abbildung 4.1.: Suchphrase (Beispiel)

UND

ODER ODER

Continuous Delivery deployment ODER concept approach method model

Serverless Function as a Service

Suchterme

Aus den Forschungsfragen von 4.1.2 sind die folgenden Suchterme abgeleitet: Function-as-a-Service, Continuous Delivery, concepts, technologies, challenges, multi-cloud, De- ployment Pipeline, Infrastructure as Code, und configuration management. Die Suchterme mit alternativen Schreibweisen sind in der Tabelle 4.1 gelistet.

Suchphrasen

Um die passende Literatur in wissenschaftlichen Datenbanken zu finden, werden durch Kombinatio- nen der Begriffe Suchphrasen abgeleitet. Zur Veranschaulichung einer Suchphrase ist in Abbildung 4.1 ein Beispiel gegeben. Die kompletten Suchphrasen sind im Anhang C einsehbar.x

37 4. Stand der Technik: Eine Systematische Literaturrecherche

Einschluss- und Auschlussskriterien

Um nur relevante Studien für die Recherche aufzunehmen, werden Einschlusskriterien verwendet. Nicht nur die Relevanz sondern auch die Qualität der verwendeten Quellen wird dadurch erhöht. Unnötige, irrelevante Primärstudien werden durch Anwenden von Auschlusskriterien gefiltert. Alle diese Einschlusskriterien müssen erfüllt sein, um ein Suchergebnis als Primärstudie in die SLR aufzunehmen:

EIN1 Es handelt sich um Herausforderungen, Konzepte, Lösungen oder Technologien im Bereich Serverless oder Function as a Service

EIN2 Es handelt sich um Herausforderungen, Konzepte, Lösungen oder Technologien im Deploy- ment von Serverless Anwendungen

EIN3 Es ist nicht älter als 2012 publiziert, da der Begriff Serverless hier entstanden ist. Ausgeschlossen wird eine Studie von der SLR, wenn mindestens eines der folgenden Ausschlusskri- terien erfüllt sind:

AUS1 Eine Studie, die bereits in einer anderen Datenbank gefunden und in die SLR aufgenommen wurde (Duplikat).

AUS2 Eine Studie, die nicht dem Peer-Review-Verfahren unterliegt.

Auswahl der Studien

Die Studien werden zunächst nach den Suchphrasen und dem Zeitraum gefiltert. Dann werden die Ein-/Ausschlusskriterien auf Titel, Abstract und Keyword angewandt. Laut [BKB+07] ist der Standard von IT und Software Engineering Abstracts zu niedrig, sodass die Schlussfolgerungen (Conclusion) zusätzlich untersucht werden sollten. Daher wird dies ebenfalls in den Auswahlprozess aufgenommen.

Extraktion der Quellen

Um die Forschungsfragen beantworten zu können, werden die wichtigen Informationen und Erkennt- nisse aus den Primärstudien extrahiert. Zur systematischen Extraktion wird das in 4.2 verwendete Formular verwendet.

Synthetisieren der Quellen

Um aus den extrahierten Daten Informationen und Erkenntnisse zu gewinnen, werden für Synthe- se der Quellen ebenfalls Formulare erstellt. Das Synthetisieren dient zur Zusammenfassung der Ergebnisse. Pro Forschungsfrage existiert hierfür ein Formular.

38 4.1. Planung der Recherche: Das Review-Protokoll

Tabelle 4.2.: Formular zur Datenextraktion Datenfeld Wert allgemeine Informationen Titel Autor Jahr Typ Seiten Land Serverless & DevOps Probleme und Herausforderungen Konzepte, Methoden, Modelle Technologien, Tools, Plattformen Multi-Cloud & DevOps Probleme und Herausforderungen Konzepte, Methoden, Modelle Technologien, Tools, Plattformen

Tabelle 4.3.: Synthese-Formular für FF1 Serverless/FaaS and CI/CD Konzepte, Methoden, Modelle Anzahl Studien

Technologien, Tools, Plattformen Anzahl Studien

Tabelle 4.4.: Synthese-Formular für FF2 Serverless und CI/CD Probleme/Herausforderun- Anzahl Studien zusätzliche Informationen gen (evtl. Lösungsvorschläge, Alternativen, ...)

Tabelle 4.5.: Synthese-Formular für FF3 Multi-Cloud und CI/CD

Konzepte, Methoden, Modelle Anzahl Studien

Technologien, Tools, Plattformen Anzahl Studien

39 4. Stand der Technik: Eine Systematische Literaturrecherche

4.2. Durchführung der Recherche

Während der Recherche wurde die Suche anhand unterschiedlicher Kombinationen der Suchter- me getestet und das Review-Protokoll immer wieder verfeinert. Hierdurch ist eine Suchstrategie entstanden die in den ausgewählten Datenbanken ähnlich sind, jedoch trotzdem erläutert werden sollten (siehe 4.2.1). Als Werkzeug für die Literaturverwaltung wurde die kostenlose Software Mendeley1 verwendet. Dieses Tool ist leicht zu bedienen und relativ selbsterklärend. Besonders gut an dem Programm ist die Synchronisation zwischen der Desktop-App, dem Browser-Plugin und der Smartphone-App, wodurch die Literatur auf beliebigen Geräten zugreifbar ist. Der Suchstrategie folgend werden die aus der Suche resultierenden Quellen aufgezeigt.

4.2.1. Suchstrategie

Hier wird beschrieben, wie die wissenschaftlichen Datenbanken für die Suche verwendet werden.

ACM Digital Library In ACM Digital Library wurde die erweiterte Suche („Advanced Search“) verwendet. Darunter wurde die Standard-Einstellung „The ACM Full-Text Collection“ aus- gewählt, welche alle Artikel beinhaltet, die jemals von ACM gesponsort oder veröffentlicht wurden, inklusive geprüften und gehosteten Inhalten von ausgewählten Verlagen. Die Such- phrasen wurden durch die Syntax von ACM DL geformt und die Suche wurde durchgeführt.

IEEE Xplore Digital Library In IEEE Xplore Digital Library wurde die „Command Search“ verwendet, um die Suchphrasen wieder so einfach wie möglich nutzen zu können. Als Suchoption wurde die Standard-Einstellung „Metadaten Only“ gewählt, um nur in Titel, Zusammenfas- sung und Schlüsselwörter zu suchen. Die Suchphrasen wurden durch die Syntax von IEEE Xplore Digital Library durch „AND“ und „OR“Verknüpfungen eingesetzt und die Suche wurde durchgeführt.

ScienceDirect In ScienceDirect wurde die erweiterte Suche („Advanced Search“) und die „tak“- Option (Title, Abstract, Keywords) verwendet.

Der Begriff Serverless wurde 2012 zum ersten Mal im Artikel von Ken Fromm[Fro12] erwähnt. Daher wurde in allen Bibliotheken nur Studien ab 2012 bis zum Zeitpunkt dieser Arbeit (2019) miteinbezogen.

4.2.2. Dokumentation der Recherche

Die SLR-Ergebnisse sind im Schaubild 4.2 hervorgehoben: ACM Digital Library lieferte von 44 Studien insgesamt 15, IEEE Xplore Digital Library von 106 Studien 25 und ScienceDirect lieferte nur 1 von 28 relevante Studien. In der Tabelle 4.6 werden die resultierenden Studien aufgezählt, die in den weiteren Prozess der SLR integriert sind. Die Ergebnisse der Studien werden dann anhand der im Protokoll definierten Datenextraktions- und Datensyntheseformulare 4.2 bis 4.5 gesammelt.

1https://www.mendeley.com

40 4.2. Durchführung der Recherche

SLR-Ergebnisse 90 80 80 70 60 50 40 29 27 30 26 20 15 10 1 0 ACM Digital Library IEEE Xplore Digital ScienceDirect Library

ausgeschlossen relevant

Abbildung 4.2.: SLR Ergebnisse

Tabelle 4.6.: Die SLR-Studien nach Quelle Quelle Studien ACM DL [AC17], [SJ17], [FCSS15], [DMB18], [FSR+14], [FCS+18], [BGK+13], [FCR+13], [GCGA15], [VJ14], [AKC+15], [Ren16], [BIS+14], [SZD+15], [Elg15] IEEE Xplore [MJB+17], [MB17], [SS18], [JY18], [MPF18], [LRLE17], [HB13], [PM13], [FRC+13], [CFN+14], [PTD+15b], [CDR+17], [PTD+15a], [BPR16], [BSG+18], [SIV17], [PMM15], [GG18], [YG16], [EBM16], [DAFP15], [ALKH17], [TPM+17], [PLB+17], [PICP16], [PRS17] ScienceDirect [MGZ+17]

41 4. Stand der Technik: Eine Systematische Literaturrecherche

Im folgenden Kapitel 4.3 werden die Informationen und Erkenntnisse der Durchführung in Ergebnis- sen veranschaulicht und interpretiert. Darüber hinaus werden die Forschungsfragen beantwortet.

4.3. Ergebnisse der Recherche

In diesem Abschnitt werden die Ergebnisse der SLR dargestellt und diskutiert. Die Aggregati- on dieser Resultate soll dann die Forschungsfragen aus 4.1.2 beantworten. Zunächst werden die Herausforderungen und Probleme von Serverless/FaaSUmgebungen diskutiert, aktuelle Konzepte, Technologien bezüglich CI/CD in diesem Umfeld zusammengefasst und anschließend über Metho- den, Modelle und Technologien in Multi-Cloud Umgebungen berichtet. Zum Schluss wird noch ein Fazit über die SLR-Ergebnisse gegeben und der Übergang zum Konzept der Arbeit eingeleitet.

4.3.1. Ergebnis für die FF1: Welche Probleme und Herausforderungen existieren im CI/CD von Serverless/FaaS Anwendungen?

Die Recherche bestätigt bereits, dass das größte Problem mit CI/CD und FaaS der Vendor-Lock-in ist. An zweiter Stelle folgt hier der Mangel an Tools, was stark mit dem Vendor Lock-in zusammenhängt. Jeder Cloud-Anbieter hat eigene Implementierungen für spezifische Services wie Authentifizierung, Konfigurationsmanagement oder Speicher. Das erfordert bei der Portierung zu einem anderen An- bieter zur erneuter Arbeit und Aktualisierung von betrieblichen Tools wie Deployment, Monitoring oder Debugging. Adzic und Chatley meinen, dass wegen der engen Bindung an den Anbieter in der Praxis die Anwendung eine signifikante Neuentwicklung bedeuten würde [AC17]. Die Entwickler sind somit abhängig an den Hersteller für Deployment-Tools. Ebenso ist zu erwähnen, dass das lokale Testen sowie Integrationstests schwierig und aufwendig sind, aufgrund von feinkörniger Natur der Funktionen [AC17][JY18][SS18][SJ17][LRLE17]. Zudem können Sie nicht eine ganze Lambda-Umgebung von AWS lokal simulieren, was lokales Testen schwierig macht [JY18]. Jeder FaaS-Anbieter bietet unterschiedliche Laufzeiten, Sprachen und cloud-spezifische Tools an. Tools wie Apex2 oder Sparta3 sollen dabei, helfen Lambda Funktionen mit Sprachen wie Go4(die nicht nativ von AWS unterstützt werden) bereitzustellen. Weiterhin wird auf die Inkompatibilität der Ereignisse mit traditionellen Tools und Frameworks wie das Serverless Framework verwiesen. Es seien neue Paradigmen von Software-Konstruktion nötig, um dieses Problem zu beheben [MJB+17]. Fazit ist, dass Probleme und Herausforderungen in den Abhängigkeiten der spezifischen Sprachen, Tools und Frameworks der Anbieter liegen. Weiterhin sind das lokale Testen und Zusammensetzen von Funktionen aufgrund der Abhängigkeit zur Cloud ein Problem für CI/CD.

2https://github.com/apex/apex 3Serverless Go Microservices für AWS: https://gosparta.io/ 4Die Programmiersprache Go: https://golang.org/

42 4.3. Ergebnisse der Recherche

Probleme, Herausforderungen CI/CD in Serverless/FaaS

5% 5% 21%

32%

21%

16%

Vendor Lock-in lokales Testen/Integrationstests, Debugging Support von Laufzeit/Sprachen für Orchestrierung von Funktionen Tool-Mangel für Deployment Komposition von Funktionen Wiederherstellungssemantiken

Abbildung 4.3.: Probleme/Herausforderungen im CI/CD in Serverless/FaaS

4.3.2. Ergebnis für die FF2: Wie ist der Stand der Technik in DevOps, CI/CD im Serverless/FaaS Umfeld?

Die SLR hat ergeben, dass proprietäre Monitoring-Tools wie AWS CloudWatch verwendet werden, um beispielsweise Log-Management zu betreiben [LRLE17]. Jedoch produzieren solche Cloud- spezifischen Lösungen einen Vendor Lock-in. Abstraktionen über der Cloud, Ereignisse durch Frameworks wie das Serverless Framework5 oder PyWren6 sollen helfen, diese Abhängigkeiten zu reduzieren [AC17][MJB+17][SJ17]. Versionierung soll in DevOps-Umgebungen aushelfen, wenn ein Mechanismus zur Wiederherstellung von funktionierenden Versionen der Anwendung sichergestellt werden muss. In FaaS-Umgebungen ist es bedeutend wichtiger, da die Komplexität im Debugging und Monitoring von Ereignissen oder Funktionen erheblich steigen kann. Cloud-Anbieter bieten hier spezifische BaaS Services Tools um Rollbacks auf frühere Versionen durchzuführen. Wie behebe ich aber den Vendor Lock-in, der in FaaS-Anwendungen entsteht? In 4.4 und 4.5 ist zu erkennen, dass in Container- sowie Container-Orchestrierung-Technologien deutlich ak- tiver geforscht wird, als mit proprietären Lösungen zu experimentieren. Die Recherche zeigt, dass Containierisierung und Container-Orchestrierung optimal für Continuous Delivery von FaaS-

5https://serverless.com/ 6http://pywren.io/

43 4. Stand der Technik: Eine Systematische Literaturrecherche

Konzepte, Methoden, Modelle CI/CD in Serverless/FaaS 9 8 7 6 5 4 3 2 1 0

Container Abstraktion Monitoring Versionierung

Container-Orchestrierung

Abbildung 4.4.: Konzepte für CI/CD in Serverless/FaaS

Anwendungen sind. Einerseits sind Funktionen in Container verpackt „überall“7 ausführbar, vor- ausgesetzt es laufen Container-Laufzeitumgebungen wie die Docker Engine 8. Weiterhin kann durch Container-Orchestrierung mit Kubernetes (K8s) und Container-Registries wie Docker Hub9) Versionierung, Komposition, Steuerung und Verfügbarkeit von Serverless Funktionen gewährleis- tet werden [JSS+19][MPF18]. Diese Vorteile existieren nicht in propriertären Cloud-Services wie AWS Lambda, Azure Functions oder Google Cloud Functions, zwecks Vendor Lock-in. Die Umgebungen und Abhängigkeiten dieser Produkte erzwingen den Nutzer, die Einschränkungen zu akzeptieren. OpenSource-Produkte wie OpenFaaS oder Fission geben Beispiele für Container- native Laufzeitumgebungen, in denen K8s oder Docker Swarm verwendet werden, um Funktionen von diesen Anbietern unter der Haube als Container zu verpacken und orchestrieren. K8s kann auf jeder virtuellen Maschine eines Cloud-Anbieters betrieben werden, und wird heutzutage als Cloud-Dienst von vielen Anbietern angeboten (Google Kubernetes Engine (GKE), AWS Elastic Kubernetes Service (EKS)). Selbstgehostete K8s-native FaaS Services eignen sich daher gut für anbieterunabhängiges CI/CD [JY18]. Die wesentlichen Eigenschaften und Vorteile von K8s werden in Kapitel 7 eingeführt.

7Docker basiert auf Linux-Technologien wie Cgroups und Namespaces. Es ist auf Linux ausgerichtet, funktioniert aber mit einem Hypervisor wie Hyper-V oder VirtualBox auch auf Windows und OS X. 8https://docs.docker.com/engine/ 9https://hub.docker.com/

44 4.3. Ergebnisse der Recherche

Technologien, Tools, Plattformen CI/CD in Serverless/FaaS 10 9 8 7 6 5 4 3 2 1 0 OpenWhisk, Kubernetes, Serverless AWS VCS: GitHub, OpenFaaS, … Docker Swarm, Framework CloudFormation BitBucket, Visual Mesos, … Studio Team

Abbildung 4.5.: Technologien für CI/CD in Serverless/FaaS

4.3.3. Ergebnis für die FF3: Welche Konzepte und Technologien existieren in der Forschung um Continuous Delivery (CD) in Multi-Cloud Umgebungen zu betreiben ?

Die Literatur zeigt, dass die Mehrheit der Forscher mit dem Model-Driven Engineering (MDE) und OASIS Standard Topology and Orchestration Specification for Cloud Applications (TOSCA) arbeitet. In diesem Bereich existieren OpenSource Projekte wie das PaaSage10, dem CloudMF-Framework oder OpenTOSCA11 Ökosystem, das vom Institut für Architektur von Anwendungssystemen (IAAS) der Universität Stuttgart entwickelt wird [FCS+18][PMM15] . Weiter zeigt die Recherche, dass IaC und Konfigurationsmanagement Tools wie Chef12 oder Puppet13 für die Automatisierung im Deployment verwendet werden [YG16]. In Kapitel 5 wird ein universelles IaC- und Orchestrierungs- Tool vorgestellt, mit der deklarativ Infrastruktur definiert und bereitgestellt wird. Die am häufigsten verwendeten Formate für IaC sind JSON, XML und YAML. Auch im später vorgestellten Prototyp in Kapitel 7 wird eines dieser Formate verwendet. Abstraktions-Tools wie jClouds14, ein Java- basiertes Multi-Cloud Toolkit, das mit vielen Cloud-Anbietern zusammenarbeitet, bietet Portabilität zwischen verschiedenen Clouds [VJ14]. Als direkte Nachfolger folgen laut Statistik Container-

10PaaSage Projekt: https://paasage.ercim.eu 11OpenTOSCA: https://www.opentosca.org/ 12Chef: https://www.chef.io/ 13Puppet: https://puppet.com 14Apache jClouds: https://jclouds.apache.org/

45 4. Stand der Technik: Eine Systematische Literaturrecherche

Konzepte, Methoden, Modelle CI/CD in Multi-Cloud 16 14

6 4 2

Microservices Cloud-Broker Service Discovery

KonfigurationsmanagementInfrastructure-as-Code (IaC) Domain Specific Language (DSL) abstrakte Dar stellung des Systems Containerisierung und Orchestrierung

modell-basierte Sprachen, MDE, models@runtime

Abbildung 4.6.: Konzepte für CI/CD in Multi-Cloud

Technologien wie Docker und Orchestrierungsframeworks wie K8s. Eine Case-Study [FCSS15] zeigt, dass durch Containerisierung, IaC und Orchestrierung die Geschwindigkeit/Häufigkeit der Build-Prozesse um das mehrfache hundertfache bis zu tausendfache gestiegen ist. Weiter wird gesagt, dass Microservices mit Container-Technologien die DevOps-Prinzipien, insbesondere den CI/CD-Prozess unterstützen [JY18][PRS17].

4.4. Fazit der SLR

Der Stand der Technik im Bereich CI/CD, Serverless/FaaS und Multi-Cloud zeigt, dass die größten Probleme im Vendor-Lock-in und dem Mangel an Tooling sind. Abstraktionen über der Cloud durch Infrastruktur-Tooling wie das Serverless Framework oder Terraform reichen alleine nicht aus, um der Abhängigkeit von FaaS Anwendungen zu entkommen. Weiterhin erschließt sich aus der SLR, dass sich Serverless/FaaS in Richtung Container-Orchestrierung bewegt. Open Source Produkte wie OpenFaaS oder bestätigen diese These. Obwohl die Multi-Cloud Recherche noch von MDE und dem TOSCA-Standard dominiert wurde, sind IaC Konzepte wie deklarative Infrastruktur, Container-Technologien und Orchestrierungen so wie Abstraktionen über der Cloud in der Serverless Domäne weit verbreitet. Weitere Recherchen bestätigten, dass K8s-basierte FaaS-Lösungen für eine anbieterunabhängige CI/CD Lösung geeignet sind. Im Serverless-Bereich, FaaS und CI/CD ist in diesem Kontext die Open Source Community aktuell aktiv beteiligt, innovative Produkte auf den

46 4.4. Fazit der SLR

Technologien, Tools, Plattformen CI/CD in Multi-Cloud 18 16 14

12 10 8 6

4 2 0

REST Roboconf

AWS CodeDeploy CloudML, CloudMF

Formate wie JSON, XML, YAML Docker, Docker Compose, AWS ECS

Kubernetes, Docker Swarm, Apache Mesos

TOSCA basierte Technologien (Cloudify,Abstraktions-Tools BPEL, ...) (Apache jClouds, Delta-Cloud,…

IaC-Tools wie Chef, Puppet, Juju, AWS Cloud-Formation,…

Abbildung 4.7.: Technologien für CI/CD in Multi-Cloud

Markt zu bringen. Jedoch ist noch großer Bedarf an wissenschaftlicher Forschung. Ebenso macht sich der Mangel an Standards im Bereich FaaS bemerkbar, da das Gebiet noch sehr jung ist. Im kommenden Kapitel wird zum Konzept der Arbeit übergeleitet.

5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen

Das Konzept der Arbeit baut auf den Ergebnissen der SLR und weiteren Recherchen auf. Eine Alternative für eine DP existiert aus der verwandten Arbeit [Iva18], (siehe Kapitel 3). Ivanov verwendet in der Implementierung seiner Arbeit das Serverless Framework, um eine DevOps- Pipeline für Serverless Anwendungen umzusetzen. Die SLR hat gezeigt, dass in dieser Lösung der Vendor Lock-in weiter besteht, da das Framework auf Cloud-Anbieter beschränkt ist und der Vendor Lock-in weitergegeben wird. Trotzdem kann diese Lösung als Alternative für einige Anwendungsfälle angesehen werden. Für ein anbieterunabhängiges CI/CD sollten jedoch Herstellerabhängigkeiten reduziert werden. Hier hat die SLR gezeigt, dass Container-Orchestrierung die Lösung für cloud- natives Multi-Cloud Serverless ist. Dadurch kann eine anbieterunabhängige CI/CD entwickelt werden. Dieses Kapitel führt zunächst einen Pseudo-Algorithmus ein, der versucht auf Basis der Geschäftsanforderungen der Serverless Anwendung das geeignete IaC Modell zu finden. Es werden zwei Modelle vorgestellt, die für eine DP in Serverless Anwendungen verwendet werden können. Anschließend wird das eigene Konzept der Arbeit vorgestellt.

5.1. Infrastructure-as-Code für Serverless Anwendungen

Solange noch keine Serverless Standards für Workflows, Ereignisquellen oder Laufzeiten existieren (siehe CNCF Serverless WG1, kann je nach Geschäftsanforderung unterschiedliche IaC Tools zur Auswahl stehen. Das Konzept der Arbeit beginnt mit einem vorgeschlagenen Algorithmus 5.1, der das optimale IaC Werkzeug sucht, um eine Serverless Infrastruktur anbieterunabhängig aufzubauen. Der Algorithmus nutzt die Geschäftsanforderungen als Input, welches folgendes beschreiben kann:

• Sprachen und Laufzeiten, die von der Serverless Anwendung verwendet werden • unterschiedliche Ereignisquellen die konsumiert werden • Multi-Stage Deployments • Komposition von Funktionen • Monitoring, Versionierung und Debugging Tooling Anforderungen • Security, Authentifizierung und weiter Anforderungen

1https://github.com/cncf/wg-serverless

49 5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen

Algorithmus 5.1 Selection Algorithmn for IaC Tooling and Pattern procedure Select-IaC-Algorithm(business-needs) while serverless standards not exist do if container-orchestration-based FaaS platforms supports business-needs then choose the most suitable FaaS platform use GitOps to do Continuous Delivery else if serverless-framework supports business-needs then use serverless framework else if multi-cloud IaC tool supports businees needs then use multi-cloud IaC tool else implement abstractions tooling or use vendor-specific IaC tool end if end while end procedure

Der Algorithmus läuft, solange es noch keine Serverless Standards existieren und versucht zuerst auf Basis von Containern und Container-Orchestrierung FaaS plattformen zu finden. Dadurch kann die deklarative Infrastruktur und weiteren Vorteilen eine Multi-Cloud und On-Prem Lösung entwickelt werden. Das GitOps Pattern wird in diesem Rahmen als Methode für CI/CD verwendet. Dieses Muster wird in den folgenden Kapiteln des Konzepts und Implementierung der Arbeit noch genauer vorgestellt. Wenn es keine Plattform gibt, welche die Anforderungen erhält, dann wird geprüft, ob ein abstrahierendes Serverless Framework und weitere Tools die Anforderungen erfüllen können. Falls das nicht der Fall ist, dann wird ein Multi-Cloud Orchestrations Tool wie Terraform geprüft, ob es zu den Geschäftsanforderungen passt. Zuletzt bleibt nur noch als Lösung eigene Abstraktionen zu schreiben oder den cloud-spezifische Dienst als IaC Tool zu nutzen. Die While-Schleife besagt, dass sich Entscheidungen, Strategien, Tools und Frameworks noch in Zukunft ändern werden, wenn Serverless Standards entwickelt und reif sind. Vermutlich müsste der Pseudo-Algorithmus dann angepasst werden. Aus den Ergebnissen in 4.3.2 und weiteren Recherchen sind Abstraktionen von FaaS Produkten eine Möglichkeit, um Serverless Produkte auf unterschiedlichen Plattformen bereitzustellen. Die verwandte Arbeit aus 3 nutzt das Serverless Framework um eine DP für Serverless Anwendungen zu entwickeln. Obwohl das Framework sich selbst als „cloud-agnostisch“ bezeichnet, wurde nach näherer Betrachtung deutlich, dass dies nicht ganz der Fall ist. Ivanov hat in seiner Arbeit bereits einen Vergleich von IaC Tools gezeigt, darunter das Serverless Framework, Terraform, Apex und SAM. Apex und SAM sind lediglich auf AWS ausgelegt. Daher kommt für eine allgemeine CI/CD Lösung nur die zwei Produkte Serverless Framework und Terraform als IaC in Frage. Ein kurzer Vergleich der beiden Tools:

Serverless Framework Das Serverless Framework ist speziell für die erleichterte Entwicklung und Bereitstellung von Serverless Anwendungen. Es übernimmt Aufgaben wie das Deployment, einschließlich Berechtigungen, Ereignisabonnements, Protokollierung und Weiteres [Sera]. Es beschreibt Anwendungen deklarativ durch eine serverless.yml Datei. Ein Beispiel solch einer IaC Datei zeigt 5.1. Eine allgemeine DP durch Nutzung des Frameworks wird in 5.1 dargestellt. Neben der Definition von Serverless Funktionen auch BaaS-Services wie eine

50 5.2. Alternatives Konzept: Abstraktionen durch Serverless Framework und Tools

AWS DynamoDB Datenbank oder eine Messaging Queue durch Amazon Simple Queue Service (SQS)2 integriert werden. Jedoch behebt das Framework den Vendor Lock-in der gehosteten FaaS Anbieter nicht, sondern abstrahiert die gemeinsamen Nenner, übernimmt Boilerplate3 Code und schränkt die Flexibilität des Nutzers ein, sobald der Nutzer Services definieren oder nutzen möchte, die nicht vom Framework angeboten werden. Der Vendor Lock-in wird außerdem nicht behoben, da man Anwendungen oder Funktionen in Multi- Cloud Deployments wahrscheinlich umschreiben muss, da die FaaS Anbieter unterschiedliche Einschränkungen und Services nutzen, sodass sich die Anwendung unterschiedlich verhält.

Terraform Terraform ist ein allgemeines IaC Tool zum sicheren, effizienten Erstellen, Ändern und Versionieren von Infrastrukturen. Terraform kann sowohl bestehende als auch beliebte Dienstanbieter sowie kundenspezifische Inhouse-Lösungen verwalten. Eine Infrastruktur beschreibt man in Terraform mit einer übergeordneten JSON basierten Konfigurationssyntax. Man definiert die gewünschten Ressourcen und Terraform bringt die Infrastruktur in diesen Zustand. Auf diese Weise kann ein Blueprint Ihres Rechenzentrums versioniert und wie jeder andere Code behandelt werden [Has17]. Der große Vorteil von so einem Tool ist, dass man cloudunabhängig ist. Dadurch kann man mehrere Anbieter sowie Services zusammenstellen und orchestrieren. Das Gute bezüglich DevOps und CI/CD ist, dass man nur ein IaC Tool benötigen würde, um eine Multi-Cloud Serverless Infrastruktur aufzubauen. Das Problem ist dennoch das Vendor Lock-in. Für jeden Cloud-Anbieter einer FaaS Plattform muss man dennoch die abhängigen Services für eine Serverless Anwendung mit Terraform selbst konfigurieren. Einige Extras wie paralleles Erstellen und Ändern von nicht abhängigen Ressourcen durch das Resource Graph Feature sind ein Plus für solche Tools wie Terraform. Der größte Nutzen von Terraform ist, dass man nicht mehr auf cloud-spezifische IaC Tools wie AWS CloudFormation, Google Deployment Manager oder Azure Resource Manager angewiesen ist. Man könnte die Infrastruktur in der automatisierten DP durch ein IaC Tool steuern.

5.2. Alternatives Konzept: Abstraktionen durch Serverless Framework und Tools

Die Nutzung des Serverless Framework für die Implementierung einer DevOps Pipeline wird ausführlich in der referenzierten Arbeit [Iva18] beschrieben. Dennoch soll dieser Abschnitt eine Möglichkeit aufzeigen, wie eine DP mit dem Framework funktioniert. Die Pipeline ist ganz einfach:

1. Der Entwickler implementiert die Serverless Anwendung anhand des App-Codes und einer serverless.yml Datei, die als IaC verwendet wird. Er schiebt seine Codeänderungen in ein Repository (Git, SVN, CVS). 2. Das Repository triggert die Pipeline durch ein CI/CD-Tool wie Jenkins4.

2https://aws.amazon.com/sqs/ 3Boilerplate bezeichnet meist gleichbleibenden Code, die an vielen Stellen in mehr oder weniger unveränderter Form benötigt werden. 4https://jenkins.io/

51 5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen

3. Installation des Serverless Framework Kommandozeilen-Tools (CLI) und die Abhängigkeiten wie Sprachbibliotheken 4. Build-Prozess durch Package CLI Befehl 5. Durchführung von Unit-Tests 6. Deployment in die Staging-Umgebung, eventuell Integrations-Tests durch Invoke CLI-Befehl 7. manuelles Deployment in die Produktivumgebung durch Pull-Request/Master-Branch

Das Serverless Framework bietet folgende Vorteile bezüglich des CI/CD-Prozesses:

Abstraktion Das Serverless Framework abstrahiert die wichtigsten Elemente beim Erstellen einer Anwendung ab, sodass Entwickler die Möglichkeit haben, den ganzen Tag mit dem Program- mieren zu verbringen [Sera]. Dadurch ist mit wenig Code bereits schnell eine Anwendung bereitgestellt und kann in die Pipeline durch ein paar Zeilen Code integriert werden.

Cloud-Agnostisch Durch Abstraktionen versucht das Framework cloud-agnostisch zu sein, indem es Cloud-Anbieter-Einstellungen unter der Haube5 konfiguriert. Dadurch können in einer Pipeline Serverless Funktionen in unterschiedlichen Regionen mit mehreren Cloud-Anbietern bereitgestellt werden.

IaC + Deployment Das Framework ist eine „All-in-One“-Lösung, mit der man Infrastruktur beschreiben und Serverless Anwendungen bereitstellen kann. Die CLI bietet eine einfache Nutzung für das Deployment.

Neben den Vorteilen gibt es entscheidende Nachteile, weshalb CI/CD mit dieser Lösung lediglich als Alternative steht:

Vendor Lock-in Das Serverless Framework abstrahiert FaaS Angebote von Cloud-Providern und eine einfache High-Level Art wie man Serverless Anwendungen schreibt und bereitstellt. Jedoch ist man abhängig davon, welche Provider das Framework bereitstellt. Darüber hinaus verwendet das Framework IaC Tools wie AWS CloudFormation unter der Haube, sodass man wiederum abhängig vom Cloud-Anbieter.

Einschränkung Das Framework schränkt den Nutzer ein, in dem es Cloud-Anbieter vorgibt, die es unterstützt. Bei der Migration aus strategischen Gründen zu einem Cloud-Anbieter, der nicht vom Framework angeboten wird, hat man ein Problem. Da muss man manuelles Tooling betreiben oder Plugins schreiben, um eine weiter funktionsfähige anbieterunabhängige CI/CD Pipeline zu erhalten.

5Automatische Konfiguration auf Basis der ausgewählten Programmiersprache und Cloud-Anbieter

52 5.2. Alternatives Konzept: Abstraktionen durch Serverless Framework und Tools

Listing 5.1 Beispiel einer Funktionsdefinition mit Serverless Framework - serverless.yml 1 # serverless.yml 2 3 # The `service` block is the name of the service 4 service: simple-service-cicd 5 6 # The `provider` block defines where your service will be deployed 7 provider: 8 name: aws 9 stage: dev 10 region: eu-west-1 11 runtime: python2.7 12 13 # The `functions` block defines what code to deploy 14 functions: 15 simpleService: 16 handler: handler.simpleService 17 18 events: 19 - http: 20 path: simple-service 21 method: get 22 cors: true

Event functons Sources

commit trigger install CLI & implement build artefacts run unit tests deploy to dev deploy to prod dependencies

Repository Actor sudo npm i -g serverless serverless package sls deploy --stage dev sls deploy --stage prod Code serverless.yml # install dependencies

Source CI/CD Pipeline

Abbildung 5.1.: Allgemeine Deployment-Pipeline mit dem Serverless Framework Quelle: Eigene Darstellungs

5.2.1. Fazit der Alternative

Das Serverless Framework ist eine gut konzipierte Lösung für die meisten Anwender, da Sie die proprietären Serverless Produkte der Marktführer wie AWS, Azure oder GCP unterstützt. Das Serverless Framework hilft in bestimmten Anwendungsfällen, wenn die Geschäftsanforderungen des Nutzers übereinstimmen. Wenn die Vorteile des Frameworks durch einfach gehaltenen, abstrakten Code nutzvoll für den Nutzer ist, kann das Serverless Framework in Frage kommen. Jedoch verliert das Framework an Wert, sobald es sich um eine anbieterunabhängige, flexible DP und das schnelle Migrieren von Serverless Anwendungen in andere Umgebungen handelt. Es existieren nun bereits mehrere Open Source Produkte, die unterschiedliche Features haben und Ihren Mehrwert haben. Ein Framework aufzublähen und alle FaaS Funktionalitäten zu integrieren wird Ihre Leichtgewichtigkeit verlieren und nicht mehr wartbar sein. Zudem bietet es keine On-Prem Lösung, es gibt jedoch Mocking-Möglichkeiten und Lokale Tests, die man verwenden kann. Fazit lautet, wenn Geschäfts- anforderungen des Nutzers mit Betracht auf Vor- und Nachteile im CI/CD Prozess vernachlässigt werden können, ist ein Framework wie das Serverless Framework eine gute Alternative.

53 5. Alternative Konzepte für Continuous Delivery von Serverless Anwendungen

Listing 5.2 Beispiel einer Funktionsdefinition mit dem Terraform Tool -lambda.tf 1 provider "aws" { 2 region = "eu-west-1" 3 } 4 5 resource "aws_lambda_function" "example" { 6 function_name = "ServerlessExample" 7 8 # The bucket name as created earlier with "aws s3api create-bucket" 9 s3_bucket = "terraform-serverless-example" 10 s3_key = "v1.0.0/example.zip" 11 12 # "main" is the filename within the zip file (main.js) and "handler" 13 # is the name of the property under which the handler function was 14 # exported in that file. 15 handler = "main.handler" 16 runtime = "nodejs6.10" 17 18 role = "${aws_iam_role.lambda_exec.arn}" 19 } 20 21 # IAM role which dictates what other AWS services the Lambda function 22 # may access. 23 resource "aws_iam_role" "lambda_exec" { 24 name = "serverless_example_lambda" 25 #... 26 }

5.3. Alternatives Konzept: Multi-Cloud Orchestrierung

Die zweite Alternative ist die Orchestrierung von mehreren proprietären FaaS Anbietern durch ein generisches IaC Tool. In diesem Kapitel werden wir Terraform verwenden, da es während der Recherche am häufigsten vorkommt als allgemeines IaC Werkzeug. Terraform nutzt die Konfigura- tionssprache HashiCorp Configuration Language (HCL) oder JSON als Format für das deklarieren von Ressourcen der Infrastruktur. HCL ist eine strukturierte Sprache, die mit Fokus auf DevOps erstellt wurde [Has17][Has]. Terraform unterstützt eine Reihe von Cloud-Infrastrukturanbietern wie AWS oder GCP und arbeitet eng mit Anbietern zusammen, um eine First-Class Integration zu gewährleisten. Cloud Anbieter wie Microsoft Azure zeigen Interesse an einer engen Zusammenarbeit mit Terraform, um die Integrationsbarrieren von Cloud-Services dadurch zu beheben und das Vendor Lock-in zu reduzieren [Cor][Kac17]. Ein Beispiel für eine AWS Lambda Funktionsdefinition ist in 5.2 zu sehen. Die wichtigsten Befehle des Tools sind:

terraform init ist der erste Befehl, der ausgeführt werden sollte, nachdem eine neue Terraform- Konfiguration geschrieben oder eine vorhandene aus der Versionskontrolle geklont wurde. Der Befehl initialisiert ein Arbeitsverzeichnis mit Terraform-Konfigurationsdateien und erwartet mindestens eine Terraform-Definition im Verzeichnis. Es kann auch über Argumente spezielle Terraform-Module als Eingabe mitgegeben werden [Has17].

54 5.4. Fazit der Alternative

Event Sources functons commit trigger terraform Build & Unit Tests terraform init workspace select terraform plan terraform apply implement Repository QA

terraform function Serverless-IaC.tf workspace select terraform plan terraform apply Prod Actor

Source CI/CD Pipeline

Abbildung 5.2.: Allgemeine Deployment-Pipeline mit Multi-Cloud IaC Tool Terraform Quelle: Eigene Darstellung terraform plan wird zum Erstellen eines Ausführungsplans verwendet. Terraform führt eine Ak- tualisierung aus, sofern nicht ausdrücklich deaktiviert, und bestimmt dann, welche Aktionen erforderlich sind, um den in den Konfigurationsdateien angegebenen gewünschten Status zu erreichen. Mit diesem Befehl können Sie bequem überprüfen, ob der Ausführungsplan für eine Reihe von Änderungen Ihren Erwartungen entspricht, ohne Änderungen an den realen Ressourcen oder am Zustand vorzunehmen. Beispielsweise kann terraform plan vor einer Änderung der Versionskontrolle ausgeführt werden, um die Gewissheit zu schaffen, dass sie sich wie erwartet verhält. Dieser Befehl kann sinnvoll in automatisierten Umgebungen wie DP sein [Has17]. terraform apply wendet die erforderlichen Änderungen an, um den gewünschten Zustand der Konfiguration oder den vorgegebenen Satz von Aktionen zu erreichen, die durch einen Ausführungsplan mit terraform plan erzeugt wurden [Has17].

Terraform arbeitet mit Zuständen, welche in den generierten Konfigurationsdateien stehen. Durch das Teilen von Zuständen wird eine DevOps-Umgebung und das Arbeiten in verteilten Umgebungen geschaffen. Terraform unterstützt bestimmte Backends wie Lokales Backend (Standard), Amazon S3 oder Google Cloud Storage. Durch den Befehl terraform workspace kann man Arbeitsbereiche, die einem remote Backend zugehören nutzen. Dadurch kann das Arbeiten im Team konsistent gehalten werden und eine CI/CD Umgebung geteilt werden [Has17].

5.4. Fazit der Alternative

Multi-Cloud Orchestrierung durch IaC Tools wie Terraform bieten dem Entwickler viel Flexibilität im CI/CD Prozess, da viele DevOps Konzepte unterstützt werden: • IaC durch deklarative Infrastruktur mit der einheitlichen HCL-Syntax oder JSON • Teilen des System-Zustands durch Remote-State Backends • Multi-Stage Deployments durch Terraform Workspace • Flexibilität durch Low-Level Konfiguration von Multi-Cloud Infrastruktur Das Tool hat neben den Vorteilen jedoch ein Problem nicht beheben können: Der Vendor Lock-in, der durch die abhängigen Cloud-spezifischen Services wie BaaS entsteht. Im nächsten Kapitel 6 werden Muster und Konzepte vorgestellt, um Continuous Delivery für Serverless Anwendungen zu betreiben und den Vendor Lock-in zu reduzieren.

6. Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen

Um unabhängig von Anbietern Continuous Delivery für Serverless Anwendungen zu betreiben, ist die Umgebung in der Serverless Anwendungen ausgeführt werden, entscheidend. FaaS Plattformen wie die in AWS Lambda oder GCF schränken den CI/CD Prozess der Serverless Anwendungen ein, sodass der Vendor Lock-in akzeptiert und berücksichtigt werden muss. Die Alternativen aus Kapitel 5 zeigen Möglichkeiten, wie Abstraktionen genutzt werden können, um CI/CD mit IaC Tools und Serverless Frameworks durchzuführen. Dieses Konzept führt eine GitOps-basierte DP für solche Serverless Anwendungen ein, und reduziert den Vendor Lock-in erheblich. Es wird eine FaaS Plattform verwendet, die auf Container-Orchestrierung basiert, die in jeder Umgebung, ob Cloud oder On-Prem verwendet werden kann. GitOps wird als Automatisierungstechnologie für Continuous Delivery genutzt. Um das Konzept zu demonstrieren wird im nächsten Kapitel 7 die prototypische Implementierung einer DP vorgestellt.

6.1. Cloud-agnostisches FaaS durch Container-Orchestrierung

Für eine Cloud-native und anbieterunabhängige DP wird eine FaaS Plattform verwendet, die auf Container-Orchestrierung basiert. Es existieren bereits mehr als 13 Open Source Serverless FaaS Produkte, die auf einer Container-Orchestrierung-Technologie basieren. Im Kapitel 7 werden die verwendeten Technologien und Plattformen aufgezeigt. Abbildung 6.1 zeigt eine abstrakte Ansicht des Prinzips von Serverless FaaS auf Basis von Container-Orchestrierung. Funktionen werden als isolierte Container verpackt und auf der FaaS Plattform bereitgestellt, während dieser auf einem CaaS in Cloud-Plattformen läuft. Der CaaS verwaltet die Bereitstellung, Verwaltung und Skalierung der Serverless Anwendungen auf dem Cluster. Die FaaS Plattform kann theoretisch auch On-Premise installiert werden, somit sind auch Hybrid Anwendungen möglich [JSS+19]. Im folgenden Abschnitt 6.2 wird das GitOps Pattern vorgestellt, das für den Continuous Delivery Prozess verwendet wird.

6.2. Continuous Delivery mit GitOps

GitOps ist eine Möglichkeit Continuous Delivery durchzuführen [Aled][Wea]. Es ist ein Pattern, das erstmals 2017 von Weaveworks CEO Alexis Richardson eingeführt, in ähnlicher Weise aber vor Jahren von Heroku praktiziert wurde. Git wird dabei als zentrales Kontrollsystem für den CI/CD Prozess genutzt [Ily]. Die erheblichen Eigenschaften von GitOps sind:

57 6. Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen

Cloud Provider A

Container

run on Function run on Container-Orchestrator FaaS platform Service Container

Function run on manages infrastructure

manages

Container Cloud Provider B Operations

Function Function run on

run on

Container-Orchestrator FaaS platform Service

manages infrastructure

Abbildung 6.1.: Abstraktes Multi-Cloud FaaS durch Container-Orchestrierung Quelle: Eigene Darstellung

Git als „einzige Quelle der Wahrheit“: Das Gesamtsystem inklusive allen Umgebungen (Dev, Sta- ging, Prod) wird durch IaC, Konfigurations- und Anwendungscode deklarativ im Repository verwaltet. Diese Dateien bilden den gewünschten Zustand eines Systems [LA18][Wea][Aleb] [Aled].

Operations per Pull Request (PR): Alle Änderungen am gewünschten Status sind Git-Commits. Durch git push werden Build-Pipelines eingeleitet. „Diff-Alarm“-Tools wie kubediff1 oder terradiff2 werden genutzt, um den tatsächlichen Zustand des Systems mit dem aktuell Ge- wünschten zu vergleichen und synchron zu halten [Alec].

1https://github.com/weaveworks/kubediff 2https://github.com/jml/terradiff

58 6.3. Architektur des Konzepts

Container Image Dev RW Repository RO CI-System RW RO Cluster Repository RW

Abbildung 6.2.: GitOps Pipeline: Push-Modell Quelle: [Wea]

Cluster Container Image Dev RW Repository RO CI-System RW RO Repository Operator

Conﬁg Repository

Abbildung 6.3.: GitOps Pipeline: Pull-Modell Quelle: [Wea]

Infrastructure-as-Code GitOps ermöglicht IaC Tools wie Chef, Puppet oder Terraform. Diese Werkzeuge und die zugehörigen Konfigurationsdateien sind ein zentraler Bestandteil von GitOps [Wea].

Pull- und Push-Modell GitOps bietet zwei Modelle um eine DP zu erstellen. Das Push-Modell triggert bei jedem commit ein CI-System an. Dieser führt ein CI/CD Skript aus, das dann ein immutables Container-Image erstellt und den Cluster synchronisiert (siehe 6.2). Das Pull-basierte Modell nutzt einen zusätzlichen GitOps Operator, der auf dem Cluster installiert ist und regelmäßig die zugehörigen Git-Repositorys und Container-Register prüft (siehe 6.3). Der signifikante Unterschied zum Push-Modell ist, dass Änderungen vom Cluster ausgehen [Wea]. Beide Modelle haben je nach Anwendungsfall Ihre Vor- und Nachteile [Mat].

Da GitOps-Operator im Pull-Modell einen weiterer Vendor Lock-in erzeugt, wird in dieser Arbeit das Push-Modell verwendet. Die DP durch GitOps und Container-Orchestrierung in Serverless Anwendungen wird in 6.4 dargestellt. Der Prozess beginnt mit dem Commit einer Serverless An- wendung. Anschließend wird das CI-System getriggert, um die Serverless Anwendung zu bauen, testen, containerisieren und zu deployen. Bei nicht bestandenen Tests schlägt der Build und die DP fehl. Wenn alle Tests bestanden werden, wird je nach Branch die Anwendung in der entspre- chende Umgebung bereitgestellt. Bei einem PR, also einen git push in den Master-Branch wird die Anwendung in der Produktiv-Umgebung bereitgestellt.

6.3. Architektur des Konzepts

Die Architektur des Konzepts wird abstrakt durch die minimalistische Definition nach George Fairbanks vorgeschlagener Entscheidungsdokumentation [ZCTZ13] beschrieben: Im Kontext von anbieterunabhängigen CI/CD in Serverless Anwendungen wurde für Container-Orchestrierung als portable Cloud-Plattform entschieden, um darauf aufbauende FaaS-Plattformen zu nutzen und das Vendor Lock-in Problem der FaaS Plattformen zu vermeiden. Continuous Delivery für Server- less Anwendungen wird mit dem GitOps Pattern und deklarative Infrastruktur (IaC) umgesetzt.

59 6. Konzept: GitOps basiertes Continuous Delivery von Serverless Anwendungen

Serverless App deﬁniton

"git push" code to repo

Start Development Environment

Tests passed? Pipeline failed install Build & unit test deploy and test containerization- containerized on Temporary No software serverless app FaaS Platform

Yes No serverless app as container Deploy to Run User- staging CI-System Staging Acceptance Tests Which Branch? Yes

Tests passed?

Deploy to master Production

Pipeline passed

Abbildung 6.4.: Abstrakte CD-Pipeline von containerisierten Serverless Anwendungen Quelle: Eigene Darstellung

Es wird der Nachteil akzeptiert, dass das Bezahl-Modell zwischen Angeboten der Containeror- chestrierung und proprietären FaaS-Produkten im aktuellen Stand möglicherweise variieren kann. Erstere berechnen pro reservierter Ressource, letztere pro Funktionsausführungsdauer [JSS+19]. Es wird jedoch angenommen, dass in Zukunft mit hoher Wahrscheinlichkeit durch Akzeptanz solcher anbieterunabhängigen FaaS Plattformen ein ähnliches Preismodell entsteht. In Abbildung 6.5 wird die Architektur und Komponenten des Systems veranschaulicht. Sie entstehen durch die Kombination der vorherigen Konzepte und stellen die grundlegenden Prozesse des Konzepts dar. Folgende Komponenten werden verwendet:

Code Enthält deklarativen Code für Serverless Anwendungen und Infrastruktur (IaC. Zudem kann es den Anwendungscode mitenthalten oder im deklarativen Code auf einen BaaS wie einen Cloud-basierten Speicher referenzieren, indem der Anwendungscode liegt.

Repository Hier befindet sich die „einzige Quelle der Wahrheit“, die auf git basiert undvonder alles abhängt. Die gesamte Logik und Infrastruktur wird hier abgelegt. Zudem bieten Services wie Versionshistorie, Logs, Änderungen, Rollback-Mechanismen Tools für Entwickler und Operations Teams [LA18]. Hier bestätigt ein Verantwortlicher den PR.

WebHook Ereignisbasierte Middleware, die bei jedem relevanten Commit im jeweiligen Branch automatisiert den Code des Repository auf das CI-System repliziert und den CI/CD Prozess triggert.

CI-System Das CI-System, der den Build-Prozess des Codes inklusiver Unit-Tests ausführt. Aus dem Build entsteht ein unveränderliches Image (Container-Image) und pusht nach Akzeptanz der Tests das Image in die Container Registry und löst ein Deployment in die jeweilige Umgebung (Staging oder Produktiv) aus.

Container Registry Ist die Registry, in der sich versionierte Container-Images befinden, und von Umgebungen gepullt werden.

60 6.3. Architektur des Konzepts

Operations

approve code Code test code & build immutable image

WebHook Copy Repo git push subscribe Container event to trigger CI System push image (Pull Request) CI-Build Registry

Developer Repository

deploy manage deploy & user acceptance tests pull image and run function as container FaaS expose app to the Internet Production Cluster FaaS

Staging Cluster

invoke services Production Cloud Environment Staging Cloud Environment

Customer Abbildung 6.5.: Gesamt-Architektur des Konzepts: GitOps basiertes Continuous Delivery Quelle: Eigene Darstellung

FaaS Der portable auf Container-Orchestrierung basierende FaaS, der auf einem Cluster installiert ist.

Cluster Der Container-Orchestrierung-Cluster, auf dem die FaaS Plattform läuft. Dieser wird vom Cloud-Anbieter verwaltet und bei Bedarf angepasst.

Cloud Umgebungen Das sind die Anbieter, auf denen die Serverless Plattformen und Anwendun- gen laufen. Nach dieser Architektur kann eine FaaS Plattform auch lokal auf einem Cluster bereitgestellt werden.

Ein wesentlicher Punkt in dieser Abbildung ist der Schritt zwischen „git push“ und dem CI-System. Dort befindet sich ein Webhook, der einen CI-Build auslöst. Ein WebHook ist ein HTTP-POST- Callback, der eine Nachricht an eine URL versendet, wenn eine bestimmte Ereignisbenachrichtigung über HTTP POST auftritt [Web][Git]. Die Architektur ist abstrakt gehalten, damit das Verständnis des Konzepts nicht verloren geht und durch zusätzliche, technische Implementierungsdetails zu komplex wird. Ebenso sind hier zusätzliche bedeutsame Artefakte wie Sicherheitsmechanismen oder Monitoring weggelassen worden, um den Fokus auf das Thema nicht zu verlieren. Dennoch sollte es erwähnt werden, da diese Aspekte wichtige Eigenschaften für eine DevOps Umgebung sind. Im folgenden Kapitel 7 wird die Prototypische Implementierung des Konzepts vorgestellt. In dieser wird die konkrete Architektur sowie die genutzten Technologien auf Basis der Konzepte, Methoden und Muster aus dem Konzept aufgezeigt.

7. Prototypische Implementierung

In diesem Kapitel wird eine prototypische Implementierung des Konzepts vorgestellt. Zunächst werden die gewählten Technologien in 7.1 als Grundlagen eingeführt und diskutiert. Anschließend wird in Abschnitt 7.2 die Komponenten der Implementierung beleuchtet. Im Kapitel darauf in 7.3 wird eine Wetter-Vorhersage Anwendung als Beispiel aufgezeigt. Das Fazit der Implementierung in 7.4 schließen das Kapitel ab. Der Quellcode des Prototyps befindet sich in GitHub unter der Apache-2.0 Lizenz als öffentliches RepositorySah19 [ ].

7.1. Verwendete Technologien

In diesem Kapitel werden die verwendeten Haupttechnologien für die Implementierung eingeführt. Diese Technologien dienen zur Grundlage für das Verständnis des Prototyps.

7.1.1. Docker als Container-Technologie

Das Erstellen und Bereitstellen neuer Anwendungen ist mit Containern schneller. Docker-Container fassen Software und ihre Abhängigkeiten zu einer standardisierten Einheit für die Softwareentwick- lung zusammen, die alles enthalten, was zur Ausführung benötigt wird: Code, Laufzeit, Systemtools und Bibliotheken. Docker unterstützt DevOps-Prozesse vor allem in Continuous Delivery erheblich, da mit unveränderlichen Images und isolierten Containern die Anwendung dadurch garantiert immer gleich läuft [Doc17]. Das eliminiert den Vendor Lock-in, der bei plattformspezifischen Einschränkungen wie Cloud-basierte BaaS-Dienste oder Laufzeiten entsteht.

7.1.2. Kubernetes für die Container Orchestrierung

K8s ist eine portierbare, erweiterbare Open-Source-Plattform für das Management von containerisierten Workloads und Services. Das Kubernetes-Projekt wurde 2014 von Google als Open Source bereitgestellt. Dadurch, dass K8s container zentriert ist, ermöglicht es die Portabilität zwischen Infrastrukturanbietern [Kub18]. K8s ist aktuell die De-Fakto Plattform, um Container zu orchestrieren und Microservices bereitzustellen [Bal]. K8s kann als Serverful Plattform gesehen werden, die On-Premise oder in der Cloud genutzt werden kann. Durch gehostete K8s Cloud-Services wie AWS EKS oder GKE kann die Verantwortung und das Management von K8s Clustern delegiert werden [JSS+19]. Das macht K8s zum Grundbaustein für Serverless FaaS Plattformen. In diesem Prototyp wird eine K8s-native Serverless Plattform sowohl auf einer VM, als auch in der Cloud verwendet. Folgende K8s Dienste werden verwendet:

63 7. Prototypische Implementierung

Kubernetes in Docker (kind) ist ein Tool zum Ausführen lokaler K8s-Cluster mit Docker- Containern. Es ist ein CNCF zertifizierter K8s Installer. kind1 wird als temporäre Test- umgebung in der DP genutzt, die im späteren Abschnitt ?? vorgestellt wird. AWS EKS: ist ein vollständig verwalteter K8s-Service von AWS und wird als Staging-Umgebung genutzt.

GKE ist ein vollständig verwalteter K8s-Service von GCP und wird als Produktiv-Umgebung genutzt.

Einer der bedeutenden Eigenschaften von K8s, die es von anderen Orchestrierungssystemen wie Apache Mesos2 unterscheidet, ist die deklarative API. K8s unterstützt dadurch IaC, das erheblich für den CI/CD Prozess ist [Bal]. Eine weitere signifikante Komponente sind die Custom Resources Definitions (CRD), mit der Entwickler eigene native Abstraktionen und Erweiterungen innerhalb der Kubernetes-API erstellen können. Eine Custom Resource kann mit einem Controller verbunden werden, der auf bestimmte Ereignisse reagieren kann. Mit diesen CRD ist es daher nativ in K8s möglich, ereignisgesteuerte Funktionen zu erstellen. Einige Serverless Plattformen wie Knative3 und Kubeless4 nutzen explizit diese CRD um Funktionen erstellen zu können. Der Vorteil durch diese Erweiterung ist eine engere Bindung zu K8s [Edm92][Alea]. Auch die in dieser Arbeit genutzte FaaS Plattform bietet einen Operator5 an, mit der CRD basiert Funktionen erstellt werden können. Da dies aber noch relativ unreifes Inkubator-Projekt ist, wird dies in der Arbeit nicht genutzt.

7.1.3. Helm.sh: Der Kubernetes Package Manager

Helm6 ist ein Tool zum Verwalten von K8s-Charts. Charts sind Pakete mit vorkonfigurierten K8s-Ressourcen. Mit diesem Tool ist es möglich K8s basierte Anwendungen zu teilen, da sie steuerbare, deklarative und Artefakte sind. Helm Charts ermöglichen reproduzierbare Builds von K8s-Anwendungen und unterstützen somit DevOps-Prozesse. In dieser Arbeit wird die Serverless Plattform mit Helm-Charts auf den Clustern installiert. Dazu wird im Build-Skript in Kapitel 7.2.2 näheres beleuchtet.

7.1.4. OpenFaaS: Kubernetes-native Serverless/FaaS Plattform

Als FaaS wird die Docker- und K8s-native Open Source Serverless Plattform OpenFaaS eingesetzt. Für die Implementierung kann ebenfalls eine andere K8s native Plattform verwendet werden. Das Konzept der Arbeit ändert sich dadurch nicht. Für OpenFaaS wurde entschieden, da die Dokumentation der Plattform ausführlich und verständlich ist, die Installation simpel ist und während der Recherche am häufigsten referenziert wurde. Zudem besitzt OpenFaaS die meisten GitHub- Sterne (aktuell über 13.000), das die Popularität der Serverless Plattform bezeugt. Die wesentlichen Komponenten von OpenFaaS werden in der häufig wiederzufindenden Abbildung 7.1 dargestellt.

1https://github.com/kubernetes-sigs/kind 2http://mesos.apache.org/ 3https://github.com/knative/ 4https://github.com/kubeless 5https://github.com/openfaas-incubator/openfaas-operator 6https://github.com/helm/helm

64 7.1. Verwendete Technologien

Abbildung 7.1.: OpenFaaS Komponenten Quelle: [Ope19]

OpenFaaS erstellt skalierbare Funktionen in Docker-Containern. Die oberste Schicht hierbei sind das API Gateway und der Function Watchdog. Das API Gateway erhält die eingehenden Anfragen über HTTP, den OpenFaaS an die passende Funktion weitergibt. Die Antwort erfolgt auch per HTTP zurück an den Client. Der Function Watchdog verteilt die Funktionen über die Hosts. Jeder Funktionsaufruf ist eine HTTP-Anfrage, die der Function Watchdog an die jeweilige Funktion weiterreicht. OpenFaaS containerisiert eine Anwendung standardmäßig in ein Docker Image unter der Haube. Durch den Function Watchdog (Golang basierter HTTP Server) wird dieser Container zu einer ereignisgesteuerten Funktion gemacht. Unter dem API Gateway befindet sich Prometheus7, ein Open Source Monitoring System, der Metriken für zusätzliche Skalierung von Serverless Anwen- dungen nutzt. Die Funktionen werden von K8s oder Docker Swarm orchestriert [Ope19]. In diesem Projekt wird der K8s Provider8 für OpenFaaS verwendet. Ein weitere bedeutsame Komponente von OpenFaaS ist das Kommandozeilenprogramm faas-cli9. Diese CLI wird für das Erstellen und Deployment der Beispielanwendung verwendet. Es existieren dazu drei wichtige Befehle: faas-cli build Baut ein Container Image in der lokalen Docker Bibliothek faas-cli push Pusht das Image in eine Remote-Container-Registry wie Docker Hub

7https://prometheus.io 8https://github.com/openfaas/faas-netes/ 9https://github.com/openfaas/faas-cli

65 7. Prototypische Implementierung faas-cli deploy Deployment der Funktion in einem Cluster

7.1.5. TravisCI für Build und Deployment

TravisCI ist ein vollständig verwalteter, gehosteter Service für CI/CD Pipelines. In diesem Projekt TravisCI verwendet, um Serverless Funktionen oder Anwendungen zu packetieren und an die jeweilige Umgebung auszuliefern. Das entwickelte Build-Skript für die Implementierung ist im nächsten Kapitel 7.2 unter dem Abschnitt 7.2.2 dargestellt. TravisCI wurde als Tool ausgewählt, da es immer kostenlos für Open Source Projekte genutzt werden kann. Zudem bietet das Tool durch einfache Integration und Synchronisation mit GitHub Repositories einen Mehrwert [Gmbb]. Weiter bietet TravisCI Support an Sprachen, Bibliotheken und das Monitoring von Builds durch die Live-Ansicht ein profitables Feature. Weitere Alternativen für eine CI/CD sind CircleCI10, Jenkins oder Gitlab-CI11. Im nächsten Kapitel wird die Architektur und Komponenten der Implementierung vorgestellt.

7.2. Komponenten der Implementierung

Der Prototyp soll die konkrete Implementierung einer GitOps basierten DP für Serverless Anwendun- gen aufzeigen. Die Technologien sind nur Beispiele um das Konzept umzusetzen. Die Komponenten der Gesamtarchitektur wird in Abbildung 7.3 veranschaulicht. Dieses Kapitel stellt die Architektur der DP anhand einzelner Phasen vor und zeigt technische Details der Implementierung.

7.2.1. Architektur des Prototyps

Die Architektur besteht aus einer GitOps basierten DP, die ein Multi-Cloud Deployment durchführt. Die DP besteht aus den folgenden Phasen:

Code-Commit Der Entwickler pusht mit einem „git push“ den Code der Serverless Funktion mit dem IaC Artefakten in das GitHub Repository. Wenn es ein Pull-Request für ein neues Feature ist, wird der Code von Operations-Teams nochmal geprüft, eventuell noch getestet und bestätigt.

GitHub App (WebHook) Zu Anfang des Projekts wird TravisCI mit einem GitHub Projekt ver- knüpft und durch die TravisCI-GitHub App12 ein WebHook erstellt. Diese GitHub App abonniert Ereignisse von Code-Commits in GitHub und triggert die DP in TravisCI an. Ebenso werden bestandene sowie fehlgeschlagene Builds direkt in den Commits auf GitHub angezeigt (siehe 7.2).

10https://circleci.com/ 11https://about.gitlab.com/product/continuous-integration/ 12https://github.com/marketplace/travis-ci

66 7.2. Komponenten der Implementierung

Abbildung 7.2.: GitHub Commit Logs (Build Status) mit Travis CI Integration - Quelle: [Sah19]

Build-Vorbereitung Sobald der CI-Server startet, wird TravisCI das .travis.yml Build-Skript parsen und die definierten Konfigurationen vornehmen. Das vollständige Build-Skript istin 7.1 dargestellt. Im ersten Schritt (Zeile 14-21) werden die benötigten Bibliotheken und Tools installiert, um den Build durchzuführen. Hierfür wird Docker als Service, kubectl13,Helm als Snaps14 und die OpenFaaS-CLI per cURL15-Befehl installiert. Ein lokaler Docker Client wird für den Build eines Docker Images mit der CLI benötigt. kubectl wird für das verbinden und konfigurieren der unterschiedlichen K8s-Cluster benötigt. Der Package-Manager Helm wird für die Installation der OpenFaaS-Plattform auf dem temporären kind-Cluster verwendet.

Lokales Testen OpenFaaS wird als temporäre Testumgebung auf dem kind-Cluster installiert. Die Wetter-App wird der CLI gebaut und getestet. Ein paar Integrationstests werden durch aufrufen der Funktion mit cURL durchgeführt. Sobald die Funktion erfolgreich Ergebnisse zurückliefert, wird die Testumgebung wieder gelöscht. Falls Fehler auftreten, wird der Build abgebrochen und die Pipeline schlägt fehl. Das Skript hierfür wird im Quelltext 7.2 aufgezeigt.

Deployment Das Deployment wird Branchen-basiert durchgeführt. Wenn der develop-Branch genutzt wird, dann verbindet sich die VM mit der Staging-Umgebung auf dem AWS EKS- Cluster. Die Wetter-App wird als Docker-Image gebaut und in die Image Registry hochgeladen. Das Deployment auf der OpenFaaS-Plattform erfolgt dann über einen Pull des Images und anschließenden Akzeptanztests. Wenn die Tests erfolgreich sind dann ist die Pipeline erfolg-

13https://kubernetes.io/docs/tasks/tools/install-kubectl/ 14https://wiki.ubuntuusers.de/snap/ 15https://curl.haxx.se/

67 7. Prototypische Implementierung

reich abgeschlossen und es könnte ein Pull-Request für ein Update der App erfolgen. Im Falle eines Pull-Requests oder einem Commit auf dem master-Branch wird die App in der Produktiv-Umgebung auf einem GKE-Cluster der GCP bereitgestellt.

68 7.2. Komponenten der Implementierung pull image & run function as container Docker Hub (Image Registry) (Image Registry) Kubernetes Engine Pipeline Passed Yes manage 8. pull image & 8. pull image & Production Cloud Environment run function as container Success expose to Internet 8. Connect to GKE Cluster 8. Connect to GKE Cluster 9. Deploy to OpenFaaS Production Amazon EKS invoke services Staging Staging Cloud Environment Production Customer develop master 4. Build immutable Image and push to Registry Branch? Quelle: Eigene Darstellung Pipeline Failed Yes No Architektur der prototypischen Continuous Delivery Pipeline 6. Connect to AWS EKS Cluster EKS Cluster 6. Connect to AWS 7. Deploy to OpenFaaS Staging 8. Acceptance Tests Operations Developer Success approve code git push 5. Local Testing Abbildung 7.3.: (Pull Request) (temporary Environment) Local Testing GitHub Repo Travis CI Pipeline Travis IaC Files subscribe change events Prepare Build Function Function (WebHook) (WebHook) GitHub App 1. Install Docker Weather-Forecast Weather-Forecast 2. Install K8s and Helm 3. Install OpenFaaS CLI Pipeline Pipeline Trigger CI CI Trigger

69 7. Prototypische Implementierung

Im nächsten Abschnitt werden die Skripte der DP näher betrachtet.

7.2.2. CI/CD Skripte

Im Zentrum der DP befindet sich das Travis CI Build-Skript. Es enthält alle Operationen durch strukturierte Befehle und Bash-Skripte, die deklarative Infrastruktur (IaC) anwenden. Das Build- Skript in Travis CI definiert alle Phasen des Builds und Deployments im YAML Format.

TravisCI Build-Skript

Der Code des Build-Skripts ist in 7.1 dargestellt. Das Build-Skript beginnt mit der Distribution VM. Um die Installation der Tools wie kubectl oder helm einfach zu halten, werden Snaps16 genutzt. Der Package-Manager snapd ist auf Ubuntu Xenial vorinstalliert, daher wird diese Distribution gewählt. Das „minimal“ Image wird verwendet, um nur die notwendigen Sprachen und Bibliotheken für die DP zu installieren. Dieses enthält Versionkontrollsysteme, Build-Tools wie gcc und make, Netzwerktools wie cURL und andere sowie Docker und Python [Gmba]. Weitere Tools wie kind oder die OpenFaaS CLI werden in der before_install17 Phase installiert. In der install-Phase wird für die temporäre Testumgebung ein K8s Cluster mit dem kind Tool installiert. Anschließend wird die OpenFaaS-Plattform durch ein Bash-Skript auf dem Cluster bereitgestellt. Um auf das K8s- Cluster zuzugreifen wird die von kind erstellte kubeconfig Datei (YAML Format) genutzt. Für die Installation der OpenFaaS-Plattform wird der Package-Manager Helm verwendet, da OpenFaaS (K8s Verison) Charts zur Verfügung stellt. Über die Port-Weiterleitung kann auf OpenFaaS lokal zugegriffen werden. Wenn die Installation der temporären Testumgebung fertig ist, wird die Anwendung auf dem lokalen Testserver der VM getestet. Die Anweisungen dafür werden im Bash-Skript in 7.2 dargestellt. Die CI-Maschine verbindet sich durch die Umgebungsvariable KUBECONFIG mit dem K8s-Cluster und loggt den Entwickler in die Docker Image Registry (Docker Hub) ein. Die Zeile 8 führt mit faas-cli up alle erforderlichen Schritte (siehe Abschnitt 7.1.4) für das Deploy- ment der Funktion aus. Zur Eingabe wird als Argument eine Spezifikation der Anwendung (siehe 7.3) in YAML-Format übergeben. Anschließend wird die Funktion über faas-cli invoke aufgerufen, um einige Testfälle abzudecken. Wenn keine Fehler auftreten, wird das temporäre Cluster gelöscht. Die nächste Phase ist das Deployment, das je nach Branch ein Deployment-Skript ausführt. Hier sind die Eingabe der Gateway URL und Zugangsdaten notwendig, um zum Cluster zu verbinden. Je nach Cloud-Plattform wird ein Authentifizierungsmechanismus um den Entwickler zu autorisieren benö- tigt. Je nach Branch werden Nutzer-Akzeptanztests durchgeführt um einen späteren Pull-Request für eine Auslieferung an die Produktivumgebung durchzuführen. Im kommenden Abschnitt wird die implementierte Beispielanwendung zur Demonstration des Prototyps vorgestellt.

16https://snapcraft.io/ 17In dieser Arbeit werden die Standard-Namen der Phasen in Travis CI verwendet

70 7.2. Komponenten der Implementierung

Listing 7.1 TravisCI Build Skript - .travis.yml 1 dist: xenial 2 sudo: required 3 language: minimal 4 5 # safelist 6 branches: 7 only: 8 - master 9 - develop 10 11 addons: 12 apt: 13 update: false 14 snaps: 15 - name: kubectl 16 classic: true 17 - name: helm 18 classic: true 19 services: 20 - docker 21 22 before_install: 23 - curl -sSL https://cli.openfaas.com | sudo sh 24 -go get sigs.k8s.io/kind 25 26 install: 27 - kind create cluster --name openfaas 28 - ./scripts/installation/openfaas-kind.sh 29 30 script: 31 - ./scripts/local-tests/weather-forecast.sh 32 - kind delete cluster --name openfaas 33 34 deploy: 35 - provider: script 36 skip_cleanup: true 37 script: bash scripts/deployment/deploy_production.sh 38 on: 39 branch: master 40 - provider: script 41 skip_cleanup: true 42 script: bash scripts/deployment/deploy_staging.sh 43 on: 44 branch: develop

71 7. Prototypische Implementierung

Listing 7.2 Lokale Tests in der temporären OpenFaaS Umgebung - weather-forecast.sh 1 #!/bin/bash 2 3 # build, deploy and push weather-forecast function and call it 4 export KUBECONFIG="$(kind get kubeconfig-path --name="openfaas")" 5 cd testing 6 # building and testing the function with gradle tool 7 echo "$DOCKER_PW" | docker login -u "$DOCKER_USERNAME" --password-stdin 8 faas-cli up -f weather-forecast.yml 9 10 # Some test cases 11 echo -n Stuttgart, DE | faas-cli invoke weather-forecast 12 echo -n Istanbul | faas-cli invoke weather-forecast 13 echo -n Heilbronn:DE | faas-cli invoke weather-forecast

Listing 7.3 OpenFaaS Function Description (IaC) - weather-forecast.yml 1 provider: 2 name: faas 3 gateway: http://127.0.0.1:8080 4 functions: 5 weather-forecast: 6 lang: java8 7 handler: ./weather-forecast 8 image: sahinmm/weather-forecast

7.3. Beispiel einer FaaS Anwendung: Wettervorhersage mit der OpenWeatherMap

Die FaaS Anwendung ist eine in Java entwickelte Wetter-Vorhersage-App auf Basis der offenen OpenWeatherMap API18. Die Funktion erhält zur Eingabe einen Ort, der eine Stadt, Land oder eine Kombination von beidem sein kann. Als Ergebnis liefert das Programm die Daten als JSON zurück. Eine Serverless FaaS Anwendung in OpenFaaS enthält zwei erhebliche Artefakte für das Deploy- ment: • Spezifikation der Anwendung: Die Definition und Konfiguration als YAML-Datei (siehe 7.3) • QuellCode: Alles was zum Code der Anwendung gehört. Der Ort des Quellcodes wird in der Spezifikation festgelegt. Darin wird der Provider mit URL des API Gateways definiert. Das kann auch zur Deployment-Zeit über das Argument --gateway überschrieben werden. Da dies eine lokale Testumgebung ist, kann der Standard-Wert beibehalten werden. Weiter wird eine Java-Funktion, der zugehörige Handler als Verzeichnis des Quellcodes und der Name die Referenz des Docker-Images. Die Struktur der Definition in OpenFaaS ähnelt der des Serverless-Frameworks (5.1). In OpenFaaS können Anwendungen aus Templates erstellt werden. Dieses Feature ist aus anderen Frameworks wie das

18https://openweathermap.org/api

72 7.3. Beispiel einer FaaS Anwendung: Wettervorhersage mit der OpenWeatherMap

Listing 7.4 Java OpenFaaS Weather Forecast Serverless Anwendung - Handler.java 1 public class Handler implements com.openfaas.model.IHandler { 2 private static final String API_KEY = "ed9cd70c532137e71859eb0258ebc6d2"; 3 private static final String API_URL = "http://api.openweathermap.org/data/2.5/weather?APPID="; 4 private static final String FORECAST_API = "http://api.openweathermap.org/data/2.5/forecast?APPID="; 5 private static final String BASE_URL = API_URL + API_KEY; 6 7 8 public IResponse Handle(IRequest req) { 9 String responseBody = ""; 10 11 String body = req.getBody(); 12 String[] inputLocationData = body.split(",|:"); 13 14 if (inputLocationData.length < 0 || inputLocationData.length > 2) { 15 responseBody = "Wrong Number of arguments! Please either enter a single value with City" 16 + "or enter a Country to it!"; 17 } else { 18 responseBody = currentWeatherDataAsJSON(inputLocationData); 19 } 20 IResponse res = new Response(); 21 res.setBody(responseBody); 22 return res; 23 } 24 25 public static String currentWeatherDataAsJSON(String[] inputLocationData) { 26 String weatherJSON = null; 27 // ... 28 URL requestURL = new URL(urlStringBuilder.toString()); 29 HttpURLConnection con = (HttpURLConnection) requestURL.openConnection(); 30 con.setRequestMethod("GET"); 31 // ... 32 return weatherJSON; 33 }

Serverless Framework bekannt. Bei einer Java-Anwendung wird in OpenFaaS ein Gradle-Projekt erstellt. Der Aufbau und die Schnittstellen der Anwendung wird vorkonfiguriert. Der Quelltext 7.4 ist ein Ausschnitt der Wetter-Vorhersage-App. Jeder Handler muss das com.openfaas.model.IHandler Interface und die Methode public IResponse Handle(IRequest req) implementieren. Im Wesentlichen sind diese zwei Schnittstellen von Bedeu- tung:

IRequest erstellt ein Request-Objekt, die Informationen der HTTP-Anfragen enthält.

IResponse erstellt ein Response-Objekt, das Ergebnisse als HTTP-Antwort an den Nutzer zurück- liefert.

73 7. Prototypische Implementierung

7.4. Fazit der Implementierung

In diesem Kapitel wurde die prototypische Implementierung des Konzepts vorgestellt. Das Ergebnis ist eine Push-basierte GitOps Multi-Cloud DP einer Serverless FaaS Anwendung. Durch Contai- nerisierung von Serverless Anwendungen sind DevOps-Praktiken wie Continuous Delivery gut umsetzbar. Durch GitOps unterstützenden Technologien wie IaC, Git-Repositories, WebHooks und integrierbaren CI-Systemen kann eine anbieterunabhängige DP entwickelt werden. Der Prototyp ist nur ein Beispiel für die Implementierung des Konzepts. Im Prinzip könnten die Technologien später durch reifere Produkte ersetzt werden. Um das Prinzip zu vereinfachen, wurde eine leichtgewichtige FaaS-Plattform gewählt. Die Implementierung hat gezeigt, dass durch Container-Orchestrierung und cloud-nativen Plattformen wie K8s isolierte, unabhängige Serverless-Umgebungen möglich sind und in einen CI/CD Prozess integriert werden können. Durch dieses Prinzip könnten große Plattformen entstehen, die auf Container-Orchestrierung und dem Serverless Paradigma aufbauen und den Vendor Lock-in auf Cloud-Anbietern reduzieren. Im nächsten Kapitel wird ein Fazit und Ausblick über die Masterarbeit gegeben.

74 8. Zusammenfassung und Ausblick

Die vorliegende Masterarbeit führt das Vendor Lock-in Problem ein, das in DevOps-Prozessen von proprietären Serverless Plattformen auftritt und schlägt eine konzeptionelle Lösung zur Reduzierung des Problems vor. Serverless ist ein weit verbreitetes, aber noch relativ neues Thema. Es beschreibt das Konzept, Anwendungen zu erstellen und auszuführen, ohne Server zu verwalten. Einerseits beschreibt es Drittanbieter Services als BaaS, die von der Cloud Plattform angeboten werden. Weiterhin wird das Deployment kleiner, kurzlebiger und ereignisgesteuerte Funktionen auf einer Plattform als FaaS bezeichnet. Continuous Delivery definiert den automatisierten Softwareausliefe- rungsprozess vom Quellcode bis zur Freigabe der Software an den Kunden. Er beschreibt weiterhin die zuverlässige, häufige und schnelle Softwarebereitstellung durch Tools. Die Einschränkungen und unterschiedliche Implementierung proprietärer FaaS Plattformen lösen ein Vendor Lock-in auf verschiedenen Ebenen aus. Eigenschaften wie API-Gateways, Ereignistypen, Sprachen, Laufzeiten oder BaaS Services unterscheiden sich in den FaaS Plattformen. Entwickler sind daher stark an die Umgebung gebunden, wenn CI/CD Prozesse definiert werden sollen. Im Rahmen der Recherche wurde auf eine verwandte Arbeit verwiesen. Diese behandelt die Imple- mentierung einer DevOps-Pipeline mit dem Serverless Framework. Sie hat bestehende DevOps- Praktiken, Technologien sowie Probleme genannt, die allgemein im DevOps-Bereich für Serverless Anwendungen entstehen. Das Vendor Lock-In Problem wird in der verwandten Arbeit angesprochen, jedoch nicht weiter behandelt und ist der Hauptfokus dieser Masterarbeit. Die SLR zur Untersuchung von Stand der Technik ergab, dass die Mehrheit der Herausforderungen im Bereich CI/CD und Serverless neben dem Vendor Lock-in der damit verbundene Mangel an Tooling ist. Lediglich Cross-Cloud Lösungen durch Abstraktionen zu nutzen, reichen nicht aus, um den Vendor Lock-in zu beheben. Der Bereich Serverless bezüglich CI/CD zeigte Konzepte wie Container und Container-Orchestrierung sowie Versionierung als geeignete Methoden um Continuous Delivery durchzuführen. Funktionen können durch Containerisierung als isolierte Deployment-Einheiten unabhängig bereitgestellt werden. Hier schlägt die Forschung vor K8s und Docker-basierte Serverless Produkte zu verwenden, da sie De-Fakto Standards im Bereich Container und Orchestrierung sind. Im Multi-Cloud Bereich wird in Konzepten wie deklarative Infrastruktur durch IaC, Container-Technologien und Orchestrierungen sowie der TOSCA Standard größtenteils aktiv geforscht. Zwei Alternativen sind auf Basis von Ergebnissen der SLR entstanden. Gemeint ist die Nutzung von CI/CD Prozessen durch das Serverless Framework oder die Multi-Cloud Bereitstellung durch ein universelles IaC Tool. Es wurde ein Pseudo-Algorithmus eingeführt, der auf Basis von Anforde- rungen und Zielen eine alternative Lösung des Problems durch IaC, Abstraktionen und Frameworks findet. Das konkrete Konzept der Arbeit basiert ebenfalls ausder SLR und weiteren Recherchen. Für die Entwicklung des Konzeptes für eine anbieterunabhängige Continuous Delivery Lösung in Serverless Anwendungen wurde eine GitOps-Pipeline konzipiert, die Serverless-Anwendungen durch Containern orchestriert. GitOps ist ein Muster, das ein Versionskontrollsystem wie git als

75 8. Zusammenfassung und Ausblick einzige Quelle der Wahrheit für den Zustand der Anwendung verwendet. Durch die Kombination von GitOps und Container-Orchestrierung kann ein anbieterunabhängiges CI/CD für Serverless Anwendungen durchgeführt werden. Zur Demonstration des Konzepts wurde eine DP und Wetter-Vorhersage-Anwendung als Prototyp implementiert und vorgestellt. Die Implementierung nutzt GitHub als Repository des Quellcodes, sowie WebHooks für die Synchronisation mit dem CI-Build-Server und IaC um GitOps zu unter- stützen sowie zwei Cloud-Plattformen Deployment-Ziele. Es werden deklarative Skripte für den Zugriff auf die Cluster und den FaaS Plattformen verwendet. Durch Nutzung von Docker und K8s nativem FaaS werden die Funktionen isoliert verpackt und bereitgestellt. Hierbei werden Images mit Tags versioniert in die Registry (Docker Hub) gepusht. Durch deklarative API von K8s kann durch Konfigurationsskripte immer der aktuelle Status im git-Repository gehalten werden. Das unterstützt den GitOps-Pattern.

Ausblick

Das Interesse an Serverless und den Vorteilen von schneller Markteinführung wird weiter zunehmen. FaaS deckt interessante Anwendungsbereiche wie Single-Page Anwendungen oder zustandslose, rechenintensive Komponenten ab. Das Vendor Lock-in Problem in proprietären FaaS Anbietern kann nicht durch Unmengen an Tooling und Abstraktionen behoben werden, da die Kontrolle des Infrastrukturmanagements verloren geht. Entwickler und Nutzer sollten sich, wenn Multi-Cloud Ansätze nicht notwendig sind eine FaaS auswählen, die bestens zu den Bedürfnissen der Anfor- derungen passt. Um eine vollständige Anbieterunabhängigkeit gewährleisten zu können, sollten Anwendungen entweder isoliert von der Zielplattform oder an die Bedingungen angepasst werden. Durch Nutzung Cloud-nativen Architekturen wie Container und Orchestrierung sind isolierte unab- hängige Deployments von Serverless Anwendungen möglich. Die Open Source Community hat dies bereits erkannt und arbeitet an mehr als fünfzehn Kubernetes-basierten Serverless/FaaS Projekten. Davon existieren bereits junge Plattformen, die Multi-Cloud Serverless Lösungen anbieten. Auf der anderen Seite stehen Standardisierungen in den Bereichen Serverless und FaaS von Organisationen wie der CNCF in Entwicklung. Diese könnten neue DevOps Konzepte und Methoden hervorbringen. Wie die Zukunft von Serverless Produkten aussehen wird ist daher nicht eindeutig.

76 Literaturverzeichnis

[AC17] G. Adzic, R. Chatley. „Serverless computing: economic and architectural impact“. In: Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering - ESEC/FSE 2017. New York, New York, USA: ACM Press, 2017, S. 884–889. isbn: 9781450351058. doi: 10.1145/3106237.3117767. url: http://dl.acm.org/citation. cfm?doid=3106237.3117767 (zitiert auf S. 25, 29, 31, 41–43, 87). [AKC+15] A. P. Achilleos, G. M. Kapitsaki, E. Constantinou, G. Horn, G. A. Papadopoulos. „Business-Oriented Evaluation of the PaaSage Platform“. In: Proceedings - 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing, UCC 2015. IEEE Press, 2015, S. 322–326. isbn: 9780769556970. doi: 10.1109/UCC.2015.51. url: https://dl.acm.org/citation.cfm?id=3233448 (zitiert auf S. 41, 92). [Alea] Alex Ellis. Introducing the OpenFaaS Operator for Serverless on Kubernetes. url: https://blog.alexellis.io/introducing-the-openfaas-operator/ (besucht am 01. 03. 2019) (zitiert auf S. 64). [Aleb] Alexis Richardson. GitOps - Operations by Pull Request. url: https://www.weave. works/blog/gitops-operations-by-pull-request (besucht am 27. 02. 2019) (zitiert auf S. 57, 58). [Alec] Alexis Richardson. GitOps Part 3 - Observability. url: https://www.weave.works/ blog/gitops-part-3-observability (besucht am 27. 02. 2019) (zitiert auf S. 58). [Aled] Alexis Richardson. What Is GitOps Really? url: https://www.weave.works/blog/ what-is-gitops-really (besucht am 27. 02. 2019) (zitiert auf S. 57, 58). [ALKH17] K. Alexander, C. Lee, E. Kim, S. Helal. „Enabling End-To-End Orchestration of Multi- Cloud Applications“. In: IEEE Access 5 (2017), S. 18862–18875. issn: 21693536. doi: 10.1109/ACCESS.2017.2738658. url: http://ieeexplore.ieee.org/document/ 8008766/ (zitiert auf S. 41, 107). [Ang] L. Angel. Docker + Servless = FaaS (Funktionen als Dienst) | Luke Angel. url: http: //lukeangel.co/cross-platform/docker-servless-faas-functions-as-a-service/ (besucht am 17. 02. 2019) (zitiert auf S. 22). [Aws19] Awslabs. awslabs/serverless-application-model. Feb. 2019. url: https://github. com/awslabs/serverless-application-model. [Bal] A. A. Balkan. Knative: Building serverless platforms on top of Kubernetes. Techn. Ber. url: https://seattle.serverlessdays.io/media/slides/Kubernetes+Serverless= Knative.pdf (zitiert auf S. 63, 64).

77 Literaturverzeichnis

[BCC+17] I. Baldini, P. Castro, K. Chang, P. Cheng, S. Fink, V. Ishakian, N. Mitchell, V. Muthu- samy, R. Rabbah, A. Slominski, P. Suter. „Serverless Computing: Current Trends and Open Problems“. In: Research Advances in Cloud Computing (2017), S. 1–20. doi: 10.1007/978-981-10-5026-8_1. arXiv: 1706.03178. url: https://arxiv.org/pdf/ 1706.03178.pdf%20http://arxiv.org/abs/1706.03178 (zitiert auf S. 17, 21, 23, 25, 29). [BGK+13] G. Baryannis, P. Garefalakis, K. Kritikos, K. Magoutis, A. Papaioannou, D. Plexou- sakis, C. Zeginis. „Lifecycle management of service-based applications on multi- clouds“. In: Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds - MultiCloud ’13. New York, New York, USA: ACM Press, 2013, S. 13. isbn: 9781450320504. doi: 10.1145/2462326.2462331. url: http://dl.acm.org/citation.cfm?doid=2462326.2462331 (zitiert auf S. 41, 90). [BIS+14] A. Brogi, A. Ibrahim, J. Soldani, J. Carrasco, J. Cubo, E. Pimentel, F. D’Andria. „SeaClouds“. In: ACM SIGSOFT Software Engineering Notes 39.1 (Feb. 2014), S. 1– 4. issn: 01635948. doi: 10.1145/2557833.2557844. url: http://dl.acm.org/ citation.cfm?doid=2557833.2557844 (zitiert auf S. 41, 93). [BKB+07] P. Brereton, B. A. Kitchenham, D. Budgen, M. Turner, M. Khalil. „Lessons from applying the systematic literature review process within the software engineering domain“. In: Journal of Systems and Software 80.4 (Apr. 2007), S. 571–583. issn: 01641212. doi: 10.1016/j.jss.2006.07.009. url: https://www.sciencedirect.com/ science/article/pii/S016412120600197X (zitiert auf S. 38). [BPR16] J. O. Benson, J. J. Prevost, P. Rad. „Survey of automated software deployment for computational and engineering research“. In: 10th Annual International Systems Con- ference, SysCon 2016 - Proceedings. IEEE, Apr. 2016, S. 1–6. isbn: 9781467395182. doi: 10.1109/SYSCON.2016.7490666. url: http://ieeexplore.ieee.org/document/ 7490666/ (zitiert auf S. 41, 103). [BSG+18] D. Baur, D. Seybold, F. Griesinger, H. Masata, J. Domaschka. „A provider-agnostic approach to multi-cloud orchestration using a constraint language“. In: Proceedings - 18th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, CCGRID 2018. IEEE, Mai 2018, S. 173–182. isbn: 9781538658154. doi: 10.1109/ CCGRID.2018.00032. url: https://ieeexplore.ieee.org/document/8411021/ (zitiert auf S. 41, 103). [CDR+17] V.Casola, A. De Benedictis, M. Rak, U. Villano, E. Rios, A. Rego, G. Capone. „MUSA deployer: Deployment of multi-cloud applications“. In: Proceedings - 2017 IEEE 26th International Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises, WETICE 2017. IEEE, Juni 2017, S. 107–112. isbn: 9781538617588. doi: 10.1109/WETICE.2017.46. url: http://ieeexplore.ieee.org/document/8003798/ (zitiert auf S. 41, 102). [CFN+14] L. Cianciaruso, F. di Forenza, E. D. Nitto, M. Miglierina, N. Ferry, A. Solberg. „Using Models at Runtime to Support Adaptable Monitoring of Multi-clouds Applications“. In: 2014 16th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (Sep. 2014), S. 401–408. doi: 10.1109/SYNASC.2014.60. url: http://ieeexplore.ieee.org/document/7034710/ (zitiert auf S. 41, 101). [Cnc18] Cncf. cncf/wg-serverless. Sep. 2018. url: https://github.com/cncf/wg-serverless/ tree/master/whitepapers/serverless-overview (zitiert auf S. 21–26, 28).

78 Literaturverzeichnis

[Cor] Corey Sanders. More and more fun with Terraform on Azure | Blog | Microsoft Azure. url: https://azure.microsoft.com/en-us/blog/more-and-more-fun-with- terraform-on-azure/ (besucht am 25. 02. 2019) (zitiert auf S. 54). [Cra] Craigshoemaker. Trigger und Bindungen in Azure Functions. url: https://docs. microsoft.com/de-de/azure/azure-functions/functions-triggers-bindings (zitiert auf S. 30). [DAFP15] M. A. A. D. Da Silva, D. Ardagna, N. Ferry, J. F. Pérez. „Model-driven design of cloud applications with quality-of-service guarantees: The modaclouds approach, MICAS Tutorial“. In: Proceedings - 16th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, SYNASC 2014. IEEE, Sep. 2015, S. 3–10. isbn: 9781479984480. doi: 10.1109/SYNASC.2014.8. url: http://ieeexplore.ieee.org/ document/7034658/ (zitiert auf S. 41, 106). [DMB18] V. Debroy, S. Miller, L. Brimble. „Building lean continuous integration and delivery pipelines by applying DevOps principles: a case study at Varidesk“. In: Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering - ESEC/FSE 2018. New York, New York, USA: ACM Press, 2018, S. 851–856. isbn: 9781450355735. doi: 10.1145/3236024.3275528. url: http://dl.acm.org/citation.cfm?doid=3236024. 3275528 (zitiert auf S. 26, 41, 89). [Doc17] Docker. Get Started with Docker Engine. 2017. url: https://www.docker.com/get- started%20https://docs.docker.com/linux/ (besucht am 01. 03. 2019) (zitiert auf S. 63). [EBM16] V.C. Emeakaroha, M. Bullman, J. P. Morrison. „Towards Automated Cost-Efficient Data Management for Federated Cloud Services“. In: 2016 5th IEEE International Conference on Cloud Networking (Cloudnet). IEEE, Okt. 2016, S. 158–163. isbn: 978-1-5090-5093-2. doi: 10.1109/CloudNet.2016.37. url: http://ieeexplore.ieee. org/document/7776594/ (zitiert auf S. 41, 106). [Edm92] Edmund Optics. „Custom Resources“. In: (1992). url: https://kubernetes.io/ docs/concepts/extend-kubernetes/api-extension/custom-resources/%7B%5C# %7Dcustomresourcedefinitions (zitiert auf S. 64). [Elg15] I. Elgedawy. „SULTAN: A Composite Data Consistency Approach for SaaS Multi- cloud Deployment“. In: Proceedings - 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing, UCC 2015. IEEE Press, 2015, S. 122–131. isbn: 9780769556970. doi: 10.1109/UCC.2015.28. url: https://dl.acm.org/citation. cfm?id=3233417%20https://ieeexplore.ieee.org/document/7431403/ (zitiert auf S. 41, 94). [Eri18] Eric Minick. The effects of cloud-native architecture on continuous delivery. 2018. url: https://www.ibm.com/blogs/cloud-computing/2018/11/12/cloud-native- architecture-continuous-delivery/ (besucht am 21. 02. 2019) (zitiert auf S. 26). [FCR+13] N. Ferry, F. Chauvel, A. Rossini, B. Morin, A. Solberg. „Managing multi-cloud systems with CloudMF“. In: Proceedings of the Second Nordic Symposium on Cloud Computing & Internet Technologies - NordiCloud ’13. New York, New York, USA: ACM Press, 2013, S. 38–45. isbn: 9781450323079. doi: 10.1145/2513534.2513542. url: http://dl.acm.org/citation.cfm?doid=2513534.2513542 (zitiert auf S. 41, 91).

79 Literaturverzeichnis

[FCS+18] N. Ferry, F. Chauvel, H. Song, A. Rossini, M. Lushpenko, A. Solberg. „CloudMF“. In: ACM Transactions on Internet Technology 18.2 (Jan. 2018), S. 1–24. issn: 15335399. doi: 10.1145/3125621. url: http://dl.acm.org/citation.cfm?doid=3182619.3125621 (zitiert auf S. 41, 45, 90). [FCSS15] N. Ferry, F. Chauvel, H. Song, A. Solberg. „Continous deployment of multi-cloud systems“. In: Proceedings of the 1st International Workshop on Quality-Aware Dev- Ops - QUDOS 2015. New York, New York, USA: ACM Press, 2015, S. 27–28. isbn: 9781450338172. doi: 10.1145/2804371.2804377. url: http://dl.acm.org/citation. cfm?doid=2804371.2804377 (zitiert auf S. 41, 46, 88). [FIMS17] G. C. Fox, V. Ishakian, V. Muthusamy, A. Slominski. „Status of Serverless Computing and Function-as-a-Service(FaaS) in Industry and Research“. In: August (Aug. 2017), S. 1–22. doi: 10.13140/RG.2.2.15007.87206. arXiv: 1708.08028. url: http://arxiv. org/abs/1708.08028%20http://dx.doi.org/10.13140/RG.2.2.15007.87206%20http: //arxiv.org/abs/1708.08028%7B%5C%%7D0Ahttp://dx.doi.org/10.13140/RG.2.2. 15007.87206 (zitiert auf S. 17, 18, 25). [FRC+13] N. Ferry, A. Rossini, F. Chauvel, B. Morin, A. Solberg. „Towards Model-Driven Provisioning, Deployment, Monitoring, and Adaptation of Multi-cloud Systems“. In: 2013 IEEE Sixth International Conference on Cloud Computing. IEEE, Juni 2013, S. 887–894. isbn: 978-0-7695-5028-2. doi: 10.1109/CLOUD.2013.133. url: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6740239 (zitiert auf S. 41, 100). [Fro12] K. Fromm. Why The Future Of Software And Apps Is Serverless. 2012. url: https: //readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is- serverless/ (besucht am 18. 09. 2018) (zitiert auf S. 17, 21, 40). [FSR+14] N. Ferry, H. Song, A. Rossini, F. Chauvel, A. Solberg. „Cloud MF: Applying MDE to tame the complexity of managing multi-cloud applications“. In: Proceedings - 2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing, UCC 2014. IEEE, Dez. 2014, S. 269–277. isbn: 9781479978816. doi: 10.1109/UCC.2014.36. url: http://ieeexplore.ieee.org/document/7027503/ (zitiert auf S. 41, 89). [Gan17] M. Ganapathi. Serverless Architecture Patterns. 2017. url: https://www.slideshare. net/AmazonWebServices/serverless-architecture-patterns%20https://www. meetup.com/Serverless-Bangalore/events/242085506/ (besucht am 18. 02. 2019) (zitiert auf S. 23). [GCGA15] M. Guerriero, M. Ciavotta, G. P. Gibilisco, D. Ardagna. „SPACE4Cloud: a DevOps environment for multi-cloud applications“. In: Proceedings of the 1st International Workshop on Quality-Aware DevOps - QUDOS 2015. New York, New York, USA: ACM Press, 2015, S. 29–30. isbn: 9781450338172. doi: 10.1145/2804371.2804378. arXiv: 1606.04036. url: http://dl.acm.org/citation.cfm?doid=2804371.2804378 (zitiert auf S. 41, 91). [GG18] G. B. Ghantous, A. Q. Gill. „DevOps Reference Architecture for Multi-cloud IOT Applications“. In: 2018 IEEE 20th Conference on Business Informatics (CBI). Bd. 01. IEEE, Juli 2018, S. 158–167. isbn: 2378-1971 VO - 01. doi: 10.1109/CBI.2018.00026. url: https://ieeexplore.ieee.org/document/8452669/ (zitiert auf S. 41, 105).

80 Literaturverzeichnis

[ggaa] ggailey777. Skalierung und Hosting von Azure Functions. url: https : / / docs . microsoft.com/de-de/azure/azure-functions/functions-scale (zitiert auf S. 30). [ggab] ggailey777. Übersicht über die Runtimeversionen von Azure Functions. url: https: //docs.microsoft.com/de-at/azure/azure-functions/functions-versions (zitiert auf S. 30). [Git] GitHub Developer. Webhooks | GitHub Developer Guide. url: https://developer. github.com/webhooks/ (besucht am 28. 02. 2019) (zitiert auf S. 61). [Gmba] T. C. GmbH. Minimal and Generic images - Travis CI. url: https://docs.travisci.com/user/languages/minimal-and-generic/ (besucht am 01. 03. 2019) (zitiert auf S. 70). [Gmbb] T. C. GmbH. Travis CI – Test and Deploy with Confidence. url: https://travisci.com/ (zitiert auf S. 66). [Goo] Google. Google Trends. url: https://www.google.com/trends (zitiert auf S. 18). [Has] HashiCorp. Terraform Curriculum - HashiCorp Learn. url: https://learn.hashico rp.com/terraform/ (besucht am 25. 02. 2019) (zitiert auf S. 54). [Has17] HashiCorp. Introduction - Terraform by HashiCorp. 2017. url: https : / / www . terraform.io/%20https://www.terraform.io/intro/index.html (besucht am 25. 02. 2019) (zitiert auf S. 51, 54, 55). [HB13] K. Huang, K. Begnum. „The hydra: A layered, redundant configuration management approach for cloud-agnostic disaster recovery“. In: Proceedings of the International Conference on Cloud Computing Technology and Science, CloudCom. Bd. 2. IEEE, Dez. 2013, S. 333–336. isbn: 978-0-7695-5095-4. doi: 10.1109/CloudCom.2013.158. url: http://ieeexplore.ieee.org/document/6735446/ (zitiert auf S. 41, 99). [HF10] J. Humble, D. Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Adobe Reader). Pearson Education, 2010 (zitiert auf S. 27, 28). [HRN06] J. Humble, C. Read, D. North. „The deployment production line“. In: AGILE 2006 (AGILE’06). IEEE. 2006, 6–pp (zitiert auf S. 26). [Ily] Ilya Dmitrichenko. Weaveworks GitOps Developer Toolkit. Part one: Skaffold. url: https://www.weave.works/blog/weaveworks-gitops-developer-toolkit-part-one- skaffold (besucht am 27. 02. 2019) (zitiert auf S. 57). [Iva18] V. Ivanov. „Implementation of DevOps pipeline for Serverless Applications“. Diss. 2018. url: https://aaltodoc.aalto.fi/bitstream/handle/123456789/32432/ master%7B%5C_%7DIvanov%7B%5C_%7DVitalii%7B%5C_%7D2018.pdf?sequence=1%7B%5C& %7DisAllowed=y (zitiert auf S. 21, 33, 49–51). [JSS+19] E. Jonas, J. Schleier-Smith, V. Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V. Shankar, J. M. Carreira, K. Krauth, N. Yadwadkar, J. Gonzalez, R. A. Popa, I. Stoica, D. A. Pat- terson. Cloud Programming Simplified: A Berkeley View on Serverless Computing. Techn. Ber. Electrical Engineering und Computer Sciences, University of California at Berkeley, 2019 (zitiert auf S. 17, 18, 21, 23, 25, 44, 57, 60, 63).

81 Literaturverzeichnis

[JY18] B. Jambunathan, K. Yoganathan. „Architecture Decision on using Microservices or Serverless Functions with Containers“. In: 2018 International Conference on Current Trends towards Converging Technologies (ICCTCT). IEEE, März 2018, S. 1– 7. isbn: 978-1-5386-3702-9. doi: 10 . 1109 / ICCTCT . 2018 . 8551035. url: https : //ieeexplore.ieee.org/document/8551035/ (zitiert auf S. 17, 21, 28, 29, 41, 42, 44, 46, 96). [Kac17] M. Kaczorowski. HashiCorp and Google expand collaboration, easing secret and infrastructure management. 2017. url: https://cloud.google.com/blog/prod ucts/gcp/hashicorp-and-google-expand-collaboration-easing-secret-and- infrastructure-management (besucht am 25. 02. 2019) (zitiert auf S. 54). [KBB+09] B. Kitchenham, O. P. Brereton, D. Budgen, M. Turner, J. Bailey, S. Linkman. „Sys- tematic literature reviews in software engineering – A systematic literature review“. In: Information and Software Technology 51.1 (2009). Special Section - Most Ci- ted Articles in 2002 and Regular Research Papers, S. 7–15. issn: 0950-5849. doi: 10.1016/j.infsof.2008.09.009. url: http://www.sciencedirect.com/science/ article/pii/S0950584908001390 (zitiert auf S. 19, 35, 36). [Kit04] B. Kitchenham. „Procedures for Performing Systematic Reviews“. In: Keele, UK, Keele University 33.2004 (2004), S. 1–26 (zitiert auf S. 19). [Kub18] Kubernetes. What is Kubernetes? - Kubernetes. 2018. url: https://kubernetes.io/ docs/concepts/overview/what-is-kubernetes/ (besucht am 01. 03. 2019) (zitiert auf S. 63). [LA18] Limoncelli, T. A. „GitOps: A Path to More Self-service IT“. In: Queue 16.3 (2018), S. 20. issn: 1542-7730. doi: 10.1145/3236386.3237207. url: https://dl.acm.org/ citation.cfm?id=3237207 (zitiert auf S. 58, 60). [Law17] Lawrence Hecht. This Week in Numbers: Serverless Adoption on Par with Containers - The New Stack. 2017. url: https://thenewstack.io/week-numbers-serverless- adoption-par-containers/ (besucht am 20. 02. 2019) (zitiert auf S. 17). [LB16] B. Liston, S. Buliani. Continuous Deployment for Serverless Applications | Amazon Web Services. Dez. 2016. url: https : / / aws . amazon . com / de / blogs / compute / continuous-deployment-for-serverless-applications/ (zitiert auf S. 17, 31). [LKO15] L. E. Lwakatare, P. Kuvaja, M. Oivo. „Dimensions of DevOps“. In: Lecture Notes in Business Information Processing. 2015, S. 212–217. isbn: 9783319186115. doi: 10.1007/978-3-319-18612-2_19. url: http://link.springer.com/10.1007/978-3- 319-18612-2%7B%5C_%7D19 (zitiert auf S. 26). [LRC+18] W. Lloyd, S. Ramesh, S. Chinthalapati, L. Ly, S. Pallickara. „Serverless computing: An investigation of factors influencing microservice performance“. In: Proceedings - 2018 IEEE International Conference on Cloud Engineering, IC2E 2018. IEEE, Apr. 2018, S. 159–169. isbn: 9781538650080. doi: 10.1109/IC2E.2018.00039. url: https://ieeexplore.ieee.org/document/8360324/ (zitiert auf S. 22). [LRLE17] T. Lynn, P. Rosati, A. Lejeune, V. Emeakaroha. „A Preliminary Review of Enterprise Serverless Cloud Computing (Function-as-a-Service) Platforms“. In: 2017 IEEE International Conference on Cloud Computing Technology and Science (CloudCom).

82 Literaturverzeichnis

IEEE, Dez. 2017, S. 162–169. isbn: 978-1-5386-0692-6. doi: 10.1109/CloudCom. 2017.15. url: http://ieeexplore.ieee.org/document/8241104/ (zitiert auf S. 28, 41–43, 98). [Mat] Matthias Jg. GitOps — Comparison Pull and Push – DevOpsLinks – Medium. url: https://medium.com/devopslinks/gitops-comparison-pull-and-push-88fcbaadfe45 (besucht am 27. 02. 2019) (zitiert auf S. 59). [MB17] G. McGrath, P.R. Brenner. „Serverless Computing: Design, Implementation, and Performance“. In: Proceedings - IEEE 37th International Conference on Distributed Computing Systems Workshops, ICDCSW 2017. IEEE, Juni 2017, S. 405–410. isbn: 9781538632925. doi: 10.1109/ICDCSW.2017.36. url: http://ieeexplore.ieee.org/ document/7979855/ (zitiert auf S. 41, 95). [MGZ+17] M. Malawski, A. Gajek, A. Zima, B. Balis, K. Figiela. Serverless execution of scientific workflows: Experiments with HyperFlow, AWS Lambda and Google Cloud. Functions 2017. doi: 10.1016/j.future.2017.10.029. url: https://doi.org/10.1016/j. future.2017.10.029. (zitiert auf S. 41, 109). [MJB+17] G. McGrath, B. Judson, P. Brenner, J. Short, S. Ennis. „Cloud event programming paradigms: Applications and analysis“. In: IEEE International Conference on Cloud Computing, CLOUD. IEEE, Juni 2017, S. 400–406. isbn: 9781509026197. doi: 10.1109/CLOUD.2016.58. url: http://ieeexplore.ieee.org/document/7820297/ (zitiert auf S. 41–43, 95). [MPF18] S. K. Mohanty, G. Premsankar, M. di Francesco. „An Evaluation of Open Source Serverless Computing Frameworks“. In: 2018 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE, Dez. 2018, S. 115– 120. isbn: 978-1-5386-7899-2. doi: 10.1109/CloudCom2018.2018.00033. url: https: //ieeexplore.ieee.org/document/8591002/ (zitiert auf S. 17, 24, 25, 29, 41, 44, 97). [Ope19] Openfaas. openfaas/faas. Feb. 2019. url: https://github.com/openfaas/faas (zitiert auf S. 65). [PICP16] D. Pop, G. Iuhasz, C. Craciun, S. Panica. „Support services for applications execution in multi-clouds environments“. In: Proceedings - 2016 IEEE International Confe- rence on Autonomic Computing, ICAC 2016. IEEE, Juli 2016, S. 343–348. isbn: 9781509016532. doi: 10.1109/ICAC.2016.19. url: http://ieeexplore.ieee.org/ document/7573162/ (zitiert auf S. 41, 108). [Plaa] G. C. Platform. Cloud Functions – Merkmale und Vorteile | Google Cloud. url: https://cloud.google.com/functions/features/ (zitiert auf S. 30). [Plab] G. C. Platform. Events and Triggers | Cloud Functions Documentation | Google Cloud. url: https://cloud.google.com/functions/docs/concepts/events-triggers (zitiert auf S. 30). [Plac] G. C. Platform. Quotas | Cloud Functions Documentation | Google Cloud. url: https://cloud.google.com/functions/quotas (zitiert auf S. 30). [PLB+17] A. Palesandro, M. Lacoste, N. Bennani, C. Ghedira-Guegan, D. Bourge. „Mantus: Putting Aspects to Work for Flexible Multi-Cloud Deployment“. In: IEEE Inter- national Conference on Cloud Computing, CLOUD. Bd. 2017-June. IEEE, Juni 2017, S. 656–663. isbn: 9781538619933. doi: 10.1109/CLOUD.2017.88. url: http: //ieeexplore.ieee.org/document/8030646/ (zitiert auf S. 41, 108).

83 Literaturverzeichnis

[PM13] A. Papaioannou, K. Magoutis. „An Architecture for Evaluating Distributed Appli- cation Deployments in Multi-clouds“. In: 2013 IEEE 5th International Conference on Cloud Computing Technology and Science. IEEE, Dez. 2013, S. 547–554. isbn: 978-0-7695-5095-4. doi: 10.1109/CloudCom.2013.79. url: http://ieeexplore.ieee. org/document/6753845/ (zitiert auf S. 41, 99). [PMM15] A. Papaioannou, D. Metallidis, K. Magoutis. „Cross-layer management of distributed applications on multi-clouds“. In: Proceedings of the 2015 IFIP/IEEE International Symposium on Integrated Network Management, IM 2015. IEEE, Mai 2015, S. 552– 558. isbn: 9783901882760. doi: 10.1109/INM.2015.7140336. url: http://ieeexplor e.ieee.org/document/7140336/ (zitiert auf S. 41, 45, 104). [PRS17] R. Pellegrini, P. Rottmann, G. Strieder. „Preventing vendor lock-ins via an interoperable multi-cloud deployment approach“. In: 2017 12th International Conference for Internet Technology and Secured Transactions (ICITST). IEEE, Dez. 2017, S. 382– 387. isbn: 978-1-908320-93-3. doi: 10.23919/ICITST.2017.8356428. url: https: //ieeexplore.ieee.org/document/8356428/ (zitiert auf S. 23, 41, 46, 109). [PTD+15a] L. M. Pham, A. Tchana, D. Donsez, N. De Palma, V. Zurczak, P. Y. Gibello. „Roboconf: A Hybrid Cloud Orchestrator to Deploy Complex Applications“. In: Proceedings - 2015 IEEE 8th International Conference on Cloud Computing, CLOUD 2015. IEEE, Juni 2015, S. 365–372. isbn: 9781467372879. doi: 10.1109/CLOUD.2015.56. url: http://ieeexplore.ieee.org/document/7214066/ (zitiert auf S. 41). [PTD+15b] L. M. Pham, A. Tchana, D. Donsez, V. Zurczak, P.Y. Gibello, N. De Palma. „An adaptable framework to deploy complex applications onto multi-cloud platforms“. In: Proceedings - 2015 IEEE RIVF International Conference on Computing and Communication Technologies: Research, Innovation, and Vision for Future, IEEE RIVF 2015. IEEE, Jan. 2015, S. 169–174. isbn: 9781479980437. doi: 10.1109/RIVF. 2015.7049894. url: http://ieeexplore.ieee.org/document/7049894/ (zitiert auf S. 41, 101, 102). [Ren16] V. Reniers. „The Prospects for Multi-Cloud Deployment of SaaS Applications with Container Orchestration Platforms“. In: Proceedings of the Doctoral Symposium of the 17th International Middleware Conference on ZZZ - Middleware Doctoral Symposi- um’16. New York, New York, USA: ACM Press, 2016, S. 1–2. isbn: 9781450346658. doi: 10.1145/3009925.3009930. url: http://dl.acm.org/citation.cfm?doid= 3009925.3009930 (zitiert auf S. 41, 93). [Rob18] M. Roberts. Serverless Architectures. 2018. url: https : / / martinfowler . com / articles/serverless.html (besucht am 18. 02. 2019) (zitiert auf S. 17, 18, 21, 22, 29). [Sah19] M. Sahin. sahinM/cloud-agnostic-devops-for-serverless. Feb. 2019. url: https : //github.com/sahinM/cloud-agnostic-devops-for-serverless/ (zitiert auf S. 63, 67). [Sera] I. Serverless. Serverless - The Serverless Application Framework powered by AWS Lambda, API Gateway, and more. url: https://serverless.com/ (besucht am 25. 02. 2019) (zitiert auf S. 50, 52). [Serb] A. W. Services. Limits für AWS Lambda. url: https://docs.aws.amazon.com/de_de/ lambda/latest/dg/limits.html (zitiert auf S. 30).

84 Literaturverzeichnis

[Serc] A. W. Services. Programmiermodell. url: https://docs.aws.amazon.com/de_de/ lambda/latest/dg/programming-model-v2.html (zitiert auf S. 30). [Serd] A. W. Services. Unterstützte Ereignisquellen. url: https://docs.aws.amazon.com/ de_de/lambda/latest/dg/invoking-lambda-function.html (zitiert auf S. 30). [SIV17] S. N. Srirama, T. Iurii, J. Viil. „Dynamic deployment and auto-scaling enterprise applications on the heterogeneous cloud“. In: IEEE International Conference on Cloud Computing, CLOUD. IEEE, Juni 2017, S. 927–932. isbn: 9781509026197. doi: 10.1109/CLOUD.2016.121. url: http://ieeexplore.ieee.org/document/7820375/ (zitiert auf S. 41, 104). [SJ17] J. Spillner, Josef. „Practical Tooling for Serverless Computing“. In: Proceedings of the10th International Conference on Utility and Cloud Computing - UCC ’17. New York, New York, USA: ACM Press, 2017, S. 185–186. isbn: 9781450351492. doi: 10.1145/3147213.3149452. url: http://dl.acm.org/citation.cfm?doid=3147213. 3149452 (zitiert auf S. 18, 25, 41–43, 88). [SS18] M. Sewak, S. Singh. „Winning in the era of Serverless Computing and Function as a Service“. In: 2018 3rd International Conference for Convergence in Technology (I2CT) (Apr. 2018), S. 1–5. doi: 10 . 1109 / I2CT . 2018 . 8529465. url: https : / / ieeexplore.ieee.org/document/8529465/ (zitiert auf S. 17, 18, 28, 29, 41, 42, 96). [SZD+15] M. Slawik, B. I. B. İ. Zilci, Y. Demchenko, J. I. A. Baranda, R. Branchat, C. Loo- mis, O. Lodygensky, C. Blanched, C. Blanchet. „CYCLONE Unified Deployment and Management of Federated, Multi-cloud Applications“. In: Proceedings - 2015 IEEE/ACM 8th International Conference on Utility and Cloud Computing, UCC 2015. IEEE Press, 2015, S. 453–457. isbn: 9780769556970. doi: 10.1109/UCC.2015.81. arXiv: 1607.06688. url: https://dl.acm.org/citation.cfm?id=3233485 (zitiert auf S. 41, 94). [TPM+17] G. Tricomi, A. Panarello, G. Merlino, F. Longo, D. Bruneo, A. Puliafito. „Orchestrated Multi-Cloud Application Deployment in OpenStack with TOSCA“. In: 2017 IEEE International Conference on Smart Computing, SMARTCOMP 2017. IEEE, Mai 2017, S. 1–6. isbn: 9781509065172. doi: 10.1109/SMARTCOMP.2017.7947027. url: http://ieeexplore.ieee.org/document/7947027/ (zitiert auf S. 41, 107). [VJ14] B. Vanbrabant, W. Joosen. „Configuration management as a multi-cloud enabler“. In: Proceedings of the 2nd International Workshop on CrossCloud Systems - CCB ’14. New York, New York, USA: ACM Press, 2014, S. 1–3. isbn: 9781450332330. doi: 10.1145/2676662.2676672. url: http://dl.acm.org/citation.cfm?doid=2676662. 2676672 (zitiert auf S. 41, 45, 92). [Wea] Weaveworks Community. GitOps. url: https://www.weave.works/technologies/ gitops/ (besucht am 27. 02. 2019) (zitiert auf S. 57–59). [Web] WebHooks.org. WebHooks. url: http : / / www . webhooks . org/ (besucht am 28. 02. 2019) (zitiert auf S. 61). [YG16] R. Yasrab, N. Gu. „Multi-cloud PaaS Architecture (MCPA): A Solution to Cloud Lock-In“. In: Proceedings - 2016 3rd International Conference on Information Sci- ence and Control Engineering, ICISCE 2016. IEEE, Juli 2016, S. 473–477. isbn: 9781509025350. doi: 10.1109/ICISCE.2016.108. url: http://ieeexplore.ieee.org/ document/7726205/ (zitiert auf S. 41, 45, 105).

85 Literaturverzeichnis

[ZCTZ13] U. Zdun, R. Capilla, H. Tran, O. Zimmermann. „Sustainable architectural design decisions“. In: IEEE Software 30.6 (2013), S. 46–53. issn: 07407459. doi: 10.1109/ MS.2013.97. url: https://www.infoq.com/articles/sustainable-architectural- design-decisions (zitiert auf S. 59). [Zima] D. Zimine. Notes and thoughts from Serverless Conf – Dmitri Zimine – Medium. url: https://medium.com/@dzimine/notes-and-thoughts-from-serverless-conf- cdfa68d99037 (besucht am 17. 02. 2019) (zitiert auf S. 18, 19). [Zimb] D. Zimine. Serverless is cheaper, not simpler. url: https://medium.freecodecamp. org/serverless-is-cheaper-not-simpler-a10c4fc30e49 (besucht am 18. 09. 2018) (zitiert auf S. 24–26, 28).

Alle URLs wurden zuletzt am 03. 03. 2019 geprüft.

86 A. Datenextraktion der Studien

Tabelle A.1.: Datenextraktion für [AC17] Datenfeld Wert allgemeine Informationen Titel Serverless Computing: Economic and Archi- tectural Impact Autor Gojko Adzic, Robert Chatley Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (884-889) Land Vereinigtes Königreich Serverless & DevOps Probleme und Herausforderungen Markteinführungszeit, lokale Testumgebung, Debugging, Herstellerabhängigkeit (Vendor- Lock-in) Konzepte, Methoden, Modelle Container, Deployment Pipeline, Versionie- rung, A/B Tests Technologien, Tools, Plattformen AWS Lambda, Azure Functions, Google Cloud Functions, IBM OpenWhisk

87 A. Datenextraktion der Studien

Tabelle A.2.: Datenextraktion für [SJ17] Datenfeld Wert allgemeine Informationen Titel Practical Tooling for Serverless Computing Autor Josef Spillner Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 2 (185-186) Land Schweiz Serverless & FaaS: Deployment Probleme und Herausforderungen keine Sprache für Orchestrierung von Micro- services mit Containern und Functions Konzepte, Methoden, Modelle Container-Orchestrierung, anbieterübergreifen- de Abstraktionen, FaaSification Technologien, Tools, Plattformen Serverless Plattformen: Azure Functions, AWS Lambda, Google Cloud Functions, OpenWhisk, Fission, OpenFaaS, IronFunctions, OpenLamb- da, Serverless Framework, PyWren, CD/CI: LambCI

Tabelle A.3.: Datenextraktion für [FCSS15] Datenfeld Wert allgemeine Informationen Titel Continous Deployment of Multi-cloud Systems Autor Ferry, N., Chauvel, F., Song, H., & Solberg, A. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 2 (27-28) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen cloud-spezifische Tools und Sprachen, Teilen von Wissen zwischen unterschiedlichen Clouds Konzepte, Methoden, Modelle modell-basierte Sprache, abstrakt Darstellung des Systems, einheitliches Metamodell, Deploy- ment Engine Technologien, Tools, Plattformen CloudML

88 Tabelle A.4.: Datenextraktion für [DMB18] Datenfeld Wert allgemeine Informationen Titel Building Lean Continuous Integration and Deli- very Pipelines by Applying DevOps Principles: A Case Study at Varidesk Autor Debroy, V., Miller, S., & Brimble, L. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (851-856) Land USA Multi-Cloud & DevOps Probleme und Herausforderungen lange Build-Zeit, Konfigurationsprobleme, Mangel an Tools Konzepte, Methoden, Modelle IaC, Container, Orchestrierung Technologien, Tools, Plattformen Microservices, Docker, Kubernetes, Docker Compose, GCP, AWS

Tabelle A.5.: Datenextraktion für [FSR+14] Datenfeld Wert allgemeine Informationen Titel CloudMF: Applying MDE to Tame the Com- plexity of Managing Multi-Cloud Applications Autor Ferry, N., Song, H., Rossini, A., Chauvel, F., & Solberg, A. Jahr 2014 Typ Konferenzbericht (Conference Proceedings) Seiten 9 (269-277) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle modell-basiert (MDE), models@runtime Pat- tern, Abstraktion durch DSL, IaC Technologien, Tools, Plattformen CloudMF, CloudML, JSON, XML, Cloudify, Chef, Puppet, TOSCA

89 A. Datenextraktion der Studien

Tabelle A.6.: Datenextraktion für [FCS+18] Datenfeld Wert allgemeine Informationen Titel CloudMF: Model-Driven Management of Multi-Cloud Applications Autor Ferry, N., Chauvel, F., Song, H., Rossini, A., Lushpenko, M., & Solberg, A. Jahr 2018 Typ Zeitschriftenartikel (Journal Article) Seiten 24 Land - Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle modell-basiert (MDE), models@runtime Pat- tern, Abstraktion, DSL, Konfigurationsmanage- ment, imperativ und deklarativ Technologien, Tools, Plattformen CloudMF, CloudML, TOSCA, XML, JSON, Puppet, Chef, Cloudify

Tabelle A.7.: Datenextraktion für [BGK+13] Datenfeld Wert allgemeine Informationen Titel Lifecycle Management of Service-based Appli- cations on Multi-Clouds: A Research Roadmap Autor Baryannis, G., Garefalakis, P., Kritikos, K., Ma- goutis, K., Papaioannou, A., Plexousakis, D., & Zeginis, C. Jahr 2013 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (13-20) Land Griechenland Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), Por- tabilität Konzepte, Methoden, Modelle modell-basiert (MDE), Cloud-Abstraktions- Layer, plattformunabhängige und einheitliches IaC, DSL, Monitoring Technologien, Tools, Plattformen CloudML, Amazon CloudFormation, Cloudi- fy, PIM4Cloud DSL, PIM4Cloud, XML, TOS- CA, Amazon CloudWatch, jclouds, Apache libcloud, BPMN, BPEL

90 Tabelle A.8.: Datenextraktion für [FCR+13] Datenfeld Wert allgemeine Informationen Titel Managing multi-cloud systems with CloudMF Autor Ferry, N., Chauvel, F., Rossini, A., Morin, B., & Solberg, A. Jahr 2013 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (38-45) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle modell-basiert (MDE), models@run-time Pattern, Abstraktion, Cloud Provider- spezifisches Modell (CPSM) und Cloud- Provider-unabhängiges modell (CPIM) als Bereitstellungs- und Deploymentmodell, technologieunabhängig, Domain-spezifische Modellierungssprache (DSML) Technologien, Tools, Plattformen CloudMF, CloudML, Cloudify, Chef, Puppet, JSON, AWS, jcloud, Simple Cloud, DeltaCloud

Tabelle A.9.: Datenextraktion für [GCGA15] Datenfeld Wert allgemeine Informationen Titel SPACE4Cloud: A DevOps Environment for Multi-cloud Applications Autor Guerriero, M., Ciavotta, M., Gibilisco, G. P., & Ardagna, D. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 2 (29-30) Land Italien Multi-Cloud & DevOps Probleme und Herausforderungen - Konzepte, Methoden, Modelle modell-basiert zur Design-Zeit, Evaluation von Qualität, QoS Bewertung, Optimierung zur Designzeit, Laufzeit-Kapazität Allokation von Cloud-Anwendungen, vollautomatisches Dis- covery von möglichen Cloud-Angeboten und Konfigurationen, Feedback-Mechanismen Technologien, Tools, Plattformen PCM/MODACloudML (Modellierungsformat)

91 A. Datenextraktion der Studien

Tabelle A.10.: Datenextraktion für [VJ14] Datenfeld Wert allgemeine Informationen Titel Configuration management as a multi-cloud enabler Autor Vanbrabant, B., & Joosen, W. Jahr 2014 Typ Konferenzbericht (Conference Proceedings) Seiten 3 Land Belgien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), Management-Overhead und Skalierbarkeit Konzepte, Methoden, Modelle Abstraktions-Layer, Konfigurationsmanage- ment, Infrastructure as Code (IaC), deklarativ Technologien, Tools, Plattformen Apache JClouds, CFengine, Chef, Puppet, Brooklyn, Amazon OpsWorks

Tabelle A.11.: Datenextraktion für [AKC+15] Datenfeld Wert allgemeine Informationen Titel Business-Oriented Evaluation of the PaaSage Platform Autor Achilleos, A. P., Kapitsaki, G. M., Constantin- ou, E., Horn, G., & Papadopoulos, G. A. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 5 (322-326) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), Inter- operabilität Konzepte, Methoden, Modelle modell-basiert (MDE), deklarativ, Skript- basiert, workflow-basiert Technologien, Tools, Plattformen PaaSage Plattform (modell-basiert), AWS, VM- Ware, OpenStack, RightScale, Apache Brook- lyn, Cloudify, GCE, CloudStack, Docker, OpenShift, IBM Bluemix, CloudFoundry, TOS- CA, YAML, HireFire, Scale Adept, CAMEL (DSL), CloudML

92 Tabelle A.12.: Datenextraktion für [Ren16] Datenfeld Wert allgemeine Informationen Titel The Prospects for Multi-Cloud Deployment of SaaS Applications with Container Orchestrati- on Platforms Autor Reniers, V. Jahr 2016 Typ Konferenzbericht (Conference Proceedings) Seiten 2 Land Belgien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), Or- chestrierung von Ressourcen, Multi-Tenant Möglichkeiten, Konfigurationsmanagement Konzepte, Methoden, Modelle Container-Orchestrierung, deklaratives Konfigurations- und Infrastrukturmanagement Technologien, Tools, Plattformen Docker, Kubernetes, Docker Swarm Apache Mesos

Tabelle A.13.: Datenextraktion für [BIS+14] Datenfeld Wert allgemeine Informationen Titel SeaClouds: A European Project on Seamless Management of Multi-Cloud Applications Autor Brogi, A., Ibrahim, A., Soldani, J., Carrasco, J., Cubo, J., Pimentel, E., & D’Andria Jahr 2014 Typ Zeitschriftenartikel (Journal Article) Seiten 4 (1-4) Land Italien, Spanien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle - Orchestrierung und Adaptierung von Services -Monitoring und Laufzeit-Rekonfiguration von Services - Compliance mit wichtigen Normen über unterschiedliche Cloud-Provider Technologien, Tools, Plattformen TOSCA, Cloud4SOA (Deployment und monitoring von Multi-Cloud Services), Monitoring: Apache DeltaCloud, Rightscale, NewRelic, Ma- nagement: Brooklyn, Apache Whirr, Apache Jclouds, Cloud Application Management for Platforms (CAMP)

93 A. Datenextraktion der Studien

Tabelle A.14.: Datenextraktion für [SZD+15] Datenfeld Wert allgemeine Informationen Titel CYCLONE Unified Deployment and Manage- ment of Federated, Multi-Cloud Applications Autor Slawik, M., Zilci, B. I. B. İ., Demchenko, Y., Baranda, J. I. A., Branchat, R., Loomis, C., … Blanchet, C. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 5 (453-457) Land Deutschland, Holland, Spanien, Schweiz und Frankreich Multi-Cloud & DevOps Probleme und Herausforderungen Interoperabilität, Kompatibilität, Austauschbar- keit Konzepte, Methoden, Modelle Konfigurationsmanagement Technologien, Tools, Plattformen Chef, Puppet, Juju, SlipStream, Cloud Infrast- ructure Management Interface (CIMI), Open Cloud Computing Interface (OCCI), TOSCA, Compose YML

Tabelle A.15.: Datenextraktion für [Elg15] Datenfeld Wert allgemeine Informationen Titel SULTAN: A Composite Data Consistency Ap- proach for SaaS Multi-Cloud Deployment Autor Elgedawy, I Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 10 (122-131) Land Türkei Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), Da- tenkonsistenzprobleme Konzepte, Methoden, Modelle Cloud -Vereinheitlichung, Orchestrierung und Adaption, Service Adapter, Messaging und Pro- tokolle Technologien, Tools, Plattformen SULTAN, XML

94 Tabelle A.16.: Datenextraktion für [MJB+17] Datenfeld Wert allgemeine Informationen Titel Cloud Event Programming Paradigms Autor McGrath, G., Judson, B., Brenner, P., Short, J., & Ennis, S. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 7 (400-406) Land USA Serverless & DevOps Probleme und Herausforderungen Cloud Events erfordern neue Paradigmen der Softwareentwicklung, Inkompatibilität mit traditionellen Tools und Frameworks Konzepte, Methoden, Modelle Abstraktion, Orchestrierung, Container, Moni- toring, Versionierung Technologien, Tools, Plattformen Lambdefy, AWS Lambda, IBM Bluemix Open- Whisk, GCP Cloud Functions, Microsoft Azure Functions, Serverless Framework, Node.js, Ro- boconf, JSON, AWS ECS, AWS CloudWatch, AWS CloudFormation, AWS API Gateway

Tabelle A.17.: Datenextraktion für [MB17] Datenfeld Wert allgemeine Informationen Titel Serverless Computing: Design, Implementati- on, and Performance Autor McGrath, G., & Brenner, P. R. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (405-410) Land USA Serverless & DevOps Probleme und Herausforderungen Sprachensupport Konzepte, Methoden, Modelle Container, nicht-native Sprachen durch Dritt- anbieter, Microservices Technologien, Tools, Plattformen AWS Lambda, Apache OpenWhisk, Azure Functions, Google Cloud Functions, Iron.io IronFunctions, OpenLambda, Docker, Apex, Sparta, Windows Container

95 A. Datenextraktion der Studien

Tabelle A.18.: Datenextraktion für [SS18] Datenfeld Wert allgemeine Informationen Titel Winning in the era of Serverless Computing and Function as a Service Autor Sewak, M., & Singh, S. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 5 (1-5) Land Indien Serverless & DevOps Probleme und Herausforderungen komplizierte Integrationstests und Debugging, mangelndes Tooling für Deployment Manage- ment, Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle Microservices Technologien, Tools, Plattformen Kubeless, Funktion, Fission, AWS Lambda, IBM Cloud Functions, Microsoft Azure Func- tions, Google Cloud Functions, Apache Open- Whisk

Tabelle A.19.: Datenextraktion für [JY18] Datenfeld Wert allgemeine Informationen Titel Architecture Decision on using Microservices or Serverless Functions with Containers Autor Jambunathan, B., & Yoganathan, K. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 7 (1-7) Land Indien Serverless & DevOps Probleme und Herausforderungen komplizierte Integrationstests und Debugging, mangelndes Tooling für Deployment Manage- ment, Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle Microservices, Container Orchestration, Con- tainer Technologien, Tools, Plattformen Docker, AWS Lambda, Kubernetes, Docker Swarm, Mesos, AWS ECS, Azure container services, SCAR Framework

96 Tabelle A.20.: Datenextraktion für [MPF18] Datenfeld Wert allgemeine Informationen Titel An evaluation of open source serverless computing frameworks Autor Mohanty, S. K., Premsankar, G., & di Frances- co, M. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (115-120) Land Finnland Serverless & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle Container, Container-Orchestrierung, Custom Resource Definitions (CRD) als Erweiterung der Orchestrierung für bentuzerdefinierte Funk- tionen Technologien, Tools, Plattformen Fission, Kubeless, OpenFaaS, AWS Lambda, Azure Functions, IBM Cloud Functions, Goog- le Cloud Functions, Apache OpenWhisk, Do- cker, Kubernetes

97 A. Datenextraktion der Studien

Tabelle A.21.: Datenextraktion für [LRLE17] Datenfeld Wert allgemeine Informationen Titel A Preliminary Review of Enterprise Serverless Cloud Computing (Function-as-a-Service) Plat- forms Autor Lynn, T., Rosati, P., Lejeune, A., & Emeaka- roha, V. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (162-169) Land Irland Serverless & DevOps Probleme und Herausforderungen Monitoring und Debugging Tools, deklaratives Deployment, Komposition von Funktio- nen, langlebige Funktionen, Zustandsverwal- tung, Nebenläufigkeit, Wiederherstellungsse- mantiken, Code-Granularität, verteilter Spei- cher Konzepte, Methoden, Modelle Container, Container-Orchestrierung, Microser- vices, Versionierung, Log Management (Moni- toring) Technologien, Tools, Plattformen AWS Lambda, AWS CloudWatch, AWS Step Functions, Google Cloud Functions, GitHub, Visual Studio Team Services, Bitbucket, Goog- le Stackdriver, NuGET, NPM, Azure Func- tions, IBM OpenWhisk, Iron.io, Auth0 Web- task, Webtask Editor, Gestal Laser, Docker, Ku- bernetes, Docker Swarm

98 Tabelle A.22.: Datenextraktion für [HB13] Datenfeld Wert allgemeine Informationen Titel The Hydra: A layered, redundant configuration management approach for cloud-agnostic disaster recovery Autor Huang, K., & Begnum, K. (2013) Jahr 2013 Typ Konferenzbericht (Conference Proceedings) Seiten 4 (333-336) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle Konfigurationsmanagement, automatisierte Fehlererkennung und Wiederherstellung, Clustering Technologien, Tools, Plattformen Puppet, MLN (Manage Large Networks), Glus- terFS

Tabelle A.23.: Datenextraktion für [PM13] Datenfeld Wert allgemeine Informationen Titel An Architecture for Evaluating Distributed Ap- plication Deployments in Multi-Clouds Autor Papaioannou, A., & Magoutis, K. Jahr 2013 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (547-554) Land Griechenland Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), feh- lende Feedback-Schleifen, Monitoring Konzepte, Methoden, Modelle modell-basiert, models@runtime, cloud- unabhängige Klassifizierung von Ressourcen unterschiedlicher Anbieter Technologien, Tools, Plattformen Chef, Puppet, SmartFrog, CloudML, TOSCA, Cloudify, Heroku, Cloudify

99 A. Datenextraktion der Studien

Tabelle A.24.: Datenextraktion für [FRC+13] Datenfeld Wert allgemeine Informationen Titel Towards model-driven provisioning, deployment, monitoring, and adaptation of multi- cloud systems Autor Ferry, N., Rossini, A., Chauvel, F., Morin, B., & Solberg, A. Jahr 2013 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (887-894) Land Norwegen Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), In- kompatibilität, Modellierung von QoS Ein- schränkungen Konzepte, Methoden, Modelle modell-basiert (MDE), models@runtime, DSL, DSML, type-instance Pattern, Cloud Provider- Independent Model (CPIM), Cloud Provider- Specific Model (CPSM), Monitoring, Adapter, Konfigurationsmanagement Technologien, Tools, Plattformen CloudML, Apache CloudStack, Eucalyptus, jclouds, Deltacloud, Simple Cloud, fog, libCloud, Chef, Puppet, Scalr, JSON, XMI, Cloudify

100 Tabelle A.25.: Datenextraktion für [CFN+14] Datenfeld Wert allgemeine Informationen Titel Using Models at Runtime to Support Adaptable Monitoring of Multi-Clouds Applications Autor Cianciaruso, L., Forenza, F. di, Nitto, E. Di, Miglierina, M., Ferry, N., & Solberg, A. Jahr 2014 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (401-408) Land Norwegen, Italien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in) Konzepte, Methoden, Modelle modell-basiert (MDE), models@runtime, Mo- nitoring, Adapter, Konfigurationsmanagement, Abstraktion und Adaption von Systemen Technologien, Tools, Plattformen CloudMF, CloudML, XML, JSON, Amazon Cloudwatch, SNS, Rackspace Monitor, Flexi- ant, JadeCloud

Tabelle A.26.: Datenextraktion für [PTD+15b] Datenfeld Wert allgemeine Informationen Titel An Adaptable Framework to Deploy Complex Applications onto Multi-cloud Platforms Autor Pham, L. M., Tchana, A., Donsez, D., Zurczak, V., Gibello, P. Y., & De Palma, N. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (169-174) Land Frankreich Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor-Lock-in), feh- lende Standards in Cloud APIs, Konzepte, Methoden, Modelle DSL, modell-getrieben (MDE) Technologien, Tools, Plattformen Bash, Puppet, Chef, Cloudify, RightScale, Scalr, EnStratus, CloudML, AMQP, REST, JSON

101 A. Datenextraktion der Studien

Tabelle A.27.: Datenextraktion für [CDR+17] Datenfeld Wert allgemeine Informationen Titel MUSA Deployer: Deployment of Multi-Cloud Applications Autor Casola, V., De Benedictis, A., Rak, M., Villano, U., Rios, E., Rego, A., & Capone, G. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (107-112) Land Italien, Spanien Multi-Cloud & DevOps Probleme und Herausforderungen Identifikation von Cloud-Services bezüglich Anforderungen, Konsistenz Konzepte, Methoden, Modelle Deployment Plan, hohe Abstraktion durch modell-basierte Sprache (basiert auf der Spra- che CAMEL), Risikomanagement durch Too- ling, Infrastructure as Code Technologien, Tools, Plattformen MUSA Deployer tool, Cloudify, Puppet, Chef, JSON, XML

Tabelle A.28.: Datenextraktion für [PTD+15b] Datenfeld allgemeine Informationen Titel Roboconf: A Hybrid Cloud Orchestrator to De- ploy Complex Applications Autor Pham, L. M., Tchana, A., Donsez, D., De Palma, N., Zurczak, V., & Gibello, P. Y. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (365-372) Land Frankreich Multi-Cloud & DevOps Probleme und Herausforderungen - Konzepte, Methoden, Modelle Domain Specific Language (DSL), Deployment Manager, Abstraktion, Messaging Technologien, Tools, Plattformen RightScale, Scalr, Cloudify, Bash, Puppet, OS- Gi, JSON, XML, YAML, REST, Docker Con- tainer, Vagrant, AMQP, ZeroMQ, CloudML

102 Tabelle A.29.: Datenextraktion für [BPR16] Datenfeld allgemeine Informationen Titel Survey of Automated Software Deployment for Computational and Engineering Research Autor Benson, J. O., Prevost, J. J., & Rad, P. Jahr 2016 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (1-6) Land USA Multi-Cloud & DevOps Probleme und Herausforderungen - Konzepte, Methoden, Modelle Infrastructure-as-Code (IaC) Technologien, Tools, Plattformen Chef, SaltStack, Ansible, Bash, Blender, Juju, OpenStack Heat, YAML, ZeroMQ, SSH

Tabelle A.30.: Datenextraktion für [BSG+18] Datenfeld allgemeine Informationen Titel A Provider-agnostic Approach to Multi-cloud Orchestration using a Constraint Language Autor Baur, D., Seybold, D., Griesinger, F., Masata, H., & Domaschka, J. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 173-182 (10) Land Germany, Czech Republic Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle Service Discovery, Object Constraint Language (OCL) (einschränken von Ressourcen), Model- lierungssprache Technologien, Tools, Plattformen TOSCA, Cloudify

103 A. Datenextraktion der Studien

Tabelle A.31.: Datenextraktion für [SIV17] Datenfeld allgemeine Informationen Titel Dynamic Deployment and Auto-scaling Enter- prise Applications on the Heterogeneous Cloud Autor Srirama, S. N., Iurii, T., & Viil, J. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 927-932 (6) Land Estland Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in), unterschiedliche Deployment-Mechanismen Konzepte, Methoden, Modelle DSL, models@runtime, modell-basiert Technologien, Tools, Plattformen CloudML, CloudMF, AWS CloudFormation, Google Cloud Deployment Manager, JSON, jclouds, Simple Cloud, DeltaCloud, Cloudify, Chef, Puppet

Tabelle A.32.: Datenextraktion für [PMM15] Datenfeld allgemeine Informationen Titel Cross-layer Management of Distributed Appli- cations on Multi-Clouds Autor Papaioannou, A., Metallidis, D., & Magoutis, K. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 552-558 (7) Land Griechenland Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in), Man- gel an Multi-Cloud Provisionierungs und De- ployment Frameworks, Service Discovery, dy- namische Provisionierung Konzepte, Methoden, Modelle deklarativ, Konfigurationsmanagement, Ma- nagement von Cross-Layer Abhängigkeiten, DSL, Infrastructure-as-Code (IaC) Technologien, Tools, Plattformen TOSCA, OpenTOSCA, SmartFrog, jClouds, Cloudify, dasein, boto, Chef

104 Tabelle A.33.: Datenextraktion für [GG18] Datenfeld Wert allgemeine Informationen Titel DevOps Reference Architecture for Multi- Cloud IOT Applications Autor Ghantous, G. B., & Gill, A. Q. Jahr 2018 Typ Konferenzbericht (Conference Proceedings) Seiten 10 (158-167) Land Australien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle CI-Broker Technologien, Tools, Plattformen CloudMF, TOSCA, AWS CodeDeploy, BitBu- cket, Codeship

Tabelle A.34.: Datenextraktion für [YG16] Datenfeld Wert allgemeine Informationen Titel Multi-Cloud PaaS Architecture (MCPA): A So- lution to Cloud Lock-in Autor Yasrab, R., & Gu, N. Jahr 2016 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (343-348) Land China Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle Standardisierungen Technologien, Tools, Plattformen (P-)TOSCA, jClouds, mOSAIC, OCCI, XML, Opscode-Chef

105 A. Datenextraktion der Studien

Tabelle A.35.: Datenextraktion für [EBM16] Datenfeld Wert allgemeine Informationen Titel Towards Automated Cost-efficient Data Ma- nagement for Federated Cloud Services Autor Emeakaroha, V. C., Bullman, M., & Morrison, J. P. Jahr 2016 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (158-163) Land Irland Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle Messaging Bus, Interoperabilität Technologien, Tools, Plattformen XML, CSV, JSON, HashMap, ArrayList, BSON, MessagePack, Hessian, CBOR

Tabelle A.36.: Datenextraktion für [DAFP15] Datenfeld Wert allgemeine Informationen Titel Model-Driven Design of Cloud Applications with Quality-of-Service Guarantees: the MO- DAClouds Approach Autor Da Silva, M. A. A. D., Ardagna, D., Ferry, N., & Pérez, J. F. Jahr 2015 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (3-10) Land Frankreich, Italien, Norwegen, Vereinigtes Kö- nigreich (UK) Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigeit (Vendor Lock-in) Konzepte, Methoden, Modelle Model-Driven Development (MDD), DSL Technologien, Tools, Plattformen CloudML

106 Tabelle A.37.: Datenextraktion für [ALKH17] Datenfeld Wert allgemeine Informationen Titel Enabling End-to-End Orchestration of Multi- Cloud Applications Autor Alexander, K., Lee, C., Kim, E., & Helal, S. Jahr 2017 Typ Journal Artikel Seiten 14 Land Südkorea, USA Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigeit (Vendor Lock-in) Konzepte, Methoden, Modelle deklarative Spezifikation durch Policies, DSL, MDE Technologien, Tools, Plattformen TOSCA, CAMP, YAML, XML, JSON, OpenTosca, Cloudify, Alien4cloud, Ubicity, SeaClouds, BPEL, BPMN, Apache Brooklyn, AWS OpsWorks, AWS Cloudformation

Tabelle A.38.: Datenextraktion für [TPM+17] Datenfeld Wert allgemeine Informationen Titel Orchestrated multi-cloud application deployment in OpenStack with TOSCA Autor Tricomi, G., Panarello, A., Merlino, G., Longo, F., Bruneo, D., & Puliafito, A. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (1-6) Land Italien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigeit (Vendor Lock-in) Konzepte, Methoden, Modelle Broker Technologien, Tools, Plattformen TOSCA, REST, YAML, BPMN, BPEL

107 A. Datenextraktion der Studien

Tabelle A.39.: Datenextraktion für [PLB+17] Datenfeld Wert allgemeine Informationen Titel Mantus: Putting Aspects to Work for Flexible Multi-Cloud Deployment Autor Palesandro, A., Lacoste, M., Bennani, N., Ghedira-Guegan, C., & Bourge, D. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 8 (656-663) Land Frankreich Multi-Cloud & DevOps Probleme und Herausforderungen - Konzepte, Methoden, Modelle IaC, DSL, Aspect-oriented Programming (AOP), Mantus Technologien, Tools, Plattformen TOSCA, TOSCA Manipulation Language (TML), YAML, CloudMF, Cloudify

Tabelle A.40.: Datenextraktion für [PICP16] Datenfeld Wert allgemeine Informationen Titel Support Services for Applications Execution in Multi-Clouds Environments Autor Pop, D., Iuhasz, G., Craciun, C., & Panica, S. Jahr 2016 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (343-348) Land Rumänien Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle modell-getrieben, models@runtime, Container Technologien, Tools, Plattformen REST, Chef, Puppet, JSON, XML

108 Tabelle A.41.: Datenextraktion für [PRS17] Datenfeld Wert allgemeine Informationen Titel Preventing vendor lock-ins via an interoperable multi-cloud deployment approach Autor Pellegrini, R., Rottmann, P., & Strieder, G. Jahr 2017 Typ Konferenzbericht (Conference Proceedings) Seiten 6 (382–387) Land Österreich Multi-Cloud & DevOps Probleme und Herausforderungen Herstellerabhängigkeit (Vendor Lock-in) Konzepte, Methoden, Modelle Container, Container-Orchestrierung Technologien, Tools, Plattformen Kubernetes, Docker, LXC, Microservices, YAML, Juju

Tabelle A.42.: Datenextraktion für [MGZ+17] Datenfeld Wert allgemeine Informationen Titel Serverless execution of scientific workflows: Experiments with HyperFlow, AWS Lambda and Google Cloud Functions Autor Malawski, M., Gajek, A., Zima, A., Balis, B., & Figiela, K. Jahr 2017 Typ Journal Artikel Seiten 13 Land Polen Serverless & DevOps Probleme und Herausforderungen - Konzepte, Methoden, Modelle Container, Versionierung, Bridge model, master/worker, queue Technologien, Tools, Plattformen AWS Lambda, Google Cloud Functions, Micro- soft Azure Functions, IronFunctions, Docker, Picasso, JSON

109

B. Synthetisieren der Daten

Tabelle B.1.: Synthetisieren der Daten für FF1 Serverless/FaaS und CI/CD Probleme/Herausforderun- Anzahl Studien zusätzliche Informationen gen (evtl. Lösungsvorschläge, Alternativen) Vendor Lock-in 5 Abstraktion lokales Testen/Integrations- 4 A/B Tests, Versionierung tests, Debugging Support von Laufzeit/Spra- 4 Abstraktionen, FaaSification, chen für Orchestrierung von Container-Orchestrierung Funktionen Tool-Mangel für Deployment 7 Containerisierung, Container- Orchestrierung Komposition von Funktionen 1 Container-Orchestrierung Wiederherstellungssemanti- 1 Versionierungstools wie Git- ken Hub, VSTS, BitBucket

111 B. Synthetisieren der Daten

Tabelle B.2.: Synthetisieren der Daten für FF2 Serverless/FaaS and CI/CD

Konzepte, Methoden, Modelle Anzahl Studien Abstraktion 3 Container-Orchestrierung 5 Container 10 Versionierung 3 Monitoring 2 Technologien, Tools, Plattformen Anzahl Studien Serverless Framework 2 LambCI, Jenkins 1 AWS CloudFormation 1 Container-basierte FaaS: Apache OpenWhisk, 11 IronFunctions, OpenLambda, OpenFaaS, Ku- beless, Fission, ... Container-Orchestration: Kubernetes, Docker 6 Swarm, Mesos, ... SCAR-Framework 2 VCS: GitHub, BitBucket, Visual Studio Team 1 Services, ... TOSCA 1

112 Tabelle B.3.: Synthetisieren der Daten für FF3 Multi-Cloud und CI/CD

Konzepte, Methoden, Modelle Anzahl Studien modell-basierte Sprachen, MDE, models@run- 14 time abstrakte Darstellung des Systems 9 Containerisierung und Orchestrierung 5 Infrastructure-as-Code (IaC) 7 Konfigurationsmanagement 9 Microservices 2 Service Discovery 3 Domain Specific Language (DSL) 10 Cloud Broker 2 Technologien, Tools, Plattformen Anzahl Studien CloudML, CloudMF 13 IaC-Tools wie Chef, Puppet, Juju, AWS Cloud- 17 Formation, AWS OpsWorks TOSCA basierte Technologien (Cloudify, 15 BPEL, ...) Docker, Docker Compose, AWS ECS 5 Kubernetes, Docker Swarm, Apache Mesos 3 Roboconf 1 Formate wie JSON, XML, YAML 12 REST 4 Abstraktions-Tools (Apache jClouds, Delta- 7 Cloud, Apache Brooklyn, ...) AWS CodeDeploy 1

113

C. Suchphrasen der SLR

Abbildung C.1.: Suchphrase 1 (FF1)

UND

ODER ODER

Continuous Delivery deployment ODER concept approach method model

Serverless Function as a Service Abbildung C.2.: Suchphrase 2 (FF1)

UND

ODER ODER

Continuous Delivery deployment ODER tool technology framework platform

Serverless Function as a Service

Abbildung C.3.: Suchphrase 3 (FF1)

UND

ODER ODER deployment pipeline delivery pipeline ODER concept approach method model

Serverless Function as a Service

Abbildung C.4.: Suchphrase 4 (FF1)

UND

ODER ODER deployment pipeline delivery pipeline ODER tool technology framework platform

Serverless Function as a Service Abbildung C.5.: Suchphrase 5 (FF1)

UND

ODER ODER configuration Infrastructure IaC ODER tool technology framework platform

Serverless Function as a Service

Abbildung C.6.: Suchphrase 6 (FF2)

UND

ODER ODER

Continuous Delivery deployment ODER problem challenge issue

Serverless Function as a Service

Abbildung C.7.: Suchphrase 7 (FF3)

UND

ODER ODER continuous delivery deployment ODER concept approach method model

multi-cloud cloud-agnostic cloud-neutral Abbildung C.8.: Suchphrase 8 (FF3)

UND

ODER ODER continuous delivery deployment ODER tool technology platform framework

multi-cloud cloud-agnostic cloud-neutral Erklärung

Ich versichere, diese Arbeit selbstständig verfasst zu haben. Ich habe keine anderen als die angegebenen Quellen benutzt und alle wörtlich oder sinngemäß aus anderen Werken übernommene Aussagen als solche gekennzeichnet. Weder diese Arbeit noch wesentliche Teile daraus waren bisher Gegenstand eines anderen Prüfungsverfahrens. Ich habe diese Arbeit bisher weder teilweise noch vollständig veröffentlicht. Das elektronische Exemplar stimmt mit allen eingereichten Exemplaren überein.

Ort, Datum, Unterschrift