Fakultät für Informatik - iteratec...Fakultät für Informatik Studiengang Informatik (Master) Transformation einer internen Anwendung in einen digitalen Service Master Thesis von

Fakultät für Informatik

Studiengang Informatik (Master)

Transformation einer internen Anwendung in einen digitalenService

Master Thesis

von

Martin Krumscheid

Datum der Abgabe: 09.01.2018Erstprüfer: Prof. Dr. Gerd BenekenZweitprüfer: Prof. Dr. Korbinian Riedhammer

Erklärung

Ich versichere, dass ich diese Arbeit selbständig angefertigt, nicht anderweitig fürPrüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfs-mittel benützt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnethabe.

Rosenheim, den 09.01.2018

Martin Krumscheid

Kurzfassung

Die iteratec GmbH hat für ihre 20-Jahr-Feier eine Anwendung konzipiert, um eine einfa-che Möglichkeit zu bieten, für alle Teilnehmer Informationen bereitzustellen. Sie wurde soerweitert, dass sie ebenfalls für andere Veranstaltungen nutzbar ist. Durch den erhöhtenEinsatz und Präsenz der Anwendung wurde von mehreren Seiten Interesse gezeigt, dieseauch für externe Veranstaltungen zu nutzen. Da die Anwendung bisher nur für den un-ternehmensinternen Betrieb konzipiert ist, muss eine Alternative betrachtet werden. Ausunternehmensspezifischen Gründen soll der Betrieb nicht auf den internen Servern weiter-geführt werden. Eine Betrachtung für den Betrieb innerhalb einer Cloud ist wegen ihrerFähigkeit zur Skalierung und hohen Verfügbarkeit sinnvoll. Das Ziel dieser Arbeit ist dieAnalyse der notwendigen Schritte um eine Anwendung in die Cloud zu transferieren undwie sie anschließend weiter aufgeteilt werden kann.

Der bisherige Backend-Server wurde mit Spring Boot geschrieben und basiert auf einerRessource und Service Architektur. Die Anwendung läuft, neben anderen Anwendungen, aufeiner internen Serverinstanz in einem Container. Als Ausführungsplattform wurde die AWSCloud ausgewählt. In der neuen Architektur sollen verschiedene Anforderungen berück-sichtigt werden, die auch teilweise im Konflikt zueinander stehen. Der erste Schritt ist dieTransformation der vollständigen Anwendung in die Cloud ohne dabei große Änderungenvornehmen zu müssen.

Anschließend findet eine Entkopplung der statischen Webseiten statt. Damit das Backend-System vollständig auf die Logikverarbeitung ausgelegt ist und die Seiten modularer ak-tualisiert werden können. Eine Ersetzung der MySQL Datenbank durch eine DynamoDBermöglicht eine flexiblere Skalierung durch Kapazitätseinheiten. Des Weiteren kann mitCloudWatch sowie der Skalierung die bestehende Anwendung mit weiteren Diensten ausge-baut werden. Wobei letzteres durch verschiedene Möglichkeiten umsetzbar ist.

Die Anwendung kann für einen optimalen Cloud Einsatz noch weiter optimiert werden,wenn eine Betrachtung der Last generierenden Bereiche durchgeführt wird. Dabei treten diedrei Felder statische, teilweise dynamische und dynamische Daten für eine Optimierungdes Monolithen hervor. Die statischen Daten wurden bereits entkoppelt. Durch die Nutzungvon CloudFront und Lambda Funktionen als AWS Dienste können Architekturen aufgebautwerden, welche die letzten beiden Typen von Daten behandeln. Durch weitere Extraktionender monolithischen Funktionalität wird automatisch eine Microservice Architektur erzeugt.

Letztendlich können nicht alle gestellten Anforderungen gleichzeitig erfüllt werden. Dennmanche stehen im Widerspruch zueinander, so ist z.B. keine Reduzierung der Kosten mög-lich, wenn weitere Dienste von Amazon hinzugefügt werden. Aber über die kompletteAnalyse der Arbeit sind alle Anforderungen erfüllt worden.

Schlagworte: AWS, Cloud, Microservice, Lambda, iteraKonf, API Gateway, Amazon

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation und Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Cloud Grundlagen 52.1 Abgrenzung zwischen Virtualisierung, Containerisierung und Serverless . . 52.2 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Beschreibung der bestehenden Architektur 113.1 Eingesetzte Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Architekturaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Entwicklungs- und Deploymentprozess . . . . . . . . . . . . . . . . . . . . . . 20

4 Auswahl des Cloud Dienstleisters 23

5 Technische Anforderungen an die Architektur 27

6 Minimal Viable Product 316.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Virtual Private Cloud (VPC) . . . . . . . . . . . . . . . . . . . . . . . . 316.1.2 Security Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1.3 AWS Certificate Manager (ACM) . . . . . . . . . . . . . . . . . . . . . . 336.1.4 Elastic Load Balancing (ELB) . . . . . . . . . . . . . . . . . . . . . . . . 346.1.5 Route 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Vorbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.1 Dateispeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.2 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.4 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.5 Multimandantenfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.6 Preisberechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Ausbau der Architektur mit weiteren Diensten 477.1 Entkopplung der statischen Webseiten . . . . . . . . . . . . . . . . . . . . . . . 477.2 Alternative für die Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . 50

7.2.1 Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2.2 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.3 CloudWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

i

7.4 Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.4.1 Manuell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.2 Automatisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.4.3 EC2 Container Service (ECS) . . . . . . . . . . . . . . . . . . . . . . . . 60

8 Aufteilung der monolithischen Architektur in kleinere Segmente 658.1 Die Anwendung als Datenbezugspunkt . . . . . . . . . . . . . . . . . . . . . . 65

8.1.1 Aufteilung in mehrere Server . . . . . . . . . . . . . . . . . . . . . . . . 668.1.2 AWS Dienste als Alternative . . . . . . . . . . . . . . . . . . . . . . . . 67

8.2 Analyse des verbleibenden Funktionsumfangs . . . . . . . . . . . . . . . . . . 708.2.1 Konfiguration von Microservice und Lambda Funktionen . . . . . . . 718.2.2 ECS Service Discovery für Microservices . . . . . . . . . . . . . . . . . 738.2.3 Feature: Fragen und Bewertungen . . . . . . . . . . . . . . . . . . . . . 768.2.4 Feature: Push Benachrichtungen . . . . . . . . . . . . . . . . . . . . . . 808.2.5 Feature: Daten Verwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 81

8.3 Resultierende Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9 Validierung der Anforderung 85

10 Fazit 87

A Datenbank Modell 89

Glossar 91

Literatur 93

ii

Abbildungsverzeichnis

1.1 Umsatz mit Cloud Computing im B2B-Bereich in Deutschland . . . . . . . . . . 2

2.1 Aufbau einer virtualisierten Maschine . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Aufbau einer Betriebssytem Virtualisierung mithilfe von Docker Containern . . 72.3 Schematische Darstellung der Docker-Engine . . . . . . . . . . . . . . . . . . . . . 82.4 Abstraktionsebenen für Virtualisierung, Containerisierung und Serverless . . . . 9

3.1 Anteile der nativen, hybriden und mixed Entwicklung . . . . . . . . . . . . . . . 123.2 Rangliste für die meistgenutzten Plattformen einer Anwendung . . . . . . . . . . 123.3 Rangliste für den Einsatzbereich einer Anwendung . . . . . . . . . . . . . . . . . 133.4 Architekturübersicht über die angeschlossenen Systeme . . . . . . . . . . . . . . 143.5 Anwendungsfall-Diagramm mit den Grundlegenden Funktionen . . . . . . . . . 153.6 Cordova Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.7 Backend-Layer Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.8 Deployment Struktur des Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.9 Git-Branch Nutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.10 Erweiterter Jenkins Prozess für den Build-Prozess . . . . . . . . . . . . . . . . . . 22

4.1 Umsatzentwicklung von Amazon Web Services . . . . . . . . . . . . . . . . . . . 244.2 Aufteilung der IaaS Cloud Betreiber in Quadranten . . . . . . . . . . . . . . . . . 244.3 Marktanteile am weltweiten Cloudgeschäft . . . . . . . . . . . . . . . . . . . . . . 25

6.1 AWS VPC mit Internet Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326.2 iteraKonf Jenkins Pipeline für das AWS Deployment . . . . . . . . . . . . . . . . 406.3 Workflow für das Cloud Deployment auf eine EC2 Instanz . . . . . . . . . . . . . 416.4 Anwendungsstruktur des MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 Darstellung der neu angebundenen Amazon Web Services (AWS) Dienste . . . . 487.2 Verteilung der Requests für statischen Inhalt . . . . . . . . . . . . . . . . . . . . . 487.3 Request Routing mit CloudFront als HTTPS Endpunkt . . . . . . . . . . . . . . . 507.4 Zugriff auf S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.5 CloudWatch System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.6 Aufbau des Amazon EC2 Container Services . . . . . . . . . . . . . . . . . . . . . 607.7 Schematischer Aufbau für ein ECS Deployment . . . . . . . . . . . . . . . . . . . 62

8.1 Lastverteilung auf dem Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.2 Neuer Systemaufbau für teilweise dynamische Daten . . . . . . . . . . . . . . . . 678.3 Aufgabenbereich des Monolithen nach der Anbindung an Amazon Dienste . . . 708.4 Architektur für die Konfiguration von Microservices . . . . . . . . . . . . . . . . 718.5 Darstellung der Microservices Discovery anhand von Amazon Diensten . . . . . 748.6 Architektur für die Nutzung von Netflix Eureka . . . . . . . . . . . . . . . . . . . 758.7 Vereinfachte Darstellung der Architektur mit einem Microservice für die Fragen 77

iii

8.8 Vereinfachte Darstellung der Architektur mit Lambda Funktionen für die Fragen 788.9 Vereinfachte Darstellung der Integration des Microservice für Push Benachrichti-

gungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.10 Vereinfachte Architektursicht auf die drei entkoppelten Bereiche des ehemaligen

Monolithen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818.11 Endgültiger Architekturaufbau mit den genutzten Diensten . . . . . . . . . . . . 82

A.1 Darstellung der Datenbankstruktur als Enitity-Relationship Modell . . . . . . . . 89

iv

1 Einleitung

Die iteratec GmbH ist seit über 20 Jahren im IT Projektgeschäft, sowie der Architektur-und Technologieberatung tätig. In dieser Zeit ist das Unternehmen stetig gewachsen undhat mittlerweile rund 300 Mitarbeiter, die sich auf acht verschiedene Standorte (fünf inDeutschland, Wien, Zürich, Breslau) verteilen.

Die Anwendung iteraKonf wurde in erster Linie für die 20 Jahr Feier von iteratec entwickelt.Aber über das Jahr verteilt werden wiederholt Weiterbildungs- oder Informationsveranstal-tungen für Mitarbeiter und Besucher durchgeführt. Durch das Potenzial von iteraKonf wareine Weiterentwicklung sinnvoll, denn dadurch können mehrere Veranstaltungen zu unter-schiedlichen Zeitpunkten eingetragen werden. Die Anwendung ist auch vielen Besuchernpositiv aufgefallen, wodurch manche bereits Interesse daran bekundet haben.

Die Anwendung besitzt eine Vielzahl an Funktionen, die den Besuch einer Veranstaltungerleichtern. Sie bietet eine Übersicht und zusätzliche Detailinformationen, wie bspw. denReferenten oder ein Abstract über die Vorträge. Gleichzeitig auch eine Sammlung von In-formationen oder wichtigen Veranstaltungsorten auf Google Maps. Die aktuellste Versionbesitzt ein Feature, dass es erlaubt während eines Vortrags Fragen zu stellen und die bereitsgestellten Fragen zu bewerten. Dadurch wird eine interaktive Fragerunde für die Vorträgeermöglicht.

1.1 Motivation und Zielsetzung

Auf den bisherigen Veranstaltungen wurde von verschiedenen externen Besuchern Interessean der Anwendung bekundet. Eine vergleichbare Anwendung mit einer solchen Funktio-nalität ist nicht aufzufinden. Das führt aber zu dem Problem, dass iteratec immer mehrals Produktentwickler wahrgenommen wird und weniger durch das Kerngeschäft der Pro-jektdienstleistung. Deshalb soll u.a. eine Rückbesinnung auf den Markenkern von iteratecdurchgeführt werden. Das hat zur Folge, dass neue Produkte in einem neuen Geschäftsum-feld bzw. Subunternehmen ausgegliedert werden müssen. Bei einem solchen Schritt sindviele verschiedene unternehmensspezifische Annahmen zu berücksichtigen. In dieser Arbeitwird sich jedoch auf die preisliche Bedeutung und die Änderung der Architektur für eineAnwendung konzentriert.

Durch die Analyse einer Transformation der internen Anwendung in einen jederzeit änder-baren digitalen Service kann eine Entscheidungsempfehlung entwickelt werden, ob sichdieses Vorgehen lohnt oder an welchen Stellen nachträgliche Arbeiten notwendig sind. DieseEntscheidungsgrundlage kann auf andere Projekte übertragen werden und somit als Hilfebei der Beratung von Kunden dienen, die ähnliche Probleme oder Notwendigkeiten haben.Gleichzeitig wird mit der Arbeit ein Fachwissen für die Transformation angeeignet, das fürspätere Projekte sinnvoll eingesetzt werden kann.

1

1 Einleitung

Abbildung 1.1 Umsatz mit Cloud Computing im B2B-Bereich in Deutschland von 2011 bis 2015 undPrognose für 2020 (in Milliarden Euro) [it]

Für diese Arbeit wird ein Wechsel in die Cloud Infrastruktur betrachtet, weil somit dieNotwendigkeit entfällt eigene Hardware teuer einzukaufen und zu betreiben. Gleichzeitigist das Geschäft in der Cloud ein stark wachsender Markt, wie es die Abbildung 1.1 darstellt.Der Umsatz mit Cloud Computing nimmt stetig zu und wird weiter wachsen. Durch dieseArbeit wird somit Fachwissen für ein zukünftiges Einsatzgebiet erzeugt.

Neben der Entscheidungsgrundlage soll in dieser Arbeit auch eine mögliche Architek-tur für den Cloud Betrieb der iteraKonf Anwendung erarbeitet werden. Anhand dieser sindnotwendige Änderungen an der Anwendung aufzuzeigen.

1.2 Aufbau der Arbeit

Zunächst wird in Kapitel 2 ein grundsätzliches Verständnis für die Unterscheidung zwischenVirtualisierung, Containerisierung und der Serverless Architektur gelegt. Ebenso wird dasThema MicroServices beleuchtet, um hier die Terminologie und Charakteristiken abzu-grenzen. Auf ein umfassendes Grundlagenkapitel mit den Erläuterungen zu eingesetztenDiensten wurde an dieser Stelle verzichtet, um einen besseren Überblick zu gewährleisten.Die Erläuterungen zu den Diensten befinden sich in den jeweiligen Kapiteln. Die Auswahldes genutzten Cloud Anbieters wird in Kapitel 4 erläutert.

In Kapitel 3 wird anschließend beschrieben, wie die bestehende Anwendung aufgebaut undzusammengesetzt ist, damit ein Verständnis der durchgeführten Änderungen entsteht. DasKapitel 5 listet die wichtigsten Anforderungen an die neue Architektur auf und beschreibtwarum diese entscheidend sind.

Für den Cloud Betrieb wird weiterhin in Kapitel 6 ein Minimal Viable Product erstellt

2

1.2 Aufbau der Arbeit

um die Anwendung möglichst schnell und kostengünstig in der Cloud zu betreiben undso einen Lernzyklus anzustoßen. Anschließend werden in Kapitel 7 weitere Dienste für dieAnwendung hinzugefügt, die eine bessere Überwachung, Logging und auch eine Autos-kalierung ermöglichen. Dort wird ebenfalls beschrieben wie die Webseiten vom Backendextrahiert und separiert werden können. In Kapitel 8 wird eine Analyse durchgeführt, um dieStellen mit der höchsten Last zu ermitteln. Es werden verschiedene Möglichkeiten für eine Ar-chitektur vorgeschlagen, um die einzelnen Bereiche der Anwendung voneinander zu trennen.

Im darauffolgenden Kapitel 9 wird überprüft, inwieweit die entstandene Architektur diegestellten Anforderungen umsetzen. Zuletzt wird im Kapitel 10 eine Handlungsempfehlunggetroffen, ob dieses Vorgehen sinnvoll und umsetzbar ist.

3

4

2 Cloud Grundlagen

In diesem Kapitel wird auf eine Differenzierung der Begriffe Virtualisierung, Containe-risierung und einer Serverless Architektur unterschieden. Ebenso wird die MicroserviceTerminologie mit ihren Charakteristiken dargelegt.

2.1 Abgrenzung zwischen Virtualisierung, Containerisierung undServerless

Die Virtualisierung ist ein wichtiger Aspekt bei der optimalen Ausnutzung eines vorhan-denen Servers und ein wichtiger Teil der heutigen Cloud-Infrastruktur. Weil viele Servernur auf den Betrieb eines Betriebssystems und einer Anwendung ausgelegt sind, entstehtdabei häufig nur eine Last zwischen 5 - 15%. Um die Effizienz der Rechenkapazität zuerhöhen, kann die Virtualisierung weitere Systeme simulieren. Diese sind dabei im Sinnedes Betriebssystems und der Anwendung vollständig isoliert zueinander. Die notwendigeHardware für die einzelnen Systeme wird von einer sehr kleinen Schicht Software, demsogenannten Hypervisor, abstrahiert und simuliert dargestellt [VMw] [Sch14]. Durch dieVirtualisierung lassen sich auf einem physischen Server mehrere virtuelle Server-Instanzenbetreiben um eine höhere Auslastung des Servers zu erreichen. In dieser Arbeit hat derHypervisor dieselbe Bedeutung wie Virtual Maschine Monitor (VMM).

Abbildung 2.1 soll diesen Zusammenhang verdeutlichen. Die unterste Ebene stellt dieHardware für die virtuellen Server zur Verfügung. Darauf aufbauend verwaltet die Softwa-reschicht des Hypervisors die Ressourcen der Hardware. Über diesem liegen die virtuellenMaschinen. Jede Maschine besitzt ein eigenes Gast Betriebssystem, eigene Binaries/Biblio-theken und die auszuführende Anwendung.

Bei der Virtualisierung wird zwischen verschiedenen Arten unterschieden. Typ-1 wird auchals „Bare Metal“ oder Vollvirtualisierung bezeichnet und realisiert die Virtualisierung direktauf der Hardware (vgl. Abbildung 2.1). Der Typ-2 wird mithilfe eines Host-Betriebsystemsrealisiert und deswegen häufig „hosted“ oder „Paravirtualisierung“ bezeichnet [Hof10].

Die Virtualisierung erfüllt verschiedene Eigenschaften [VMw]:

1. PartionierungEin physikalischer Server erlaubt das Ausführen von mehreren Betriebssystemen zurgleichen Zeit. Dafür werden die notwendigen Ressourcen zwischen den virtuellenMaschinen aufgeteilt.

2. IsolationAuf der Hardwareebene ist eine Fehler- und Sicherheitsisolation zwischen den Maschi-nen vorhanden. So lassen sich physische Seiteneffekte, welche die einzelnen Maschinenbetreffen, vermeiden.

5

2 Cloud Grundlagen

Abbildung 2.1 Aufbau einer virtualisierten Maschine [Docb]

3. KapselungDie virtuelle Maschine ist gänzlich in Dateien oder im Dateiformat abgespeichert. Diesführt dazu, dass ein Kopieren oder Verschieben der Maschinen möglich ist.

4. Hardwareunabhägigkeit (Entkopplung)Die Maschine ist vollständig von der physischen Hardware entkoppelt. Sie kann aufunterschiedlichen physikalischen Systemen genutzt werden.

Containerisierung

Neben den genannten Virtualisierungen existiert die Betriebssystem-Virtualisierung als eineweitere Möglichkeit. Viele Anwender beschreiben fälschlicherweise diese Art Virtualisierungals leichtgewichtige VMs. Das liegt daran, dass viele der Eigenschaften übereinstimmen.Allerdings unterscheidet sich das Konstrukt einer containerbasierten Virtualisierung imAufbau. In Abbildung 2.1 findet sich der Aufbau einer virtuellen Maschine visuell dargestellt.Abbildung 2.2 zeigt eine andere Struktur für die Virtualisierung.

Die Containerisierung benötigt keinen Hypervisor, sondern ein Host Betriebssystem. Inner-halb dessen wird eine Container Runtime aufgebaut, z.B. Docker, welche für die Verwaltungder Container zuständig ist. Die Container selbst besitzen keine eigenen Gast-Betriebssystemewie bei den virtuellen Maschinen. Sie beinhalten lediglich die notwendigen Binaries undBibliotheken für den Betrieb des Containers sowie die auszuführende Anwendung. DerVorteil einer Containerisierung liegt in dem verringerten Overhead der Virtualisierung. DieVoll- und Paravirtualisierung benötigt ein vollständiges Gast-Betriebssystem, das einer fes-ten Ressourcenzuteilung von Prozessor, Arbeitsspeicher und Festplattenspeicher unterliegt.Dabei ist es unerheblich ob das System diese aktuell wirklich nutzt. Bei den Containernhingegen, werden die darunterliegenden Ressourcen über alle Container geteilt, so dassdieser nur noch die notwendigen Dateien benötigt, damit die Anwendung läuft. Die Start-geschwindigkeit eines Containers ist außerdem deutlich höher, da auf einem bestehendenGastsystem gearbeitet wird [Doc16] [Goo].

6

2.1 Abgrenzung zwischen Virtualisierung, Containerisierung und Serverless

Abbildung 2.2 Aufbau einer Betriebssytem Virtualisierung mithilfe von Docker Containern [Docb]

Docker als Container Laufzeitumgebung

Docker beschreibt dabei u.a. die Container Laufzeitumgebung, indem die Container aus-geführt werden. Laut der Open Container Initiative wird das Docker Image als der defacto Standard für Container bezeichnet [The]. Der Abschnitt basiert, falls nicht andersgekennzeichnet, auf der Dokumentation von Docker [Doca].

Ein wichtiger Teil des Docker Systems sind die Dockerfiles. Diese beschreiben den vollständi-gen Aufbau eines Containers. Die Containerstruktur besteht aus verschiedenen Layern. JederBefehl der innerhalb eines solchen Dockerfiles genutzt wird, erzeugt dabei einen eigenenLayer. Es ermöglicht außerdem, dass der Container über das Dockersystem erzeugt und an-schließend ausgeführt bzw. in ein Repository übertragen wird. Es existiert ein Dockerhub indem bereits viele vorgefertigte Images vorhanden sind. Diese können ohne großen Aufwandals verwendete Layer eingebunden werden.

Wenn ein Container gestartet wird, entsteht durch Docker ein zusätzlicher Layer auf demStack des Images. Nur dieser Layer ist beschreibbar und wird innerhalb des Containersstandardmäßig als Ablage genutzt. Änderungen der Dateien an den darunterliegenden Lay-ern sind nicht direkt möglich, stattdessen werden diese Dateien in den writeable Containerkopiert, geändert und von dort aus genutzt. Wenn die Ausführung des Containers stoppt,wird der oberste Layer wieder gelöscht. Dadurch besitzen die Container keine dauerhaftePersistenz. Diese kann nur erreicht werden, wenn vom Host-System ein Dateisystem mitdem Container verbunden wird.

Docker verwaltet die Container über eine Docker-Engine (vgl. Abbildung 2.3). Diese bestehtaus drei großen Komponenten. Der Server, auch docker daemon genannt, ist ein dauerhaftlaufender Prozess der die Container, Images, Netzwerk und das Dateisystem verwaltet. Überdie REST API wird eine Kommunikation mit dem Serverdienst ermöglicht. Durch das ClientCommand Line Interface (CLI) kann mit dem Docker System kommuniziert werden. SowohlClient als auch Server können auf derselben Instanz oder getrennt voneinander betrieben

7

2 Cloud Grundlagen

Abbildung 2.3 Schematische Darstellung der Docker-Engine [Doca]

werden. Mit der CLI kann über einen Remote Zugriff auf entfernte Server zugegriffen werden.

Diese Infrastruktur ist optimal dafür geeignet Microservices umzusetzen, da jeder Con-tainer isoliert agieren kann. Durch schnelles herunterfahren und neu starten des Containerskönnen andere Versionen erzeugt werden.

Serverless

Die Informationen in diesem Abschnitt stammen von [Sba17], [Rob] als auch von den Web-seiten der drei großen Cloud Anbieter [Amab],[LLCc],[Corb].Unter Serverless versteht man die Abstraktion der vollständigen Serverinfrastruktur durchDritte. Dieses Konzept wird häufig auch als Function-as-a-Service (FAAS) bezeichnet. DerAnwendungsentwickler kann den serverseitigen Code erstellen und sich so auf seine Kernauf-gaben konzentrieren. Der entwickelte Code kann veröffentlicht werden, ohne sich Gedankendarüber zu machen, wie die genutzte Infrastruktur aufgebaut ist.

Sowohl die Konfiguration, das Management und die Wartung fällt nicht mehr in die Zustän-digkeit des Entwicklers, sondern wird vollständig vom Betreiber übernommen. Dadurchwird Zeit und Geld gespart. Allerdings wird auch die Abhängigkeit von einem Anbietererhöht, da die Implementierungen meist noch zusätzliche Dienste des Anbieters nutzt unddiese bei einem Wechsel der Plattform berücksichtigt werden müssen. Dies wird auch VendorLock genannt. Ein großer Vorteil einer Serverless Architektur ist die einfache Skalierung undFlexibilität. Der Anbieter passt die bereitgestellte Infrastruktur an die benötigten Funktions-aufrufe an. Sie können auch die entstehenden Kosten reduzieren, denn diese entstehen nurfür die tatsächliche Nutzung und nicht dem Bereithalten. Damit die Funktionen von außenals Endpunkt angesehen werden können, wird ein API Gateway benötigt. Dieses reagiert aufAnfragen und führt die entsprechende Funktion aus.

8

2.2 Microservices

Abbildung 2.4 Abstraktionsebenen für Virtualisierung, Containerisierung und Serverless[McK16][modifiziert]

Verglichen mit der Virtualisierung und Containerisierung abstrahiert die Serverless Architek-tur vollständig die Infrastruktur. In Abbildung 2.4 ist der Unterschied grafisch dargestellt.Durch Nutzung von Funktionen entscheidet sich der Entwickler keinen Einfluss auf dieInfrastruktur zu besitzen, damit wird auch die Möglichkeit genommen eine Serveroptimie-rung durchzuführen. Aus dem fehlenden Einfluss resultiert, dass nicht jede Anwendungauf Basis der Serverless Architektur umsetzbar ist, wenn bspw. auf ein Service Level Agree-ment (SLA) geachtet werden muss. Gleichzeitig erhöht ein Schritt zur Dezentralisierungdie Komplexität der Anwendung selbst, bewirkt aber im Gegenzug eine Vereinfachung desDeploymentprozesses.

2.2 Microservices

Für diesen Abschnitt dienen die drei Bücher [New15],[Ama17b],[RV16] und [Ama17b], [Fow]als Grundlage.

Wird eine Google Trend Auswertung [LLCa] betrachtet, ist in den letzten Jahren das Inter-esse an Microservices deutlich gestiegen. Dabei ist dies keine revolutionäre Entwicklung.Denn der Begriff entwickelte sich auf Basis der bestehenden Bereiche wie bspw. ContinuousDelivery und Skalierung. Die Bedeutung Microservice ist nicht genau definiert. Deswegenwird häufig eine Beschreibung mithilfe von Definitionen der Charakteristiken eines Micro-services versucht. Der Konsens bezeichnet Microservices als kleine, autonome Dienste diemiteinander interagieren können. Dabei ist die Definition von „klein“ für jeden Serviceunabhängig festzulegen. Aber jeder sollte sich auf den entsprechenden Kontext des Einsatz-bereichs konzentrieren, häufig wird in diesem Zusammenhang der Begriff Bounded Contextverwendet.

9

2 Cloud Grundlagen

Charakteristiken

Dem Begriff Microservice liegt ein Modularisierungskonzept zugrunde, was der Teile-und-herrsche Technik entspricht. Dabei wird versucht ein großes Softwaresystem in kleinereModule zu zerlegen. Jedes Modul soll dabei genau eine spezielle Funktionalität anbieten.Durch die Kommunikation mit anderen Microservices entsteht somit ein verteiltes System,bei dem jedes Element eigenständig aktualisiert und verändert werden kann. Das führt auchdazu, dass jeder Service schnell durch eine andere Version ausgetauscht werden kann. Dadie Services isoliert voneinander operieren und nur über eine Application ProgrammingInterface (API) interagieren, entsteht eine Heterogenität in der jeweils verwendeten Techno-logie. So kann für die Problemstellung jedes Services die optimale Lösung erreicht und auchneue Technologien schneller eingeführt werden.

Daneben haben Microservices noch weitere Vorteile in den Bereichen Ausfallsicherheitund Skalierung. Bei einem Ausfall einer monolithischen Anwendung kommt es dazu, dassdas gesamte System nicht erreichbar ist. Fällt jedoch ein Microservices aus, kann nur die-se Funktionalität nicht weiter genutzt werden, die restliche Anwendung ist davon nichtbetroffen und arbeitet ordnungsgemäß weiter. Die Skalierung wiederum, ermöglicht daspräzise Skalieren eines Teils der Anwendung ohne das unnötige Bereiche davon betroffensind. Durch die gezieltere Skalierung wird die Ausnutzung der Hardware optimiert.

Bisher wurden einige Charakteristiken angesprochen, die einen Microservices beschrei-ben. Es gibt allerdings nicht nur positive, sondern auch negative Aspekte. Durch die verteilteAnwendung wird die Komplexität der Struktur und Interaktion untereinander deutlicherhöht. Je mehr Microservices entstehen, desto höher wird die Komplexität. Auch die Feh-lersuche ist erschwert, weil es aufwendiger ist, den Fehlerursprung zu finden. Gleichzeitigentstehen neue Fehlerquellen bspw. in der Netzwerkinfrastruktur, da alle Microservices mit-einander kommunizieren müssen. Ebenso kann hier das CAP-Theorem genannt werden. DasTheorem besagt, dass von den drei Eigenschaften (C)onsistency, (A)vailability und (P)artiontolerance ein Verteiltes System maximal zwei Eigenschaften gleichzeitig erfüllen kann [GL02].

Die hier genannten Aspekte sind mitnichten vollständig und sollen nur einen grobenÜberblick bieten. Sie führen aber zu der Aussage, dass ein Microservice eine hohe Kohäsionund eine lose Kopplung darstellen soll.

10

3 Beschreibung der bestehenden Architektur

In diesem Kapitel wird auf die bestehende Anwendung eingegangen und es wird dargestelltaus welchen Frameworks das Frontend und Backend besteht. Anschließend wird die aktuelleArchitektur beschrieben um ein Verständnis für das Konzept und die weitere Aufteilung zuerzeugen.

3.1 Eingesetzte Frameworks

Ionic

Für das Frontend wird Ionic als Open-Source SDK des Unternehmens Drifty Co. verwendet.Es bietet durch Cordova eine Cross-Plattform-Funktionalität mit der dieselbe Code Basis fürviele verschiedene Systeme wie z.B. für Android, iOS, Windows genutzt werden kann. Durchüber 120 verschiedener nativer Plugins können auch viele plattformspezifische Funktionengenutzt werden z.B. Bluetooth, GPS, Gyroskop usw. Ionic bietet dafür einen Wrapper, derdie nativen Plugins vereint und in einer Smartphone-Anwendungen auf einfache Weisebereitstellt. Als Frontend Technologie wird Angular eingesetzt und erreicht dadurch, unterder Einschränkung, dass nicht alle Funktionen von Angular in Ionic genutzt werden (z.B.Routing), eine sehr große Support Community [Dria].

Ionic besitzt an dem Zeitpunkt der Erarbeitung rund 31000 GitHub Sterne [Gita] undknapp 11500 Fragen zu Ionic 2 auf StackOverflow [Staa]. Als direkter Vergleich dient Nati-veScript mit rund 11000 Sternen [Gitb] und knapp 3000 Fragen [Staa], was auf eine höhereBeliebtheit für Ionic hindeutet.

Durch die große Anzahl von Plugins kann die Anwendung viele native Funktionen nutzen.Das Testen auf realen Geräten wird dadurch jedoch unumgänglich, da viele Plugins nichtim Browser, sondern nur auf den Geräten funktionsfähig sind. Auch wenn die Pluginsden Funktionsumfang deutlich erhöhen, wird gleichzeitig auch das Potential für weitereProbleme erhöht. Bei der Kompilierung und beim Testen muss dabei immer sehr genau dieFunktion des Plugins überprüft werden. Plugins können sich auch gegenseitig beeinträchti-gen, deshalb sollte die Anzahl der verwendeten Plugins aufgrund potentieller Konflikte inBezug auf ihre Abhängigkeiten möglichst gering gehalten werden.

Zwischen Februar und Juni 2017 wurde eine Entwicklerumfrage gestartet in dem die IonicCommunity auf allgemeine Fragen wie die native, hybride oder gemischte Entwicklung aberauch zu den Gewohnheiten von Entwickler befragt wurden. Außerdem sind weitere Fragenin den Kategorien Backend-Technologie, Tools und Testing als auch Meta Informationen(Ionic Version, Zielplattform etc.) gestellt worden. Mehr als 13000 Entwickler haben an dieserUmfrage teilgenommen und erzeugt somit einen guten Überblick über die verschiedenenThemen [Drib]. Die Umfrage zeigt einen Wandel von der nativen, hin zu der hybriden Ent-wicklung. Das Resultat ist in Abbildung 3.1 abgebildet. 2015 gaben rund 20% der Entwickler

11


Abbildung 3.1 Anteile der nativen, hybriden und gemischten Entwicklung der Ionic Community imZeitraum 2015-2017 und 2017-2019 [Drib]

Abbildung 3.2 Rangliste für die meistgenutzten Plattformen einer Anwendung [Drib]

an native Anwendungen zu entwickeln. Diese Zahl hat sich in den letzten zwei Jahren von20% auf unter 3% verringert. Wohingegen sich die Entwicklung als Hybrid-System im Wachs-tum befindet. Rund 32% der Befragten gaben an, dass sie vermutlich die komplette nativeEntwicklung in den nächsten zwei Jahren aufgeben. Diese Zahlen sind nicht allgemeingültig,sondern beschreiben die Meinung der Mitglieder, die Ionic kennen oder einsetzen und nichtdie generelle Entwicklung von z.B. nativen Anwendungen.

Android und iOS sind die zwei Plattformen für welche die meisten Anwendungen geschrie-ben werden (vgl. Abbildung 3.2). Android nimmt dabei mit fast 95% die Spitzenpositionein, etwas abgeschlagen davon folgt iOS mit rund 83% der Anwendungen. Darunter zählennicht die Android/iOS Tablets. Diese sind separat als dritte Kategorie zusammengefasst, fürdie nur noch 45% der Anwendungen entwickelt wird. Daraus ist ersichtlich, dass Ionic fürüberwiegend Smartphone Anwendungen genutzt wird.

In Abbildung 3.3 wird eine Übersicht über die verschiedenen Einsatzgebiete von Ionicgezeigt. Die Umfrage zeigt, dass die Entwickler nicht nur an Verbraucheranwendungenarbeiten (61%), sondern auch an Anwendungen für den internen Unternehmenseinsatz

12

3.1 Eingesetzte Frameworks

Abbildung 3.3 Rangliste für den Einsatzbereich einer Anwendung [Drib]

(41%). Dort wo die bestehenden Systeme durch modernere ersetzt werden und mehr aufMobile Anwendungen geachtet wird.

Spring Boot

Das Backend ist als Spring Anwendung geschrieben. Grundsätzlich ist das Spring Frame-work sehr umfangreich, umständlich zu konfigurieren und besitzt eine steile Lernkurve[Atk14][Web15]. Mit Spring Boot wird das Konzept Convention over Configuration, auch alsCoding by Convention bezeichnet, für Spring umgesetzt [Pria]. Anhand der Konventionen(z.B. Namensschema) innerhalb eines Projekts wird die Konfiguration des Frameworksautomatisch durchgeführt. Das senkt erheblich die notwendigen Arbeiten und die Anzahlzu treffender Entscheidungen, weil sich die Konfiguration auf Teile beschränkt, die nicht inder Konvention enthalten sind. Somit wird die Entwicklung von neuen Funktionen durchwenige Annotationen bereits deutlich schneller umgesetzt, als es mit vielen Zeilen XMLBeschreibung möglich gewesen wäre [YT15]. Spring Boot ermöglicht eine vollständige Au-tokonfiguration der Spring Suite und eine weitergehende Konfiguration über Annotationdirekt im Code. Dadurch entfällt das Aufteilen und Verteilen von XML-Dateien vollständig.

Es kann somit auf einfache und schnelle Weise eine Stand-Alone Anwendung aufgebautwerden ohne dabei auf Features von Spring verzichten zu müssen und den erhöhten Konfi-gurationsaufwand zu betreiben. Die erzeugte Anwendung muss nicht als WAR-File deployedwerden. Ebenfalls ist dafür kein eigenständiger Application-Server notwendig, da dieser imFramework eingebettet ist. Als eingebettete Server stehen Tomcat-, Jetty- oder Undertow-Server (abhängig von der Konfiguration) bereit, der die Anwendung ausführt. Zusätzlichkönnen spezielle Endpunkte angeboten werden um verschiedenste Metriken und Zuständeder Anwendung auszulesen, so dass externe Monitoring Programme feststellen können obder Server noch funktionsfähig ist.

Spring Boot ermöglicht die Nutzung der in Spring enthaltenden Prinzipien der Depen-dency Injection und Repositories. Ersteres wird genutzt um die Verknüpfung zwischenverschiedenen Klassen über eine Annotation durchzuführen und so die Initialisierung zuumgehen. Dadurch entstehen die Klassen standardmäßig als Singleton Beans. Repositoriesvereinfachen den Umgang mit der Datenbank, denn sie abstrahieren die komplette Daten-bank Kommunikation. Dadurch wird notwendiger Boilerplate Code vermieden [Prib]. In denProperties von Spring müssen dafür nur die Verbindungsinformationen hinterlegt sein, dannübernimmt Spring die Verwaltung der Datenbankverbindungen. Ein großer Vorteil eines sol-chen Repository liegt in der Möglichkeit, eigene Abfragen zu definieren ohne dabei wirklich

13


Abbildung 3.4 Architekturübersicht über die angeschlossenen Systeme mit Request und ResponseIndikatoren [eigene Darstellung]

SQL schreiben zu müssen. Die notwendige SQL Abfrage wird aus der Namensgebung derMethode abgeleitet und soll so SQL Fehlerquellen vermeiden. Außerdem wird durch dasKonzept der Profiles das Konfigurations-Management für unterschiedliche Umgebungenvereinfacht. Dabei wird immer das gleiche Artefakt verwendet, die Umgebungskonfigurationwird mittels Parameter angegeben.

3.2 Architekturaufbau

In diesem Abschnitt werden die Architekturen des vorhandenen Frontends und Backends,welche unter stark vereinfachten Anforderungen für einen internen Firmendienst erstelltwurden, erläutert.

Abbildung 3.4 zeigt eine Übersicht der angebundenen Dienste und deren Kommunika-tionsverbindungen untereinander. Als zentrales Element ist das Backend über Spring Bootrealisiert. Daran angebunden ist eine MySQL-Datenbank über Spring Boot Data, das Light-weight Directory Access Protocol (LDAP) von iteratec über Javax Naming, eine API fürTwitter über die Erweiterung Spring Social Twitter und ebenso eine über Rest mittels JSONangesprochene Wetter API von OpenWeatherMap bzw. Darksky.net.

Neben dem Backend existiert das auf Ionic basierende Frontend. Dieses besteht aus deriteraKonf Anwendung und dem Administrator Interface. Beide Frontends kommunizierenüber Rest-Schnittstellen mit dem Backend, wobei der Adminbereich mit JWT authentifiziertsein muss. Für den initialen Verbindungsaufbau der App zum Backend wird nur der Kon-ferenz Code benötigt, durch den die Id ermittelt und in den folgenden Requests genutzt wird.

Um über Änderungen zu informieren und Daten zu übermitteln wird auf das Push System

14


Abbildung 3.5 Vereinfachtes und zusammengefasstes Anwendungsfall-Diagramm mit den Grundle-genden Funktionen der Anwendung [eigene Darstellung]

von den Betriebssystemen Android und iOS gesetzt. Dafür wird als Basis Google Firebasegenutzt, welches die Versendung von Benachrichtigungen an Android und iOS ermöglicht.Letzteres nur nachdem die Zertifikate dafür in Firebase eingetragen wurden. Über einemPost-Request an die Rest-Schnittstelle von Firebase werden Benachrichtigungen an die Geräteverschickt.

Dafür müssen sich die Geräte bei Firebase registrieren und erhalten darüber ein Tokenüber welches sie referenziert werden können. Dieses Token wird dem Backend zur Verfü-gung gestellt. Wenn es in einer Benachrichtigung enthalten ist, sendet Firebase direkt andie Android-Systeme eine Benachrichtigung und für iOS wird diese über den Apple PushNotification Service geschickt.

Abbildung 3.5 zeigt verschiedenen Anwendungsfälle, die in der Anwendung umgesetztsind. Wegen der Lesbarkeit sind sie stark vereinfacht und zusammengefasst dargestellt. Aufder linken Seite sind die Anwendungsfälle, welche nur vom Konferenz Besucher benötigtwerden. Mittig zu erkennen sind Anwendungsfälle, die für Besucher und Administratornotwendig sind und die auf der rechten Seite sind für den Administrator.

Der Client hat eine Vielzahl von verschiedenen Funktionen innerhalb der Anwendung.Er kann bei Fragerunden mitmachen und Fragen bewerten, dadurch erhalten die Besucherdie Möglichkeit aktiv an der Veranstaltung teilzunehmen. Ebenso können die Galerie undNachrichten Bilder als Thumbnail oder Vollbild angezeigt werden. Diese sind nach demersten Aufruf auf dem Gerät gespeichert und müssen nicht erneut angefordert werden,falls das Bild nochmal geöffnet wird. Ähnlich verhält es sich mit Dateien die von einzelnenVorträgen heruntergeladen werden können.

Daneben gibt es zusätzlich für den Administrator viele Funktionen wodurch die Datenvon Konferenzen oder Referenten gepflegt werden können. Auch kann er bei einer Fragerun-de Fragen schließen, d.h. als beantwortet markieren, oder einzelne Abstimmungen löschen.Der Administrator sieht ebenfalls alle Informationen, kann aber beispielsweise nicht aktiv aneiner Abstimmung teilnehmen.

15


Abbildung 3.6 Cordova Architektur [Fou]

3.2.1 Frontend

Ionic basiert sehr stark auf Angular, deshalb ist die Struktur in den Projekten sehr ähnlich zuder einer Angular 2 Webanwendung. Innerhalb eines src-Ordners wird die Anwendung alsCode beschrieben, dabei werden in Unterordnern zwischen Pages, Services, Providern undKomponenten unterscheiden. Die Ordner „platform“ und „plugins“ liegen auf derselbenEbene wie der src-Ordner und sind einer der Hauptunterschiede zu einer normalen AngularAnwendung. In den „plugins“ Ordner werden die notwendigen Plugins heruntergeladenund gespeichert. Der „platform“ Ordner enthält die installierten Plattformen. Wenn eineinstalliert wird, werden die notwendigen Plugins, wenn nicht vorhanden, heruntergeladenund kompiliert in dem Ordner gespeichert. Daneben gibt es noch weitere wichtige Dateiendie vorhanden sein müssen damit die Anwendung für die verschiedenen Betriebssystemefunktionsfähig ist. In der config.xml werden die Eigenschaften und Werte, z.B. Android-Permissions, für die Plattformen beschrieben.

Cordova bietet einem die Möglichkeit eine herkömmliche Webanwendung bestehend ausHTML, CSS und JS-Dateien in einer nativen Anwendungsform (d.h. apk oder ipa) zu er-stellen. Crodova erstellt dafür einen Wrapper der alle notwendigen Teile beinhaltet. DieseAnwendungen können in den AppStores angeboten oder über den manuellen Installations-weg installiert werden.

In Abbildung 3.6 ist die High-Level Abstraktion von Cordova ersichtlich. Die Kompo-nente der HTML Rendering Engine (WebView) übernimmt dabei die Darstellung der WebApp. Sie kann mit den nativen Funktionen des mobilen Betriebssystems interagieren und

16


Repositories MySQL

Web-App Hybrid-App Admin-UI

ResourcenServices

Presentation

Business Logic

Data

Security

Abbildung 3.7 Backend-Layer Architektur [eigene Darstellung]

hat darüber Zugang zur Sensorik oder anderen Diensten. Die Standard-Engine wird vomBetriebssystem bereitgestellt. Je nach System kann es aber sein, dass diese nicht ausreichendist, weil bestimmte Funktionen nicht gegeben sind (z.B. WebRTC). Deshalb gibt es andereProjekte wie z.B. Crosswalk oder WkWebViewEngine die dem Projekt hinzugefügt werdenkönnen. Bei der Anwendungsinstallation werden diese mit installiert und ersetzten dieStandard-Engine des Betriebssystems bei der Ausführung. Die Web-App Komponente bein-haltet den eigentlichen Code der Anwendung die in HTML, CSS und Javascript geschriebenist.

3.2.2 Backend

Für ein Verständnis der Backend Struktur wird in Abbildung 3.7 ein Layerdiagramm darge-stellt. Im Presentationlayer sind die Oberflächen eingegliedert. Alle besitzen eine Verbindungzu den REST-Ressourcen des Backends. Diese dienen dadurch als öffentliche Schnittstelleum Anfragen von den Oberflächen zu beantworten. Die Web-App und Admin Oberflächewerden beide als statische Webseiten auf dem Backend Server bereitgestellt. Sobald die Da-teien zur Verfügung gestellt wurden, sind die Oberflächen grundsätzlich ohne Verbindungzu dem Webserver nutzbar und erzeugen keine weitere Last auf diesem. Die Webseiten,geschrieben als Single-Page-Applikationen nutzen anschließend die Rest-Ressourcen desBackends um Daten zu erhalten.

Ressourcen stellen somit den zentralen Einstiegspunkt des REST-Backends dar. Diese sindin zwei verschiedenen Klassen aufgeteilt. In der ersten (Konferenz-Schnittstelle) werdenverschiedene Methoden beschrieben, die in erster Linie dafür dienen, Daten an die Anwen-dungen auszuliefern. Als zweite Klasse wird eine Administrator-Ressource (Administrator-Schnittstelle) beschrieben. In dieser sind die Update- und Create-Methoden um die Daten-veränderung durchzuführen.

17


Abbildung 3.8 Deployment Struktur des Backend Docker Containers auf einem Linux Host System[eigene Darstellung]

Die Ressourcen selbst beinhalten jedoch nicht die eingesetzte Logik der Aufgabe, sonderndienen als Annahmepunkt der Anfrage und als Deklaration der Schnittstelle mit Endpunktund Http-Methode. Sie rufen die entsprechenden Methoden in den Services auf, in denendie eigentliche Logik ausgelagert ist. Die verschiedenen Aufgaben des Backends werdenin unterschiedlichen Services realisiert. Es gibt beispielsweise einen für das Ausliefern vonInformationen zu einer Konferenz oder einen Push-Service über den, mit einem Datenobjekt,Push-Benachrichtigungen an die Devices oder Websockets geschickt werden können. Durchdas Spring Boot Framework wird mithilfe der Dependency-Injection ein Service mit derRessource verbunden. Dafür müssen die Services mit einer @Service Annotation versehensein.

Die Daten von der Anwendung werden in einer MySQL-Instanz gespeichert. In dem Data-layer wird die Logik durch die Repositories von Spring Boot deutlich vereinfacht. Es ist nichtmehr notwendig eigene Abfragen über Datenbank Manager oder ähnlichem zu schreiben,da dieses Vorgehen von Spring abstrahiert wird. Dependency-Injection hilft auch an dieserStelle mit der Verbindung zwischen Repository und dem entsprechenden Services.

Ein weiterer Punkt in Abbildung 3.7 betrifft den Bereich Sicherheit im Business LogicLayer. Dort wird die Sicherheitskonfiguration des Applikationservers durchgeführt. Dabeiwird mithilfe von Spring die WebConfig des Tomcats so umgestellt, dass Anfragen an dieAdministrator-Schnittstellen authentifiziert sein müssen. Gleichzeitig aber Anfragen an dieKonferenz-Schnittstelle nur der Bedingung unterliegen, dass die ID in der URL korrekt seinmuss. Diese kann nur vom Backend angefordert werden, wenn ein bestimmtes Attribut der

18


Konferenz richtig ist. Ebenfalls sind die statischen Webseiten von den Sicherheitsrichtlinienausgeschlossen, sodass jeder auf die Seiten zugreifen kann.

Die Zugriffsbeschränkung für den Administrator wird über einen Filter geregelt. Überdiesen wird überprüft, ob eine Anfrage an die Ressource einen gültigen Wert im Authenti-cation Header besitzt. Nur mit einem gültigem Wert ist der Zugriff auf die Ressource möglich.

Abbildung 3.8 zeigt wie die Struktur der Anwendung auf dem Ziel-System aussieht. Inner-halb eines Server wird das Betriebssystem Linux Ubuntu 16.04 LTS ausgeführt. Innerhalbdes Betriebssystems läuft ein Docker System mit einem Daemon der die Container verwaltet.

Die Anwendung läuft in einem Docker Container in dem Java 8 als Execution-Environmentgenutzt wird. Die gestartete Anwendung läuft in einem eingebetteten Tomcat Server. Nebendieser Anwendung laufen noch parallel andere Container mit den verschiedensten Anwen-dungen. Deshalb wird bei dem Anwendungsdocker-Container der interne Port 10009 aufden externen Port 8888 umgelenkt und ist somit von außen erreichbar. Die Anwendung imContainer kann über die Server IP-Adresse mit dem Port 8888 erreicht werden.

3.2.3 Datenbank

Als Datenbank dient eine MySQL-Instanz. Basierend auf dem Principle of Least Privilege,bei dem ein Benutzer nur die minimalen Rechte zugewiesen bekommt, ist ein Benutzer fürdie iteraKonf-Datenbank erstellt worden. Dies erhöht den Schutz für die Daten und Funktio-nalität gegenüber böswilligem Verhalten. Denn sollten der Benutzername und das Passwortkompromittiert sein, wird der Schaden auf die Bereiche beschränkt für die der Benutzerdie Berechtigungen besitzt. Dadurch sollten die Informationen auf anderen Datenbankengeschützter sein [SS75].

Die Datenbankverbindung wird im Backend über Properties gesetzt. Spring besitzt da-für vorgefertigte Schlüsselpaare (Verbindungs-URL, Benutzername, Passwort und der JDBCTreiber) die in der entsprechenden Datei eingetragen werden müssen.

Die Abbildung A.1 zeigt die aktuelle Datenstruktur auf der Datenbank und die Bezie-hung zwischen den verschiedenen Entitäten. Die conference und speaker Entitäten sindalleinstehend und ein solcher Datensatz beinhaltet keine Constraints. Daneben existierennoch viele Entitäten die entweder einen Fremdschlüssel auf conference oder speechbesitzen.

Mithilfe des Migrationstool Flyway kann auf Änderungen in den Entitäten auf Daten-bankebene dynamisch reagiert werden. Durch das Tool ist keine manuelle Anpassungder Datenbank für die verschiedenen Entwicklungs-, Test- und Produktivsystemen mehrnotwendig. Es bietet die Möglichkeit Skripte mit einer Nummer auszustatten um so eineVersionierung zu erreichen. Da nur eine Abhängigkeit zu Flyway benötigt wird, um eineIntegration in Spring Boot zu erreichen, kann das Tool sehr einfach in Betrieb genommenwerden. Die Skripte müssen dafür nur im richtigen Verzeichnis des Ressource Ordners liegen.

Sobald Spring startet, wird Flyway aufgerufen und vergleicht anschließend die vorhan-denen Skripte mit denen aus der Flyway Tabelle. Wenn neue Skripte erkannt werden, sind

19


master

production

feature_1

feature_2

nicht persistent

persistent

Abbildung 3.9 Im GitLab werden zwei persistente Branches genutzt. Dabei zählt der Master-Branchals Entwicklungszweig und der Production als Zweig für die Produktivumgebung. Vom Masterwerden für die einzelnen Features Branches erstellt, die bei Abschluss zurück in den Master gemergedwerden. Der wiederum wird in den Produktion-Zweig gemerged. [eigene Darstellung]

diese auszuführen. Sobald ein Skript ausgeführt ist, wird ein neuer Eintrag in der Tabelle er-zeugt. Bei Migrationsfehlern wird die Anwendung nicht gestartet und der Datenbankeintragwird von Flyway als nicht erfolgreich gekennzeichnet. Die Prüfung beschränkt sich aber nichtnur auf den Abgleich von neuen Skripten, sondern die bestehenden Skripte werden ebenfallsüberprüft. Dies geschieht durch den Vergleich der Hashwerte von den einzelnen Skripten.Sollte der Wert zwischen Datenbanktabelle und Skript nicht übereinstimmen, wird einFehler von Flyway erzeugt und die Anwendung startet nicht. Dadurch sollen nachträglicheÄnderungen an Skripten nicht zu einer Inkonsistenz der Datenbank führen.

3.3 Entwicklungs- und Deploymentprozess

Für die Entwicklung des Projekts wird auf GitLab als zentrales Repository und Jenkinsals Build-Platform gesetzt. Die Struktur in GitLab ist wie in Abbildung 3.9 umgesetzt. Esexistieren zwei persistente Branches die nicht wieder gelöscht werden. Der ProduktionBranch enthält den aktuellen Zustand der im Live-Betrieb eingesetzt wird. Dieser ist explizitvom Master Branch getrennt, da er als Development Zweig genutzt wird und sich täglichändern kann. Durch diese Trennung kann gewährleistet werden, dass nur vorher getesteteZustände in den Live-Betrieb gehen. Neben diesen zwei Branches werden während derEntwicklung weitere Zweige erstellt. Diese Feature-Branches sind allerdings nicht persistentund werden nach Vollendung der Aufgabe in den Master-Branch gemerged. Sobald derMerge erfolgreich durchgeführt wurde, wird der erstellte Feature-Branch wieder gelöscht.An dieser Stelle bedeutet nicht persistent, dass sie nicht dauerhaft existieren, sondern nursolange das Feature in Entwicklung ist.

Beim Erzeugen von neuen Branches vom Master-Branch aus, muss darauf geachtet werden,dass zumindest im Frontend mit Ionic alle notwendigen Abhängigkeiten aktuell sind. Da dieNode_Modules nicht im Repository liegen, ändern sich diese auch nicht mit einem Checkoutdes entsprechenden Branches. Deshalb muss bei einem Wechsel eine Aktualisierung derAbhängigkeiten durchgeführt werden. Erst danach sind die korrekten Abhängigkeiten fürdiesen Branch geladen. Ohne die Aktualisierung kann die Anwendung entweder wegen

20

3.3 Entwicklungs- und Deploymentprozess

Fehlern nicht gebaut werden oder es können während der Laufzeit bestimmte Programmteilenicht geöffnet oder ausgeführt werden. Dann beginnt die Fehlersuche welche teilweise sehrviel Zeit benötigt. Dasselbe betrifft auch die benötigten Plugins bzw. Plattformen. Hierist auch darauf zu achten, dass nach einem Wechsel des Branches, die gewünschten undvollständigen Plugins zur Verfügung stehen.

Zusätzlich sollte auch immer auf die Plugins geachtet werden. Denn das Hauptproblemliegt im Kompilierungs-Prozess. Je mehr Plugins enthalten sind, desto mehr Abhängigkeitenzu Bibliotheken existieren. Wenn verschiedene Plugins die gleiche Abhängigkeit mit unter-schiedlichen Versionen nutzen, wird der Build-Prozess fehlschlagen. Ebenfalls wichtig istdarauf zu achten ob die Plugins für alle genutzten Plattformen genutzt werden können. Esexistieren einige Plugins, die nur für Android, iOS, Android/iOS funktionieren.

Die Plattformen müssen nicht direkt überprüft werden, da die Installation vollständigauf Cordova basieren. Allerdings müssen auch die unterschiedlichen Plattformen hinsicht-lich ihrer Eigenheiten berücksichtigt werden. Darunter zählen z.B. die unterschiedlichenWeb-Engines, welche unter Umständen Probleme machen. Das Verhalten von Browser undPlattform kann sich unterscheiden, deshalb ist ein Test auf realen Geräten unausweichlich.

Für die Entwicklung von Android-Anwendungen ist lediglich das SDK notwendig, dassermöglicht es auf vielen Betriebssystemen zu entwickeln. Bei iOS hingegen ist dies nichtmöglich, dafür wird MacOSX und XCode benötigt. Ohne ein solches Setup ist es nichtmöglich iOS Apps zu entwickeln. Zusätzlich ist es bei Apple notwendig, Zertifikate undProvisionierungsprofile zu nutzen, die durchaus auch Probleme machen können, so dass beiiOS mindestens einmal XCode geöffnet werden muss um die richtigen Einstellungen für dieApp zu setzen.

Für das Backend ist in Jenkins eine Pipeline für das Deployment eingetragen (vgl. Ab-bildung 3.10). Der Build wird über einen Trigger, der alle fünf Minuten auf Änderungen imGitLab Repository überprüft, ausgelöst. Der Build-Prozess gliedert sich in vier verschiedeneBuilds. Zunächst werden die Frontend-Oberflächen, darunter zählt die Web-App der nativenAnwendung, die Administrator-Oberfläche und auch die QAWall gebaut. Dies geschiehtim Jenkins-Server ähnlich wie auf einem Entwickler-Rechner, über ein Skript werden dieeinzelnen Befehle in der Linux-Bash ausgeführt. als letzter Build-Schritt wird das Backenderzeugt. Dafür werden die erzeugten Dateien der vorherigen Schritte in den Backend-Ordnerkopiert, damit diese im Backend als statische Webseiten vorhanden sind. Danach wird mitMaven das Spring Boot Java Artefakt erzeugt.

Sobald dieser Build-Schritt abgeschlossen ist, wird der nächste Prozess angestoßen. Erbettet die im vorherigen Schritt entstandene Jar Datei in ein Docker-Image das anschließendin eine eigene Docker-Registry veröffentlicht wird. Sobald das Image erstellt ist wird imletzten Schritt eine SSH Verbindung auf den Anwendungsserver aufgebaut und dort derDocker-Container gestartet. Nach einer kurzen Startzeit von Spring Boot ist dieser kurzdarauf erreichbar. Der Vorteil durch die vier Build-Schritte liegt in der Fehlererkennung,wenn ein Build-Prozess nicht erfolgreich beendet wurde.

21


Start build_app

docker_deploy docker_start Ende

GitLabRepository

Docker Registry

build_admin

build_qawallbuild_backend

Abbildung 3.10 Erweiterter Jenkins Prozess für den Build-Prozess [eigene Darstellung]

22

4 Auswahl des Cloud Dienstleisters

Das folgende Kapitel über die Auswahl des Cloud Dienstleisters basiert überwiegend aufden Quellen von [Syn17] und [Leo+17].

Die Synergy Research Group [Syn17] berechnet für den Cloudbetrieb (Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und gehostete Private Clouds) einen gesamtenUmsatz von rund elf Milliarden Dollar und einem weiteren Wachstum von über 40% proJahr. Allein Amazon generiert hierbei fast ein Drittel des Umsatzes (vgl. Abbildung 4.1) mitrund vier Milliarden Dollar mit einer kontinuierlichen Steigerung pro Jahr. Das Geschäfts-feld erscheint dadurch sehr interessant, folglich versuchen viele sich im Cloudgeschäft zuetablieren.

Abbildung 4.2 zeigt eine Eingliederung der bekanntesten IaaS Cloud Anbieter. Die Grafikbetrachtet nur die Thematik des IaaS und nicht PaaS, Software-as-a-Service (SaaS) oderähnlichem. Sie ist in vier, sogenannte magische Quadranten aufgeteilt und unterscheidetsomit in den Kategorien Führer, Herausforderer, Visionäre und Nischenbetreiber.

Die Einteilung zeigt, dass viele Unternehmen versuchen im Cloudgeschäft mitzuwirken.Der obere rechte Quadrant klassifiziert die darin enthaltenen Betreiber als Marktführer, diegeringe Anzahl an Unternehmen zeigt, dass sich alle an zwei Betreibern messen müssen.Der Marktführer kann eindeutig als AWS gedeutet werden, da er in der Ausführbarkeit undeigenen Vision die höchsten Werte erzielt, wird jedoch von Microsoft mit ihrer Azure Cloudverfolgt. Als möglicher dritter Kandidat liegt Google zwischen Visionären und Marktführern,ist jedoch deutlich abgeschlagen von den ersten beiden. Herausforderer gibt es praktischkeine, da sie eine ähnliche hohe Ausführbarkeit wie die Marktführer haben müssten, ohnejedoch die eigene Vision zu vervollständigen. Im Quadranten der Nischenbetreiber sind diemeisten kleineren Unternehmen angesiedelt. Sie versuchen durch innovative Ideen weitereKunden zu gewinnen und ihr Geschäft auszubauen. Die zehn Größten von ihnen vereinenjedoch knapp 20% des IaaS Marktanteils unter sich [Syn17].

In Abbildung 4.3 ist die Marktabdeckung für die Bereiche IaaS, PaaS und hosted privateCloud der einzelnen Unternehmen aufgeschlüsselt. Auch hier sticht Amazon mit einemMarktanteil von rund 34% direkt ins Auge. Microsoft ist mit knapp einem Drittel vonAmazon, entsprechen ca. 11% Marktanteil, weit abgeschlagen. Jedoch besitzt Microsoft eindreifach so großes Wachstum (3%) als Amazon (1%) in den letzten vier Quartalen.

Eine mögliche Auswahl des Betreibers beschränkt sich ab diesem Zeitpunkt auf die zweigrößten Betreiber am Markt. Eine Untersuchung der verfügbaren Regionen beider Dienst-leister zeigt, dass keine Differenzierung möglich ist, weil beide ähnlich viele (ca. 40) Re-chenzentren besitzen. Beide Betreiber definieren diese in Regionen, wobei jedoch Amazonweniger besitzt diese aber in einer weiteren Untergliederung in Verfügbarkeitszonen aufteilt.Eine hohe Ausfallsicherheit und Verfügbarkeit wird von beiden angeboten und gewährleistet.

23


Revenueinmilliondollars

1,050 1,0051,169

1,4201,566

1,8242,085

2,4052,566

2,886

3,2313,536 3,661

4,100

QuarterlyrevenueofAmazonWebServicesfrom1stquarter2014to2ndquarter2017(inmillionU.S.dollars)

Q1'14

Q2'14

Q3'14

Q4'14

Q1'15

Q2'15

Q3'15

Q4'15

Q1'16

Q2'16

Q3'16

Q4'16

Q1'17

Q2'17

SourceAmazon©Statista2017

0

1,000

2,000

3,000

4,000

5,000

AdditionalInformation:Worldwide;Amazon;1stquarter2014to2ndquarter2017

Abbildung 4.1 Umsatzentwicklung von Amazon Web Services [Stab]

Abbildung 4.2 Aufteilung der verschiedenen IaaS Cloud Betreiber in vier Quadranten, weltweit[Leo+17]

24

Abbildung 4.3 Rangliste der Marktanteile von dem weltweiten Cloudgeschäft [Syn17]

Ähnliches gilt für die angebotenen Produkte. Beide bieten eine hohe Anzahl von verschiede-nen Services. Die Bezeichnungen unterscheiden sich, jedoch die Funktionalität ist grundsätz-lich ähnlich. Auch wenn [Ben+17] nicht als vollständig oder aktuell angesehen werden kann,so zeigt es doch, dass jeder Betreiber fast immer einen Service besitzt, der eine ähnlicheFunktionalität bietet wie der Konkurrent. Da im Grunde von beiden die gleichen Servicesangeboten werden, ist die Auswahl des Cloudbetreibers auch nicht über die verfügbarenServices möglich.

Für Amazon spricht, dass sie mit den AWS im Cloudgeschäft als der Führende in denBereichen IaaS und im PaaS angesehen werden. Durch die Führungsrolle wird Amazon fürviele als Referenzpunkt, mit einer hohen Innovationskraft für neue Services auf dem bereitsgroßen Portfolio, angesehen. Für die Zukunft wird der Amazon Cloud ein gesteigertesEinflusspotential für die IT Industrie bescheinigt. Auch wenn die AWS nicht immer optimalfür die Anforderungen des Softwareprodukts geeignet ist, wird es häufig als sichere Lösunggenutzt. Die Unternehmen erwarten durch die Marktführung eine gewisse Stabilität undgleichzeitig soll durch die große Anzahl an verfügbaren Diensten eine zukunftsweisendeAusrichtung getroffen werden.

Durch die Position des Marktführers gilt Amazon als der ausgereifteste und unterneh-menstauglichste Anbieter, der seine Funktionen einer großen Anzahl von Benutzern undRessourcen bereitstellen kann. Dadurch schafft es Amazon seine Cloud nicht nur Benut-zern, die von Innovationskraft und digitalen Geschäftsprozessen getrieben sind, interessantdarzustellen, sondern auch für Unternehmen die ihr traditionelles Rechenzentrum in eineIaaS Cloud umziehen möchten. Des Weiteren bietet Amazon sehr viele Partner an, welchedie Implementierung, Migration und Management von Services erleichtern. Dadurch wirdsichergestellt das Software und Lizenzlösungen möglichst vereinfacht werden.

Aber auch Azure, in den Bereichen IaaS und PaaS, als zweiter großer Anbieter verzeichnethohe Wachstumsraten mit einem hohen Umsatz. Microsoft hat in den Funktionsumfang

25


seiner Cloud viel investiert und bietet nun eine große Bandbreite an Funktionen. Die Ge-schwindigkeit in der neue Features entwickelt werden ist sehr hoch und wird noch weitersteigen. Azure ist an einem Punkt angekommen, bei dem nicht nur die Funktionen vonbestehenden Cloudbetreibern nachimplementiert werden, sondern die Entwicklung gehtimmer mehr in die Richtung eigener Ideen und Innovationen.

Da Azure ein Microsoft Produkt ist, finden sich hier viele verschiedene Microsoft Dienstegebündelt, was eine Integration vereinfacht. Aus diesem Grund nutzen viele, die bereitsauf Microsoft Produkten setzen und ihre Software in die Cloud verschieben möchten, aufAzure. Microsoft hat das Ziel dabei, nicht nur die IaaS und PaaS Seite der Cloud abzudecken,sondern erweitert auch die SaaS und on-premise Lösungen. Als Beispiel ist mit AzureStack der Hybrid-Cloudansatz zu erwähnen um den Kunden an Azure heranzuführen. Diehohe Innovationskraft von Azure verdeutlicht, dass es immer mehr für eine Vielzahl vonUse-Cases geöffnet werden soll. Beispielsweise ist der Zwang, eine Windows lizenzierteInstanz zu nutzen, entfallen.

Gleichzeitig haben beide Anbieter negative Faktoren, die es ebenfalls zu beachten gibt.Das reichhaltige Angebot von Amazon bringt auch eine nicht zu vernachlässigende Komple-xität mit, die von Amazon durch eine gute Dokumentation, Trainings, Zertifizierungen etc.versucht wird auszugleichen. Jedoch ist ein Start mit den AWS Diensten grundsätzlich ein-fach, aber es erfordert vom Unternehmen eine hohe agile Leistung um sie in einem optimalenUmfeld nutzen zu können. Als Marktführer wird Amazon als die Organisation angesehen,die den Preis bestimmt. Dabei will Amazon jedoch nicht unbedingt der günstigste Anbieterin einer Wettbewerbssituation sein. Die Preispolitik ist nicht ganz einfach zu verstehen undes wird empfohlen auf Preisberechnungstools zurückzugreifen. Über Preisänderungen wirdnicht aktiv informiert.

Azure hingegen wird von Microsoft als enterprise-ready vermarktet. Häufig ist es anders alserwartet und bei einem Unternehmen, dass auf einen so großen Erfahrungsschatz im BereichEnterprise zurückblickt, sollte es sich mehr unternehmenstauglich anfühlen. Es treten immerwieder Probleme mit dem Support, der Dokumentation oder Schulungen auf. Microsoftarbeitet stetig an der Qualität und hat in den letzten Jahren bereits große Fortschritte indem Bereich gemacht. Das richtige Know-How und eine Risikominimierung wird durch einunorganisiertes und unstrukturiertes System der Servicepartner erschwert.

Durch kontinuierlichen Verbesserungen und dem hohen Innovationstrieb gelangt Microsoftan einen Punkt, an dem nicht jede Funktion den gewünschten Fertigstellungsgrad unddie angestrebte Benutzerfreundlichkeit besitzt. Es entstehen verschiedene Versionen derFunktion, die möglicherweise jeweils eine unklare Anleitung oder Dokumentation besitzt,wird die Implementierung erschwert. Auch wird durch die fehlende Benutzerfreundlichkeithäufig das Azure Portal genutzt und somit existieren wenige Open-Source DevOps-Tools,die es den Administratoren erleichtert.

Die Auswahl zwischen AWS und Azure ist stark vom Projekt abhängig und deswegenkann keine allgemeine Entscheidung getroffen werden. Für dieses Projekt ist die Wahl aufAWS gefallen, wobei auch Azure genutzt werden kann. Der Grund für die EntscheidungAWS zu verwenden liegt sowohl an der Marktführerposition und der guten Dokumentationals auch daran, dass es bereits erfolgreich im Unternehmen verwendet wird.

26

5 Technische Anforderungen an dieArchitektur

Die Architektur wird maßgeblich durch Anforderungen beeinflusst. Die hier vorgestelltenAnforderungen sind auf die wichtigsten Architekturtreiber beschränkt, damit der Umfangüberschaubar bleibt. Sie beeinflussen maßgeblich die weiterentwickelte Architektur.

Bei der Aufnahme von Anforderungen besteht immer die Möglichkeit, dass sich die unter-schiedlichen Anforderungen gegenseitig beeinflussen bzw. behindern. Häufig wird dadurcheine optimale Lösung verhindert. Die Folge ist, ein abwägen und priorisieren von Anforde-rungen, damit eine zufriedenstellende Lösung gefunden werden kann. [PBG11]

AN-1: Kosten

Wenn es um die Weiterentwicklung geht, ist der Kostenpunkt eine entscheidende Anfor-derung an die Architektur. Bisher wurde die Anwendung vollständig auf der bestehendenHardware im Unternehmen betrieben. Dadurch fallen keine Anschaffungskosten, sondernnur Betriebskosten an. Gleichzeitig werden noch andere Programme und Virtualisierungenauf dem Server betrieben, wodurch sich die Betriebskosten auf alle Anwendungen verteilen.Eine genaue Berechnung der aktuellen Kosten ist durch viele Faktoren, wie bspw. Stromver-brauch, Kühlung oder Wartung nur schwer zu berechnen.

Ziel dieser Anforderung ist es, die Kosten für die Transformation in die Cloud zunächst aufein Minimum zu reduzieren. Dies gilt besonders für die entstehenden Personalkosten, welchedurch die benötigte Zeit eines Entwicklers entsteht. Aber auch die Kosten der eingesetztenCloud-Dienste soll zunächst minimal sein.

Der Anforderungspunkt würde in der späteren Entwicklung Konflikte erzeugen. Deshalbist die Bedeutung für die ersten Schritte von großer Bedeutung, verliert diese aber mitzunehmender Entwicklung. Die Abspaltung von der eigenen Infrastruktur dient auch dafür,das Produkt weiter zu vermarkten. Dadurch soll das Projekt möglichst schnell die eigenenKosten tragen und sobald diese gedeckt sind, kann die Architektur optimiert und ausgebautwerden.

AN-2: Programmierumgebung

Durch den Cloudbetrieb und das Aufteilen in Microservices entsteht die Möglichkeit, einzel-ne Programmabschnitte in unterschiedlichen Programmiersprachen und Technologiestacksumzusetzen. So kann beispielsweise ein Service mit Java und Spring Boot umgesetzt werden,während ein anderer mit NodeJS und Javascript implementiert ist.

Mit dieser Anforderung sollen die Microservices vereinheitlicht werden, damit ein ge-meinsames Fachwissen aufgebaut wird und keine Insellösungen in den unterschiedlichsten

27

5 Technische Anforderungen an die Architektur

Programmiersprachen entstehen. Dies ermöglicht einen Wechsel in verschiedene Programm-teile ohne, dass eine Umstellung in andere Sprache notwendig wird.

Bisher wurde Java 8 mit Spring Boot eingesetzt und die weitere Anwendung soll auchweiterhin damit umgesetzt werden. Diese Anforderung ist jedoch nicht als bindend anzuse-hen, denn wenn eine andere Methodik ein besseres Resultat für die Architektur verspricht,kann diese angewendet werden. Grundsätzlich ist aber Java als Programmiersprache zubevorzugen.

AN-3: Horizontale Skalierung

Die horizontale Skalierung zählt u.a. als das Hauptargumente für einen Betrieb in der Cloud.Dort muss sich nicht um die notwendige Server Infrastruktur gekümmert werden, somitwird es leicht neue Instanzen hochzufahren und die vorhandene Last von einer einzelnenInstanz zu reduzieren.

Mit steigendem Interesse geht einher, dass auch die Last auf den Monolith steigen wird.Die entstehende Last kann durch zwei Möglichkeiten reduziert werden. Zunächst ist einevertikale Skalierung möglich, dabei findet eine Vergrößerung der vorhandenen Ressourceneiner Instanz statt, z.B. des Prozessors oder Arbeitsspeichers. Diese Variante ist jedoch nachoben hin beschränkt und skaliert nur die vollständige Anwendung. Eine andere Möglichkeitist die horizontale Skalierung, d.h. ein paralleler Betrieb von der gleichen Anwendungnebeneinander. Die gesamte Menge an Anfragen wird dann zwischen allen Anwendungenaufgeteilt.

Diese Last muss sich jedoch nicht unbedingt auf den ganzen Monolith beziehen, vielmehrerzeugen einzelne Bereiche des Servers die Last. Es ist bspw. möglich während eines VortragsFragen zu stellen und vorhandene zu bewerten. Der Vorgang ist stark abhängig von denteilnehmenden und aktiven Nutzern, bspw. können 500 Benutzer gleichzeitig Fragen stellenund damit eine so große Last erzeugen, dass eine Skalierung notwendig ist. Durch einegeschickte Aufteilung der Anwendung kann diese Problemstellung durch eine horizontaleSkalierung gelöst werden.

Die Anforderung soll deshalb dazu dienen, die verändernde Architektur im Hinblick auf dieSkalierung zu beeinflussen. Bei jeder Veränderung oder Weiterentwicklung sollte über dieseMöglichkeit der Skalierung nachgedacht werden.

AN-4: Austauschbarkeit

Wenn der Monolith aktualisiert wird, besteht immer das Problem, dass die Anwendungwährenddessen nicht zur Verfügung steht. Deshalb sollte die Architektur so weiterentwickeltwerden, dass einzelne Bereiche der Anwendung unabhängig austauschbar sind.

Die entstehende Modularität kann gewährleisten, dass bei Problemen im Programmco-de, eine Änderung an einem Teilbereich der Anwendung schnell in den produktiven Betriebgelangt ohne massive Auswirkungen auf die Verfügbarkeit zu besitzen. Denn während demAustausch bleiben die anderen Bereiche der Anwendung erreichbar. Gleichzeitig wird einschnelleres Deployment für einzelne Teilbereiche ermöglicht um dadurch sowohl Funktionen

28

als auch Logik anzupassen.

AN-5: Verfügbarkeit

Die Anwendung soll möglichst gut erreichbar sein, weshalb eine enge Verbindung mit AN-4:Austauschbarkeit besteht. Damit ist die Anwendung bei einer Aktualisierung grundsätzlicherreichbar. Die Verfügbarkeit bezieht sich jedoch auch auf die Infrastruktur und ist deswegenein weiterer wichtiger Punkt für den Betrieb in der Cloud, z.B. kann dort schnell eineneue Instanz provisioniert werden, was für Unternehmen zur einer teuren Redundanz vonHardware führen würde.

In der Cloud soll die Anwendung mit einer hohen Verfügbarkeit betrieben werden. Darunterzählt, dass fortlaufend überprüft wird, ob die zuständigen Endpunkte erreichbar sind. Wer-den Fehler erkannt, sind selbstständig Maßnahmen durchzuführen um den gewünschtenBetriebszustand wiederherzustellen.

Für die Anwendung ist in den ersten Schritten keine extreme Verfügbarkeit notwendig,diese wird mit mehreren Konferenzen immer wichtiger. Deshalb sollte die Architekturhinsichtlich der Ausfallsicherheit weiterentwickelt werden, denn bereits bei einer angenom-menen Verfügbarkeit von 99% entsteht eine mögliche Ausfallzeit von rund 3,6 Tagen im Jahr.Solange die Ausfallzeiten sich nicht auf die Zeiten einer Konferenz beschränken, ist dies einetragbare Zeitspanne, da es sich um keine kritische Anwendungssoftware handelt.

AN-6: Multimandantenfähigkeit

Ziel ist es, dass die Anwendung für einen Einsatz außerhalb des Unternehmens genutztwerden kann. Die bisherige Architektur ist lediglich für den internen Anwendungsfall konzi-piert, deshalb können die bisherigen Datensätze nicht einem Mandanten zugeordnet werden.

Mit dieser Anforderung soll deshalb eine Anwendung für mehrere Mandanten entstehen,wodurch alle Kunden gleichzeitig an ihren eigenen Daten arbeiten können. Die Mandan-tenfähigkeit sieht vor, dass jeder nur seine eigenen Daten lesen und ändern kann. JeglicheDaten anderer Mandanten dürfen deshalb weder sichtbar noch änderbar sein. Durch dieUmsetzung der Anforderung kann die Anforderung AN-1: Kosten an Bedeutung verlie-ren, da die Hardware besser ausgenutzt werden kann. In diesem Zusammenhang ist auchdie Anforderung AN-3: Horizontale Skalierung wichtig, damit die erzeugte Last mehrererMandanten gut skaliert werden kann.

29

30

6 Minimal Viable Product

Ein Minimal Viable Product (MVP) soll dabei helfen möglichst schnell und mit minimalenAufwand in einen Feedback Zyklus zu kommen, in dem Features eingebaut, evaluiert undanschließend daraus gelernt werden kann. Dadurch soll sich die Software in Richtung desKunden entwickeln und so eine hohe Zufriedenheit erreicht werden. Dabei muss es nichtzwingend das kleinste vorstellbare Produkt sein, sondern kann durchaus einen gewissen,aber reduzierten, Implementierungsstand besitzen. Hat ein Produkt bereits einen Fertigstel-lungsgrad von über 50%, ist es vermutlich besser dieses direkt iterativ zu entwickeln unddie Grundversion als Version null oder eins zu benennen. Ein MVP dient nicht nur als Testfür das Produktdesign und der technischen Umsetzbarkeit, sondern auch ob der eigentlicheBusinesszweck erreicht werden kann [Rie11].

In dieser Arbeit wird das MVP die Transformation des Monolithen in die Cloud sein.Das soll möglichst einfach sein, d.h. zum einen schnell und zum anderen ohne das Entfernenoder Hinzufügen von Funktionalität. Deswegen wird versucht möglichst die vollständigeAnwendung ohne Änderungen in die Cloud zu übertragen.

6.1 Grundlagen

In diesem Unterkapitel finden sich Informationen zu den benötigten AWS Diensten. Es wirdsomit ein Grundstein für das Verständnis der nachfolgenden Kapitel gelegt. Die VirtualPrivate Cloud (VPC) ermöglicht eine Netzwerkkonfiguration in der Cloud, dieses wird mitSecurity Groups als Firewalls abgesichert. Mithilfe des AWS Certificate Manager (ACM)können die HTTPS Endpunkte des Elastic Load Balancing (ELB) konfiguriert werden. Dieseverteilen die Anforderungen an die angebundenen Instanzen. Der Route 53 Domain NameService (DNS) Dienst führt eine Namensauflösung der Load Balancer durch. Wenn nichtanders gekennzeichnet, stammen die Informationen aus der offiziellen Dokumentation vonAmazon [Ama17a].

6.1.1 Virtual Private Cloud (VPC)

Ein VPC ermöglicht das Erstellen von AWS Ressourcen in einem selbst definierten privatenNetzwerk mit den AWS typischen Möglichkeiten zur Skalierung. Es ist vergleichbar miteinem Netzwerk, welches für das eigene Datencenter aufgebaut werden müsste.

Das virtuelle Netzwerk ist einem Benutzeraccount fest zugeordnet und von allen ande-ren Netzen innerhalb der Cloud logisch isoliert. Viele Dienste, z.B. eine Elastic ComputeCloud (EC2) Instanz, benötigen die Angabe eines VPC damit sie erstellt werden können.Es existieren Konfigurationsmöglichkeiten für den IP Adresse Bereich, Subnetze, RoutingTabellen, Netzwerk Gateways und Security Groups. Für jedes VPC kann konfiguriert werden,wie die Kommunikation mit Ressourcen außerhalb des Netzes stattfinden soll.

31


Abbildung 6.1 AWS VPC mit Internet Gateway [Ama17a]

Wenn neue EC2 Instanzen in das VPC erstellt werden, erhalten sie standardmäßig eineprivate IPv4 Adresse und sind nur innerhalb des Netzes erreichbar. Der Zugriff von au-ßerhalb ist nicht möglich. Beim Starten einer Instanz kann eine öffentliche IPv4 Adressezugewiesen werden, dadurch wird eine Kommunikation zwischen verschiedenen Subnetzenermöglicht. Allerdings ist weiterhin kein Zugriff aus oder vom Internet möglich. Dafür mussfür das VPC ein Internet Gateway vorhanden sein. Durch entsprechende Einträge in denRouting Tabellen des Netzwerks wird der Internetverkehr über das Gateway geleitet und sodie Internetverbindung ermöglicht.

Abbildung 6.1 zeigt ein VPC mit verbundenem Internet Gateway. In dem Netzwerk sind zweiSubnetze eingetragen, wobei nur das erste Subnetz eine Verbindung über das Gateway zumInternet besitzt. Dafür wurde den Instanzen eine elastische IP Adresse zugewiesen, damitsie mit dem Internet kommunizieren können. Sie dient auch dazu, dass unterschiedliche In-stanzen den selben öffentlichen Endpunkt darstellen können, jedoch immer nur eine Instanzzur selben Zeit. Gleichzeitig wird ein neuer Eintrag in die Routing Tabelle des Subnetzeseingetragen, damit alle Internetanfragen an den Internet Gateway (in der Abbildung 6.1 alsTarget: igw-id bezeichnet) geschickt werden.

Das VPC ermöglicht zudem die Anbindung des unternehmenseigenen Datenzentrumsüber eine von AWS verwaltete Virtual Private Network (VPN) Verbindung auf Basis von IP-sec. Dafür wird ein virtuelles privates Gateway hinzugefügt, das als Endpunkt auf der AWSSeite dient und eine Verbindung mit dem Endpunkt (Gateway) des Unternehmensnetzwerksherstellt. Das Gateway des Unternehmens kann dabei ein physikalisches Gerät oder eine

32

6.1 Grundlagen

Software sein, welche die VPN Verbindung akzeptiert.

6.1.2 Security Groups

Die Security Groups beschreiben eine virtuelle Firewall und können so den ein- und aus-gehenden Datenverkehr beeinflussen. Innerhalb einer solchen Group können dafür ver-schiedene Regeln definiert werden. Neu erstellte Groups besitzen standardmäßig keineRegel, die den eingehenden Datenverkehr erlaubt. Der ausgehende ist jedoch durch einevorhandene Regel vollständig zugelassen, diese kann aber jederzeit entfernt werden. Zujeder Zeit können weitere Regeln erstellt oder gelöscht werden, die anschließend auf allenInstanzen mit der Security Group automatisch aktiviert sind. Eine Regel besteht immeraus einer Quelle, Protokoll und Port Bereich. Die Quelle kann dabei eine feste IP Adresse,ein Netzsegment oder sogar eine andere Security Group sein. Bei letzterem wird nur dieKommunikation zu oder von einer Instanz erlaubt, welche die entsprechende Group besitzen.

Eine Besonderheit unterscheidet die Security Group von einer richtigen Firewall. Die Groupserlauben nur das definieren von Regeln die eine Verbindung zulassen, es können dadurchnicht spezielle IP Adressen blockiert werden. Das ist von besonderer Bedeutung bei Regelndie eigentlich ein ganzes Netz zulassen würden, aber innerhalb dessen einzelne IP Adressenblockiert oder gesperrt werden sollen.

Die Groups sind stateful, was bedeutet, dass eine Antwort auf ein ausgehenden Requestnicht von den Regeln für eingehende Verbindungen betroffen und somit erlaubt ist. Dasselbegilt auch für die andere Richtung. Der Grund liegt darin, dass die Verbindung durch denRequest erzeugt wird und dieser über die Regeln kontrolliert wird.

Grundsätzlich sind Security Groups alleinstehend, nicht zugewiesen und somit ohne Funkti-on. Sie können aber auf eine oder mehrere EC2 Instanzen gleichzeitig angewandt werden.Wird ein VPC erstellt, ist automatisch eine default Group angelegt worden. Diese beschreibt,dass jegliche ausgehende Datenverbindung erlaubt sind. Die eingehenden sind jedoch nurzugelassen, wenn sie von derselben Security Group kommen. Bei einer Instanz ohne weitereZuweisung einer anderen Group wird die default Group des VPC zugewiesen. Damit ergibtsich die folgende Priorität: EC2 Security Group > Default VPC Security Group.

Den Instanzen können nachträglich Groups zugeordnet oder entfernt werden, bis zu ei-nem Maximum von fünf. Sind mehrere einer Instanz zugewiesen, werden alle Regeln jedereinzelnen zu einer Liste zusammengefasst. Anschließend wird diese Liste genutzt umVerbindungen zu erlauben oder zu verbieten.

6.1.3 AWS Certificate Manager (ACM)

Mithilfe des ACM wird einem das Erstellen und Verwalten von Zertifikaten abgenommen.Es existieren zwei Arten um ein Zertifikat mit dem ACM nutzen zu können. Die erste wirdüber die Nutzung eines importierten unternehmenseigenen Zertifikats ermöglicht. Dabeiist das Unternehmen selbst dafür verantwortlich, dass das Zertifikat gültig und von eineranerkannten Zertifizierungsstelle ausgestellt ist. Ebenso muss der Inhaber des Zertifikatsimmer darauf achten, dass es aktuell gehalten wird. Als zweite Möglichkeit bietet AWS an,ein Zertifikat über den Manager zu erstellen und verwalten zu lassen. Somit entfallen alle

33


Arbeiten mit dem Zertifikat (vor allem bzgl. Zertifizierung, Erneuerung) und es entstehendadurch auch keine weiteren Kosten.

Die vom ACM erstellte Zertifikate beinhalten verschiedene Eigenschaften. Für die Validie-rung der Domain wird eine E-Mail an den registrierten Benutzer geschickt mit Anweisungenwie die Validierung durchzuführen ist. Die Zertifikate sind 13 Monate gültig und werdenanschließend automatisch vom Manager erneuert und die Zertifikate in den Services ausge-tauscht. Dadurch sollen Ausfallzeiten aufgrund von fehlerhaften bzw. ungültigen Zertifikatenvermieden werden. Wichtig ist auch, dass die Browser oder Anwendungen den Zertifikatenauch Vertrauen und keine Warnungen anzeigen. Weshalb die Zertifikate von Amazon beiden gängigsten Browsern von Google, Microsoft, Mozilla und Apple als vertrauenswürdigangesehen werden.

Dennoch existieren Nachteile, denn die im ACM vorhandenen Zertifikate können nurvon Services genutzt werden, die den Manager integriert haben. Darunter zählen aktuellfünf verschiedene Frontend Dienste: Elastic Load Balancing, CloudFront, Elastic Beanstalk,API Gateway und CloudFormation. Ebenso können die Zertifikate nur für die sichere Kom-munikation über die SSL/TLS Protokolle genutzt werden. Eine Einbindung der Zertifikatein die EC2 Instanzen ist ebenfalls nicht möglich, wodurch diese dann wiederum auf vomUnternehmen bereitgestellte Zertifikate angewiesen sind.

6.1.4 Elastic Load Balancing (ELB)

Unter ELB wird das Verteilen von Datenverkehr auf verschiedene Zielsysteme zusammen-gefasst, die sogenannte Load Balancer sind dabei die eigentliche Komponente. Sie leitenden Datenverkehr an ihre registrierten Ziele, wie z.B. EC2 Instanzen weiter. Dabei wählter nur Ziele aus, die auch einen verfügbaren Zustand besitzen. Dafür überprüft der LoadBalancer in regelmäßigen und konfigurierbaren Abständen mit einem Request ob eine Ant-wort mit dem HTTP Statuscode 200 vom Ziel eingeht. Bei nicht verfügbaren Zielen wirddas Routing an diese Instanzen ausgesetzt bis das Ziel wieder erreichbar ist. Sollten alleZiele nicht verfügbar sein, wird ein Broadcast an alle eingetragenen Ziele durchgeführt. DieBezeichnung Elastic bezieht sich auf das automatische Skalieren des Loadbalancers und demAktualisieren der dazugehörigen DNS Einträge, wenn der Datenverkehr zu groß wird.

Damit ein Load Balancer eingehende Datenverbindungen akzeptieren kann muss er mitListenern konfiguriert werden. Die Konfiguration eines Listener beinhaltet sowohl das Proto-koll und den Port der Clientverbindung als auch den Port und das Ziel für die ausgehendeVerbindung. Zusätzlich können zu jedem Listener Regeln definiert werden. Diese führeneine Prüfung von einer konfigurierten Bedingung durch. Sollte diese korrekt sein wird derRequest an das speziell definierte Ziel weitergeleitet.

Load Balancer Typen

Es gibt drei verschiedene Arten von Load Balancern in der AWS Cloud: Application-,Network- und Classic Load Balancer. Der Unterschied zwischen den drei liegt in derKonfiguration. Die ersten beiden vereinen Zielrechner in sogenannten „Target Groups“ undleiten den Datenverkehr auf diese um. Die Target Groups sind ein Verbund von möglichenZielsystemen, z.B. können drei EC2 Instanzen innerhalb einer Gruppe definiert sein, die alle

34

6.1 Grundlagen

den Request bearbeiten können. Der Application Load Balancer unterstützt nur Protokolleauf der Anwendungsebene und deshalb aktuell nur die Protokolle HTTP und HTTPS. DerNetwork Load Balancer hingegen kann mit den Netzwerk Protokollen konfiguriert unddadurch in vielen Anwendungsfällen eingesetzt werden. Der Classic Load Balancer ähneltdem Network Load Balancer jedoch können die Zielsysteme nicht über eine Group definiertwerden, sondern müssen jeweils direkt beim Load Balancer registriert sein.

Routing Algorithmus

Wenn die Load Balancer den Datenverkehr an die Target Group weiterleitet, wird das zustän-dige Ziel anhand eines Routing Algorithmus ausgewählt. Der Application Load Balancerschaut bei jedem Request welcher Listener und die damit verbundene Target Group genutztwird. Aus dieser Group wird mithilfe des Round Robin Verfahrens ein Ziel ausgesucht,dieses Verfahren ist für jede Target Group eigenständig anzusehen und beeinflusst nicht dasnächste Ziel einer anderen Group.

Der Netzwerk Load Balancer nutzt hingegen das Flow Hash Verfahren.

h = H(X)modN (6.1)

Die Formel (6.1) zeigt, wie ein Hashwert h als Lookup Schlüssel für die Zielauswahl berech-net wird. Der Parameter N steht dafür für die Anzahl der Ziele innerhalb einer Targetgroup.H(X) ist die Hashfunktion für einen Eingangswert X. Der Wert basiert auf dem Protokoll derVerbindung, den IP Adressen von der Quelle und dem Ziel, sowie deren Ports und der TCPSequenznummer. Mit dem berechneten Wert h wird in einer Tabelle nach der Zuordnungzur Ziel Instanz geschaut und dorthin der Request weitergeleitet [San15].

Der klassische Load Balancer von Amazon nutzt zwei verschiedene Methoden. Für TCPListener wird wie beim Application Load Balancer das Round Robin Verfahren für dieregistrierten Instanzen eingesetzt. Für HTTP oder HTTPS Listener wird eine Instanz mit derschnellsten Verbindung bzw. die geringste Last genutzt.

Load Balancer Capacity Unit (LCU)

Alle Load Balancer besitzen sogenannte LCU. Amazon beschreibt anhand dieser Einheit,wie der Load Balancer den Datenverkehr im Durchschnitt pro Stunde verarbeitet. Dafürwerden vier verschiedene Bereiche untersucht und der Bereich mit dem höchsten Wert fürdie Berechnung herangezogen.

• Neue Verbindungen:Die Anzahl von Verbindungen die pro Sekunde zum Load Balancer neu aufgebautwerden.Eine LCU: 25 Neue Verbindungen pro Sekunde

• Aktive Verbindungen:Anzahl der aktiven Verbindungen zum Load Balancer. Gemessen pro Minute.Eine LCU: 3000 aktive Verbindungen pro Minute

• Bandbreite:Der Datenverkehr der vom Load Balancer verarbeitet wurde. Maßeinheit ist Mb/s.Eine LCU: 2,22 Mbit/s (1GB/Stunde)

35


• Regelauswertungen:Summe der ausgewerteten Regeln innerhalb von den Listenern und der Anforderungs-rate. Die ersten zehn verarbeiteten Regeln sind im kostenlosen Kontingent.Eine LCU: 1000 Regelauswertungen pro Sekunde

Wird ein einziger dieser Grenzwerte überschritten wird eine zweite LCU benötigt. DieseBerechnung kann bei der Preisberechnung ausschlaggebend sein.

6.1.5 Route 53

Der Route 53 Service kann helfen verschiedene Endpunkte in der Cloud einfacher zuerreichen. Er erfüllt drei Hauptfunktionen, wovon beliebige Kombinationen möglich sind:

• Domänennamen registrierenWenn Webseiten oder Anwendung einen festen Namen benötigten, ermöglicht derService die Registrierung eines neuen Domänennamen. Dafür kann der Benutzerseine Wunschdomäne angeben und das System überprüft ob diese Verfügbar ist.Unter Angabe von Kontaktinformationen ist eine Bereitstellung der Domain möglich.Abhängig von der genutzten Top-Level-Domain werden die Domänen entweder überdie Amazon Registrar, Inc. oder Gandi bereitgestellt werden.

• Internetverkehr zu Ressourcen weiterleitenWenn Anfragen an eine Domain gestellt werden, kann der Service diese anhand desNamens auflösen und einem Endpunkt zuordnen. Dadurch muss der Benutzer nichtden eindeutigen, vielleicht komplizierteren, Namen oder IP Adresse des Endpunktskennen.

• Zustand der Ressource feststellenDer Service kann regelmäßig und automatisch die Ressource Abfrage um zu überprü-fen ob diese erreichbar ist. Das System erlaubt das Einstellen von Benachrichtigungen,um möglichst schnell auf Verbindungsfehler zu reagieren.

Wenn eine Domain registriert wird, erstellt der Service eine sogenannte „Hosted Zone“ inder automatisch vier verschiedene Nameserver erzeugt werden. Sobald sie der Hosted Zonehinzugefügt sind, wird die Domain aktualisiert und dort die Server eingetragen um eineNamensauflösung der Domain zu ermöglichen. Damit wäre eine Hauptfunktion bereitserfüllt.

Die zweite Funktion, das Weiterleiten des Internetverkehrs, wird über sogenannte Re-cordsets innerhalb einer Hosted Zone durchgeführt. Ein solcher Datensatz benötigt einenNamen, dieser wird als DNS Eintrag genutzt für den die Weiterleitung aktiviert werden soll.Der Name muss immer mit dem Namen der gehosteten Zone enden, was bereits bei derErstellung automatisch und nicht änderbar von Amazon berücksichtigt wird. Als weitereInformation wird der Typ des Eintrags benötigt, dafür gibt es eine bestimmte Auswahl anverfügbaren Typen die mit DNS kompatibel sind. Als häufigster Eintrag darunter zählt dieWeiterleitung auf Basis der IP Adresse. Der entsprechende Wert ist mit dem Typen engverbunden, deshalb sollte eine IP Adresse nicht in einen Canonical Name verwendet werden.Innerhalb eines Records besteht die Möglichkeit die Zustandsprüfung für den Endpunkt zuaktivieren, wodurch die dritte Hauptfunktion ermöglicht wird.

36

6.2 Vorbedingungen

Die Auflösung einer Domain, die der Benutzer in den Browser eingibt oder eine Anwendungnutzt, wird dann nach dem üblichen DNS Schema aufgelöst. Die Nameserver entscheidendann anhand der Hosted Zone und den eingetragenen Records an welchen Zielpunkt derAufruf gerichtet ist.

6.2 Vorbedingungen

Die Anwendung kann bei der Überführung vom internen in einen Cloud Betrieb nicht einszu eins umgesetzt werden. Deshalb wird sie auf Abhängigkeiten hin untersucht, die füreine Cloud nicht nutzbar sind. In diesem Kapitel wird auf zwei notwendige Änderungeneingegangen.

6.2.1 Dateispeicherung

Im aktuellen System wird dem Container beim Starten ein Teil vom Dateisystems des Hostseingebunden. Der Monolith nutzt den eingebundenen Teil um darauf Dateien abzuspeichernoder einzulesen. Das ermöglicht die dauerhafte Speicherung der Daten. Dies ist notwendig,weil ein Stopp des Containers die darin enthaltenen Dateien löscht. Ohne die Speicherungaußerhalb des Containers würde ein solcher Fall zu einer Dateninkonsistenz führen, da inder Datenbank Werte eingetragen sind, die nicht mehr zu existierenden Dateien führen.Während ein Einbinden des Dateisystems auf dem eigenen Server sehr einfach möglich ist,kann sich dieser Umstand in der Cloud ändern.

Innerhalb der AWS Cloud existieren mit Simple Storage Service (S3), Elastic File System(EFS) und Elastic Block Storage (EBS) drei verschiedene Möglichkeiten, um die Dateienabzuspeichern:

• S3Daten werden als Objekte in einer Ressource gespeichert, sogenannten Buckets. DieDateien können bis zu fünf Terabyte groß sein und die Anzahl der gespeichertenObjekte ist beliebig, da das Bucket mit seiner Größe skaliert. Verfügbarkeit sowieSicherheits- und Compliance-Funktionen zählen ebenfalls zu den Kernpunkten desService. Der Dienst kann auch von außerhalb des EC2 Bereichs genutzt werden. Dieeigene API erlaubt die Einbindung in viele verschiedene Programmen.

• EBSIst ein Speicher für eine persistente Blockspeicherung von EC2 Instanzen. Die Volumeswerden innerhalb einer Zone repliziert um so eine hohe Verfügbarkeit und Ausfall-sicherheit zu erreichen. Diesem Speicher muss bei der Erstellung eine feste Größeangegeben werden und er besitzt ansonsten keine weitere automatische Größenskalie-rung. Durch Entfernen, Modifizieren und erneutes Einbinden wird die Veränderungder Speichergröße jedoch ermöglicht. Der Zugriff auf den Blockspeicher ist nur voneiner einzigen EC2 Instanz möglich.

• EFSDas System stellt ebenfalls einen einfachen und skalierbaren Speicher zur Verfügung.Die Speicherkapazität ist wie beim S3 Dienst elastisch und wächst mit der Anzahlvorhandener Daten. Wie das EBS kann es nur von EC2 Instanzen ausgenutzt werden.

37


Jedoch wird ein gleichzeitiger Zugriff von mehreren Instanzen aus ermöglicht. Das FileSystem wird über die „open-after-close“ bzw. „read-after-write“ Semantik und FileLocking konsistent gehalten. Es würde ebenfalls ein Bereitstellen des Dateisystems aufeinem betriebsinternen Server ermöglichen, so dass die Daten stets beim Unternehmenliegen.

Auswahl der Speicherlösung

S3 ist ein Objektspeicher und kann deswegen keine Dateizuordnung über Pfadangabentreffen. Daraus resultiert, dass eine Anpassung des Softwarecodes notwendig ist um aktivdas neue Speichersystem nutzen zu können. Aufgrund des MVP und der nicht zwangsweisenotwendigen Änderungen fällt S3 als Speicherlösung weg.

EBS ermöglicht eine Blockspeicherung, die auch nach einer Terminierung der EC2 Instanzbestehen bleibt. Da das Systemverzeichnis standardmäßig bei der Terminierung gelöschtwird, muss ein weiteres eingebunden werden, welches nicht automatisch gelöscht wird.Für dieses neue Verzeichnis muss die Eigenschaft „Löschen bei Terminierung“ zwingenddeaktiviert sein, da es sonst schnell passieren kann, dass die vorhandenen Daten, durchUnachtsamkeit beim Beenden oder Verändern der EC2 Instanz, gelöscht werden könnten.Bei der Erstellung einer Instanz können beliebig viele weitere Verzeichnisse angegebenwerden und daher wird keine größere Konfiguration außer dem Erstellen eines Mountpointsbenötigt. Alternativ können auch weitere Verzeichnisse nachträglich hinzugefügt werden.Durch eine minimale Änderung innerhalb einer Konfigurationsdatei des Monolithen kannder aktuelle Dateipfad für die Dateispeicherung auf den neuen angepasst und dadurch dieSpeicherung in der Cloud ermöglicht werden.

Als sinnvollste Wahl erscheint das EFS, weil es ähnliche Funktionen wie das EBS bietet,jedoch keiner festen Größe unterliegt und in Abhängigkeit der vorhandenen Daten skaliert.Der gleichzeitige Zugriff von mehreren Instanzen aus, ist ein weiterer Grund warum dasEFS zu bevorzugen ist. Denn dadurch wird, bei einer absehbaren Lasterhöhung durch meh-rere gleichzeitige Konferenzen, eine grundsätzliche manuelle Skalierung des vollständigenMonolithen ermöglicht, ohne dass weitere Änderungen am System vorzunehmen sind. ImVergleich zum EBS benötigt das EFS einen leicht erhöhten Konfigurationsaufwand, weil aufjeder Instanz die benötigte Software installiert werden muss. Gleichzeitig hat es eine dreifachso hohe Kostenbelastung, die jedoch vernachlässigbar sind (siehe Kapitel 6.6). Der Aufwandfür die Einbindung eines EBS oder EFS ist ähnlich und stellt daher keinen Kritikpunkt da.Durch die Nutzung des EFS sind für die Anwendung keine Änderungen notwendig. Dafürist im Docker Startbefehl nur die Verbindung der richtigen Verzeichnisse notwendig.

6.2.2 Benutzerverwaltung

Damit eine Transformation des MVP gelingen kann, ist es zwingend erforderlich innerhalbdes Projektes einen weiteren Punkt umzusetzen. Aktuell ist die Benutzeranmeldung aufder Webseite des Administrators über das Backend mit dem internen LDAP von iteratecverbunden. Dieser Service ist von außen nicht erreichbar und soll auch in Zukunft nichtfreigeschaltet werden, da dies sonst eine potenzielle Sicherheitslücke zur Folge hätte, welchepersonenbezogene Daten betreffen würde.

38

6.3 Deployment

Bei einer Transformation in die Cloud muss deshalb eine autarke Benutzerverwaltungin die Anwendung eingebaut werden. Dafür benötigt das Backend neue Funktionen umeinen Benutzer anlegen, löschen oder editieren zu können. Eine Funktion um das Passwortzurückzusetzen ist für ein MVP zunächst nicht ausschlaggebend. Für die Benutzer werdenkeine Einstellungen gespeichert, daher können diese im ersten Schritt manuell gelöscht undanschließend neu angelegt werden.

Amazon Cognito

Mit Amazon Cognito wird in der AWS Cloud eine Möglichkeit angeboten, ein sicheres undskalierbares Benutzerverzeichnis zu erstellen. Dadurch kann das interne LDAP in der Cloudabgebildet werden. Die Nutzung des Amazon Cognito Dienstes kann beispielsweise Funk-tionen wie Login, Registrierung oder das Passwort Management übernehmen. Allerdingsmuss dafür die Authentifizierungslogik vollständig umgestellt und neugeschrieben werden.Für die Umsetzung des MVP ist eine Lösung mit Spring Security einfacher, da bereits dasWissen über die Logik vorhanden ist. Die Einarbeitung in eine neue Thematik entfällt. Somitreduziert sich der Zeitbedarf für die Umsetzung der Benutzerverwaltung im MVP. DieNutzung von Cognito erzeugt zusätzlich eine starke Abhängigkeit zu Amazon.

Spring Security

Eine andere Möglichkeit die Benutzerverwaltung umzusetzen ist das Spring Security Modul.Das bereits für die interne LDAP Authentifizierung eingesetzt wird.

Für die Speicherung ist eine neue Tabelle in der Datenbank notwendig. In dieser wirdder Benutzer eindeutig über eine ID referenziert. Außerdem werden weitere Benutzerdatenwie beispielsweise der Loginname, vollständige Name des Benutzers oder die E-Mail gespei-chert. Ebenfalls wird ein kryptografischer Hashwert des Benutzerpassworts abgespeichert.

Dafür kann die Bcrypt Implementierung von der Spring Security Suite als Passwort Encodergenutzt werden. Damit wird ein, in „A future-Adaptable Password Scheme“ [PM] beschrie-benes Konzept für zukunftsorientierte Hashing Algorithmen genutzt. Die Implementierungsieht vor, dass bei immer größeren Rechenleistungen der verwendeten Computersysteme diegeleistete Arbeit exponentiell erhöht werden kann. Damit die Anzahl der durchgeführtenHash Berechnungen gering gehalten und so weniger Passwortkombination ausprobiertwerden können. Zusätzlich wird es in der genutzten Implementierung ermöglicht einenzufälligen Salt in den Algorithmus einzubringen. Da Hashing Funktionen idempotent undunidirektional sind, kann das Passwort nur anhand eines Vergleiches von beiden Hashwertenüberprüft werden [NY89].

Die Anmeldung funktioniert somit weiterhin über das Spring Security Modul. Der Un-terschied zur bisherigen Anmeldung gegen das LDAP liegt in dem verwendeten Providerfür die Authentifizierungslogik. Dieser wird gegen einen ausgetauscht, welche die Authenti-fizierung mit der neue Datenbanktabelle durchführt.

39


Abbildung 6.2 iteraKonf Jenkins Pipeline für AWS Deployment [eigene Darstellung]

6.3 Deployment

Das Deployment in die Cloud unterscheidet sich nicht maßgeblich von dem bisherigen. Umdie notwendige Anzahl an Jobs in Jenkins zu reduzieren wird eine Pipeline (vgl. Abbildung6.2) erstellt. In ihr sind alle notwendigen Schritte für ein Deployment in die AWS enthalten.Gleichzeitig zeigt es auch die durchschnittliche Zeit an, die jeder einzelne Buildschrittbenötigt. Nachfolgend werden die einzelnen Schritte kurz erläutert:

• Setup CredentialsÜber die Spring Konfigurationsdatei werden die notwendigen Eigenschaften oder APISchlüssel für die Anwendung gesetzt. Diese liegen im Projekt als Templates vor undenthalten nur Platzhalter. Im Jenkins Server ist dafür eine entsprechende Datei mit allennotwendigen Werten eingetragen. Der Buildschritt ersetzt die Platzhalter innerhalb derTemplates durch die Werte aus der Datei.

• Build WebpagesIn diesem recht langen Buildschritt werden die drei verschiedenen Webseiten erzeugt.Dabei wird für jede eine Überprüfung der notwendigen Abhängigkeiten durchgeführtund anschließend der produktiv Build-Prozess von ionic gestartet. Dadurch werdenverschiedene Optimierungen, eine Ahead-of-Time Kompilierung, Minify und nochweitere Schritte durchgeführt.

• Build ServerDieser Schritt ist vergleichsweise einfach und führt lediglich einen Mavenbuild von demBackendserver durch. Während dieser Zeit werden die integrierten Tests durchgeführt.

• Build Docker ImageAuf dem lokalen Buildserver wird das Docker Image anhand des Dockerfiles erzeugtund in das iteratec interne Docker Repository hochgeladen.

• AWS DeploymentDer Schritt aktualisiert die Daten und Container in der Cloud.

Der letzte Buildschritt AWS Deployment beinhaltet mehrere Unterschritte. Zunächst wirdauf dem Build Server das neue Docker Image in eine Datei gespeichert. Anschließend wirdeine eine SSH Verbindung zu der EC2-Instanz in der Cloud aufgebaut (vgl. Abbildung6.3). Dafür muss die Security Group der Instanz eine SSH Verbindung erlauben. Wenndie Verbindung aufgebaut ist, wird die Datei auf den Remotehost übertragen. Der nächsteSchritt ist den laufenden Container zu aktualisieren. Dafür wird dieser zunächst ange-halten und sowohl der Container als auch das genutzte Image entfernt. Das neu erstellte

40

6.4 Aufbau

Abbildung 6.3 Workflow für das Cloud Deployment auf eine EC2 Instanz [eigene Darstellung]

Image wird in den Docker Daemon geladen und mit einem Befehl der Container gestar-tet. Nach rund 20 Sekunden, inklusive Startzeit des Backend, ist der Server wieder erreichbar.

Der Deployment Prozess unterscheidet sich im letzten Build-Schritt zum bisherigen, denndort wird keine Verbindung zum unternehmenseigenen Server aufgebaut, sondern zu einerCloud Instanz. Der notwendige Docker Befehl zum Starten des Containers muss dement-sprechend für die Cloud Instanz angepasst werden, um bspw. das Filesystem korrekt zuverbinden.

6.4 Aufbau

In diesem Kapitel soll der Anwendungsaufbau in der Cloud näher beschrieben werden. Einegrafische Darstellung ist in Abbildung 6.4 aufgezeigt.

Das System läuft vollständig in der AWS. Das VPC erstellt einen Adressbereich von denendie Dienste ihre IP Adressen beziehen und von innen erreichbar sind. Mit dem RelationalDatabase Service (RDS) wird die betriebsinterne MySQL Datenbank in die Cloud ausgelagert.Damit möglichst wenig Arbeitsaufwand investiert werden muss, wird weiterhin auf eineMySQL Instanz gesetzt.

Ebenfalls im VPC enthalten ist eine EC2 Instanz (Abbildung 6.4 Mitte). Damit sie fürdas MVP genutzt werden kann, sind drei wichtige Aspekte zu berücksichtigen. Zunächstmuss bei der Inbetriebnahme der Instanz ein SSH-Schlüssel erzeugt werden. Der öffentlicheSchlüssel wird in der Instanz automatisch hinterlegt und der private Schlüssel muss gut

41


Abbildung 6.4 Anwendungsstruktur des MVP [eigene Darstellung]

gesichert werden, da er nur bei der Erzeugung der Instanz ausgegeben wird. Der privateSchlüssel ist für den Zugang zum System und das Deployment des Containers wichtig,damit die SSH Verbindung aufgebaut werden kann. Der zweite wichtige Punkt ist dieInstallation von Docker auf der Instanz. Standardmäßig ist kein Docker Daemon auf demSystem installiert, deswegen muss vor dem ersten Deployment eine manuelle Installationstattfinden. Als letzter vermutlich wichtigste Punkt ist die Security Group zu nennen. Die-se muss für die Instanz korrekt eingestellt sein, da sonst kein Zugang zum System möglich ist.

In der Abbildung 6.4 sind die Security Groups für den eingehenden Datenverkehr mithilfeder roten Umrahmungen dargestellt. Wegen der Übersichtlichkeit wurden die ausgehendenRegeln nicht eingefügt, da sie aktuell jeglichen Datenverkehr zulassen weil keine anderenSysteme und nur eine Instanz im Netz sind. Die Regeln der EC2 Instanz zeigen, dass nur eineSSH Verbindung von außen aufgebaut werden kann. Die Kommunikation zur Anwendungist nur über eine Instanz mit der entsprechend zugewiesenen Security Group möglich undin diesem Aufbau nur über den ELB.

Auf der rechten Hälfte der Abbildung 6.4 ist das EFS zu erkennen, auch dieses musseinem VPC zugewiesen sein, damit der Mountpoint in der EC2 Instanz erzeugt werdenkann. Damit das EFS nutzbar ist, muss es auf der Instanz zuerst konfiguriert werden. Dafürmuss zunächst über den Paketmanager eine bestimmte Software installiert werden, damitdie Kommunikation zum EFS System nutzbar ist. Anschließend muss es in die EC2 Instanzeingebunden werden.

42

6.4 Aufbau

ELB

Die Kommunikation von außen wird über einen ELB ermöglicht. Er fungiert als Proxy Systemindem er die Anfragen aus dem Internet an die eingestellte Target Group weiterleitet. Da esein Load Balancer ist, verteilt er die Anfragen an verschiedenen Instanzen der Target Group.In diesem Setup wird ein Application Load Balancer als öffentlicher Endpunkt genutzt. Ererhält eine öffentliche DNS Adresse und kann als Weiterleitungsregeln die Protokolle HTTPund HTTPS nutzen. Da wir mit der Anwendung Passwörter übertragen und damit Drittekeine Möglichkeit besitzen alle übertragenen Daten abzufangen, wird der ELB mit einemHTTPS Listener konfiguriert. Damit dieser funktioniert, wird ein Zertifikat benötigt. Bei derErstellung eines solchen Listeners kann das benötigte Zertifikat über den ACM ausgewähltwerden. Ohne eine weitere Konfiguration ist die Verbindung mit dem ELB über HTTPSmöglich.

Beachtet werden sollte jedoch, dass die HTTPS Kommunikation nur zwischen dem Endnut-zer und ELB stattfindet. Letzteres nutzt das Zertifikat um die Verbindung zu terminierenund den Request zu extrahieren bevor er die Anfrage an das Ziel weiterleitet. Danach wäredie Kommunikation zwischen ELB und der Anwendung für alle im Netzwerk sichtbar. Wiebereits erwähnt werden Passwörter übertragen, deswegen ist auch eine gesicherte Verbin-dung zwischen den internen Komponenten notwendig. Für die Kommunikation kann aufein selbst signiertes Zertifikat gesetzt werden, da dort keine Benutzerinteraktion stattfindet.Somit ist auch keine Warnung über ein unsicheres Zertifikat für den Endbenutzer ersichtlich.

Datenbank

Damit auch die Verbindung zwischen Backend und der MySQL Instanz geschützt ist, wirddort ebenfalls eine gesicherte Verbindung erzeugt. Dafür wird ebenso ein selbst erstelltesZertifikat genutzt, da auch diese Verbindung nicht nach außen hin geöffnet ist. Das Zertifikatwird mithilfe von Java Umgebungsvariablen, die im Dockerfile angegeben sind, gesetzt undanschließend durch die Verbindung automatisch genutzt.

Dateisystem

Das EFS wird über drei verschiedene Methoden abgesichert. Zunächst wird eine Identityand Access Management (IAM) Berechtigung benötigt um Aufrufe an das EFS API Systemdurchzuführen. Nur mit den richtig eingestellten Berechtigungen können die Aufrufer Datenerstellen, verwalten oder löschen. Die zweite Methode ist die zusätzliche Nutzung vonSecurity Groups. Wie bei der EC2 Instanz muss das EFS notwendige Regeln in den SecurityGroups besitzen. Damit die initiale Verbindung zwischen Instanz und EFS hergestellt werdenkann. Gleichzeitig ist der Zugriff auf das EFS nur aus dem VPC heraus möglich, da es keineöffentliche IP Adresse zugewiesen bekommen kann. Außerdem können mit sogenanntenZugangskontrolllisten der Zugang verweigert werden. Als letzte Sicherheitsmaßnahmebesitzt das File System ein ähnliches Berechtigungssystem wie Unix basierte Systeme für dasLesen, Schreiben und Ausführen von Dateien. Sobald eine Verbindung zum EFS aufgebautist, sind Dateiberechtigungen die letzte Sicherheitsmaßnahme.

43


DNS

Als letzte Komponente von Abbildung 6.4 ist noch die Verbindung zwischen Route 53und dem ELB zu erläutern. Auf den ELB kann über seinen externen DNS Namen (z.B.iterakonf-elb-493276328.eu-central-1.elb.amazonaws.com) zugegriffen wer-den. Es ist jedoch sofort ersichtlich, dass sich ein Benutzer eine solche Adresse nur schwermerken kann. Der Service ermöglicht die Nutzung einer einfacheren Domain, wodurch sichfür Personen bessere Adressen erzeugen lassen. Die Anzahl der dargestellten Pfeile sollenein Vergleich darstellen, wie oft Anfragen an die jeweilige DNS gestellt werden.

6.5 Multimandantenfähigkeit

In diesem Kapitel wird auf die geforderte Multimandantenfähigkeit eingegangen. Darunterwird das Teilen einer Anwendungsinstanz zwischen mehreren Kunden verstanden. DieTeilung bezieht sich dabei aber nur auf die ausführenden Ressourcen, denn jeder Mandantbesitzt einen eigenen Datenbereich. Die Multimandantenfähigkeit kann auf der Anwen-dungsebene oder aus Sicht eines PaaS Betreibers betrachtet werden. Bei letzterem ist dieAnwendung auf verschiedenen Instanzen vorhanden und spiegelt andere Charakteristikenund Anforderungen wieder [KMK12].

Wird die aktuelle Anwendung betrachtet, ist es nur sinnvoll die Anwendungssicht zubetrachten. Die PaaS Sicht ist zwar ebenfalls umsetzbar, allerdings erhöhen mehrere Anwen-dungen die Komplexität und reduzieren gleichzeitig die Effektivität der Instanzen, da jederMandant zunächst nur einen geringen Teil der Leistung benötigt. Durch die Nutzung einereinzelnen Instanz für alle Mandanten wird eine bessere Auslastung der Infrastruktur erreichtund die erzeugten Kosten werden verringert. Sollte dennoch ein Kunde darauf bestehen, istdieses Konzept in der Cloud ebenfalls umsetzbar.

Die Multimandantenfähigkeit ist zudem eine wichtige Funktion, um möglichst schnelldie Kosten für den Betrieb abzudecken. Das Spring Security Modul von Privotal wird bereitsin der Anwendung verwendet, um die Anmeldung des Administrators durchzuführen. Eskann auch für die Multimandantenverwaltung genutzt werden. Über den Login kann derMandant identifiziert werden und die jeweilige ID wird in einem signierten JSON Web Token(JWT) gespeichert. Bei jeder Anfrage an den Server ist ein gültiges Token notwendig, dasonst alle Anfragen blockiert werden. Dabei wird die ID des Mandanten extrahiert und fürdie weitere Verarbeitung genutzt.

Die Funktionalität verändert die interne Architektur der Anwendung deutlich. Es müs-sen viele Programmteile angepasst werden, denn in den Ressourcen wird die MandantenIDaus den Anfragen extrahiert und an die Services weitergegeben. Diese müssen dahingehendangepasst werden, dass sie die ID bei dem Lesen der Daten aus der Datenbank mit angeben.Daraus resultiert, dass auch die Repositories von Spring Boot einem weiteren Parameterbenötigen.

Der große Eingriff in den Sourcecode ist nicht zu unterschätzen, da das Fehlerpotential andieser Stelle sehr hoch ist. Wird bspw. für manche Funktionen vergessen die MandantenID zu berücksichtigen, kommt es zu einem Bruch der Datenisolierung zwischen den Man-

44

iterakonf-elb-493276328.eu-central-1.elb.amazonaws.com

6.6 Preisberechnung

danten. Das Potenzial kann aber dadurch reduziert werden, dass die Änderung von derDatenebene hin zu den Ressourcen durchgeführt wird. Dadurch propagiert die Änderungvon den Repositories über die Services zu den Ressourcen. Gleichzeitig ist es an dieser Stelleessentiell, dass Funktionstests für die Multimandantenfähigkeit geschrieben wird. Dadurchlassen sich viele Datenfehler bereits finden.

6.6 Preisberechnung

In diesem Abschnitt soll ein grober Überblick über die entstehenden Kosten für den darge-stellten Systemaufbau berechnet werden. Personalkosten sind in dieser Berechnung nichtberücksichtigt. Die folgenden Preise sind alle für die Region EU(Frankfurt), auch wenn sie inDollar angegeben sind. Zusätzlich wurden sie für eine einfachere Berechnung entsprechendgerundet.

Zunächst wird eine EC2 Instanz benötigt, diese wird t2.medium bezeichnet und besitztzwei virtuelle Prozessoren mit vier GB Arbeitsspeicher. Eine Speicherung ist nur über extraeingebundene Laufwerke möglich. Der Preis für die Instanz beträgt ca. 40$ pro Monat.

Für die Datenspeicherung in einer MySQL Datenbank wird eine Instanz des Typs db.t2.medium herangezogen. Dieser Typ besitzt, wie die EC2 Instanz, zwei virtuelle Prozesso-ren und vier GB Arbeitsspeicher. Die Speichergröße für die Datenbank wurde standardmäßigauf 20 GB gelassen. Die Netzwerkleistung wird mit gering bis mittel ausgeschrieben, wasfür den Anwendungsfall des MVP ausreichend ist. Die Kosten belaufen sich auf rund 62$pro Monat.

Für die Kommunikation von außen wird ein Load Balancer genutzt. Der Preis setzt sich auszwei verschiedenen Aspekten zusammen. Zunächst ist der Fixpreis mit rund 20$ pro Monatanzusetzen. Gleichzeitig wird von Amazon eine variable Berechnung auf Basis der LCUdurchgeführt. Weil dafür aber keine Datengrundlage über die Anzahl der Verbindungen undBandbreite vorliegen, ist eine Berechnung des variablen Preises nicht eindeutig möglich. Fürdas MVP wird jedoch zunächst von einer LCU pro Stunde ausgegangen, daraus ergibt sichein Preis von rund 6$ pro Monat. Alternative könnte der Konzeptpart vom ELB weggelassenwerden, um die Kosten zu reduzieren. Dann muss für die Anwendung die Verwaltung desHTTPS Endpunktes durch die Benutzer selbst verwalten. Denn der ACM kann nicht aufEC2 Instanzen eingesetzt werden. Deshalb muss der Benutzer selbst ein Zertifikat erstellenlassen, einbinden und ggf. verlängern. Es würde also den Verwaltungsaufwand erhöhen.

Als weiteres wird die Route 53 als DNS System genutzt. Dafür fällt für die erstellte HostedZone eine vernachlässigbare Gebühr von 0,50$ pro Monat an. Durch die geringe Summewird sie in der Berechnung außen vorgelassen.

Als letztes gilt es noch die Kosten für die Dateispeicherung zu definieren. Für das EFSfällt eine Gebühr von 0,36$ pro Gigabyte an. Im aktuellen System liegt der Datenverbrauchfür neun Konferenzen bei 65 MB für 550 Bildern. Auch wenn diese Zahl stark von der jeweili-gen Konferenz abhängig ist, soll sie als Orientierung dienen. Der benötigte Speicherplatz fürdie Dateispeicherung ist sehr gering und nimmt nur minimalen Einfluss auf den Endbetrag.Er kann somit für das MVP zunächst vernachlässigt werden.

45

t2.medium

db.t2.medium

db.t2.medium


Zusammengerechnet ergibt sich daraus:

EC2 40 $+ RDS 62 $+ ELB 20 $+ LCU 6 $= 128 $

Diese 128$ pro Monat sind umgerechnet zum aktuellen Kurs (1$ = 0,86€) rund 110€ undals reine Betriebskosten anzusehen. Die Entwicklungskosten für das Erstellen der Benutzer-verwaltung sind dabei noch nicht mit eingerechnet. Basierend auf Gulp Freelancer Studie[Gmb17][fre17] wird für einen IT Freelancer im Durchschnitt knapp 90€ pro Stunde gezahlt.Wird der Stundensatz mit den Betriebskosten verglichen, fallen die laufenden Kosten in denHintergrund.

46

7 Ausbau der Architektur mit weiterenDiensten

In diesem Kapitel sollen weitere Dienste und Funktionen der Anwendung hinzugefügtwerden. Dabei ist das Ziel eine Optimierung des laufenden Zustands und eine bessere Ver-waltung der Anwendung innerhalb der Cloud zu erreichen. In den Unterkapiteln wird dieAnwendung weiterhin als einem Monolithen angesehen und eingesetzt. Die Informationender verwendeten Dienste basiert auf der Dokumentation von Amazon [Ama17a].

In Abbildung 7.1 ist eine auf die wesentlichen Aspekte reduzierte Übersicht von den neuangebundenen Diensten.

7.1 Entkopplung der statischen Webseiten

Die Entkopplung der Webseiten aus dem Backend-Server ist einer der ersten Punkte, dieoptimiert werden können. Das ermöglicht, dass Deployment zu verändern und die Webseitenunabhängig vom Backend Server zu aktualisieren. Dafür kann der S3 Dienst mit seinemBuckets als statisches Webhosting genutzt werden, wenn die entsprechende Option aktiviertist.

Ein Bucket ist eine flache Container Struktur, die keine hierarchischen Strukturen abbildet.Die Dateien werden als Objekte unter einem Schlüsselwort abgespeichert. Diese Schlüsselermöglichen es, ein Dateisystem logisch zu erstellen, denn sie setzen sich aus den Ord-nerbezeichnungen und Dateinamen zusammen. Auch wenn alle Objekte innerhalb einesBuckets auf einer Ebene liegen, stellt das Schlüsselwort den Pfad innerhalb eines logischenDateisystems dar.

Wird eine solche Struktur erzeugt, können auch mehrere Webseiten über ein Bucket bereitge-stellt werden. Bei einem Aufruf einer unspezifischen Seite oder dem Stammverzeichnis wirdvon dem S3 Bucket automatisch die konfigurierte Indexseite ausgeliefert. Wird jedoch anden Endpunkt ein logisches Verzeichnis oder Pfad angehängt, sucht der Service nach einemObjekt mit genau diesem Schlüssel. Wird dazu kein Objekt gefunden, wird automatisch nacheiner index.html Datei gesucht. Wenn kein Objekt oder keine Datei gefunden werden konnte,wird von dem Bucket eine Fehlermeldung generiert.

Die Entkopplung führt folglich zu einer geringfügigen architektonischen Veränderungdes Systems. Denn jedes Bucket bekommt einen, nach Bezeichnung und Region festgelegtenDNS Namen. Dadurch sind nun zwei Endpunkte vorhanden. Vor der Entkopplung wurdenalle Requests über eine DNS Weiterleitung vom Monolithen bearbeitet und darüber diestatischen Seiten ausgeliefert (vgl. Abbildung 7.2a). Nach der Entkopplung werden dieRequests, auf Basis des DNS Namens, auf zwei unterschiedliche Endpunkte aufgeteilt (vgl.Abbildung 7.2b).

47

7 Ausbau der Architektur mit weiteren Diensten

Abbildung 7.1 Vereinfachte Gesamtansicht der angebundenen AWS Dienste [eigene Darstellung]

(a) Vor der Entkopplung werden alle Requests zum Monolithen weitergeleitet

(b) Nach der Entkopplung sind die Requests für statischen Inhalt und Datenaufgeteilt

Abbildung 7.2 Verteilung der Requests für statischen Inhalt [eigene Darstellung]

48

7.1 Entkopplung der statischen Webseiten

Ein nennenswerter Punkt ist die Zugriffsberechtigung auf das Bucket. Damit Benutzerdie Daten abfragen können, muss zum einen die Access Control List angepasst werden, da-mit jeder Zugriff bekommt. Gleichzeitig ist auch eine Policy notwendig, damit die Benutzerauch das Recht besitzen die Objekte zu lesen.

Das Laden von einer der Webseiten würde keine HTTPS Verbindung benötigten, weilnur die Daten der Seite selbst geladen werden. Die jeweilige Seite sendet alle weiterenDatenabfragen über eine HTTPS Verbindung an das Backend System. Aber nach dem Ladender statischen Seite ist für den Benutzer diese in der Adresszeile nicht ersichtlich. Damitder Benutzer ein Gefühl von Sicherheit bei der Passworteingabe bekommt, sollten auchdie statischen Webseiten über eine HTTPS Verbindung übertragen werden. Mit diesemAnwendungsfall wird eine Einschränkung von S3 deutlich, denn ein Bucket kann lediglicheinen HTTP Endpunkt anbieten. Mithilfe des CloudFront Services kann dafür eine Lösungbereitgestellt werden.

CloudFront als HTTPS Endpunkt

CloudFront ist ein Content Delivery Network (CDN) Dienst, der die Daten oder Anwendun-gen von Kunden über die gesamte Welt (je nach Konfiguration) verteilt und so eine geringeLatenz mit hoher Übertragungsgeschwindigkeit erreicht. Ein Aspekt des Dienstes ist dieVerteilung von statischem Inhalt, darunter zählen auch die Webseiten aus den S3 Buckets.Zudem ist der ACM Dienst in CloudFront integriert und kann somit Zertifikate aus demManager nutzen. Anders als die bisherigen Dienste kann das CDN nur mit Zertifikatenvom ACM interagieren, die in der Region US-East (N. Virginia) enthalten sind, weil dasCDN keiner Region zugeordnet werden kann. Von dort aus wird das Zertifikat über allegeographischen Standorte verteilt.

Es gilt ebenso zu beachten, dass wenn bei der Konfiguration von CloudFront ein S3 Bucketausgewählt wird, kann als Sicherheitsfeature eine Access Identity erstellt werden. Wenn diesemit dem Bucket verbunden wird, kann der Zugriff explizit nur für die Identity zugelassenwerden. Wenn CloudFront für ein S3 Bucket konfiguriert wird, kann als Sicherheitsfeatureeine Access Identity erstellt werden. Im Zusammenhang mit einem Bucket, ist es dadurchmöglich, den Zugriff explizit nur für diese Identity zuzulassen. Der Nachteil ist jedoch, dassnur eine Standardseite definiert werden kann. Der Zugriff auf die Unterseiten ist dann nurnoch über eine vollständige Pfadangabe möglich. Alternativ kann der Zugriff von Cloudfrontauch auf den HTTP Endpunkt des Buckets geschehen. Dabei kann aber die Access Identitynicht genutzt werden und gleichzeitig wäre das Bucket für alle frei zugänglich.

Durch den Einsatz von CloudFront ändert sich die Abbildung 7.2b geringfügig zu Ab-bildung 7.3. Die Requests für die statischen Inhalte werden dann vom Route 53 Service aufden CloudFront Endpunkt weitergeleitet, der wiederum die Daten von einem S3 Bucketbezieht.

Das Deployment der Anwendung verändert sich geringfügig. Der in Kapitel 6 Abbildung 6.2beschriebene „Build Server“ Schritt muss verändert werden, denn die im vorhergehendenProzess erstellten Webseiten müssen nicht mehr in das Backendverzeichnis kopiert werden.Im Prozessschritt „AWS Deployment“ ist es anschließend notwendig, alle Webseiten über die

49


Abbildung 7.3 Request Routing mit CloudFront als HTTPS Endpunkt [eigene Darstellung]

SSH Verbindung auf die EC2 Instanz zu kopieren. Dort kann dann eine Synchronisierungmit dem S3 Bucket stattfinden und die Daten auf der Instanz wieder entfernt werden.

7.2 Alternative für die Datenspeicherung

In diesem Kapitel werden Optimierungen für die Datenspeicherung in das Filesystem undder Datenbanknutzung aufgezeigt.

7.2.1 Dateien

Im MVP wurde mit EFS bereits eine Dateispeicherung beschrieben, die den gleichzeitigenZugriff von mehreren Systemen zulässt. Daher eignet sich das EFS grundsätzlich für diemanuelle Skalierung (siehe Kapitel 7.4). Jedoch generiert diese Methodik immer einen manu-ellen Aufwand für das Einbinden des Dateisystems.

Mithilfe eines Übergangs von EFS zu S3 kann eine Optimierung durchgeführt werden.Denn der Vorteil, den die Speicherung in S3 besitzt, liegt in dem größeren Einsatzbereich.Anders als das EFS, ist S3 losgelöst von einer EC2 Instanz und kann so auch von außerhalbder AWS Cloud genutzt werden, z.B. von einem Unternehmensserver aus. Somit wird dieNutzung von der EC2 nicht mehr bindend. Allerdings hat diese Entkopplung einen negativenAspekt, denn für die Nutzung von S3 ist eine wesentliche Anpassung des Codes notwendig.

Der Aufwand für die Anpassung der Software ist nicht zu unterschätzen, da ein kom-pletter Dateiservice notwendig wird und die Speicherung in das Filesystem des Hosts zuFehlern oder Inkonsistenzen führen kann. Da die Verarbeitung der Dateien nur über dasSoftware Development Kit (SDK) von Amazon stattfinden kann, sollte in der Software dieseFunktionalität in einen eigenen Service gekapselt sein. Dieser muss jegliche physikalischeSpeicherung der Dateien übernehmen und der restlichen Programmcode muss auf die neueLogik des Service umgestellt werden (vgl. Abbildung 7.4).

Amazon sorgt dafür, dass die Daten letztendlich Konsistent über alle Speicherstellen sind.Da für die Hochverfügbarkeit von S3, die Daten über mehrere Datenzentren verteilt werdenmüssen, geht damit einher, dass Anfragen ältere Daten als Antwort bekommen können. Fürdas Verhalten beim Erstellen oder Aktualisieren gilt, dass wenn ein Objekt hochgeladenwird, eine Chance besteht, dass nachfolgende Leseoperationen keine Daten oder respektivebei einer Aktualisierung ältere Daten zurückliefert werden. Das gilt insbesondere auch dann,wenn das Hochladen einer Datei als „erfolgreich“ zurückgemeldet wird. Denn erst wenn

50


Abbildung 7.4 Der Zugriff auf die Dateien über einen neuen S3 Service [eigene Darstellung]

das Objekt vollständig über die Rechenzentren propagiert ist, enthält jede Antwort dengleichen und aktuellen Inhalt. Ein ähnliches Verhalten ist für das Löschen von Dateien zuberücksichtigen. Solange ein Löschvorgang nicht auf alle verteilten Datensätzen ausgeführtwurde, besteht auch hier die Chance, dass eine Antwort die noch vorhandenen Daten enthält.Änderungen an einem Objekt sind als atomare Operationen anzusehen, dadurch könnenkeine korrupten Daten oder teilweise verfügbare Daten in Antworten enthalten sein.

Amazon unterstützt bei S3 Buckets kein Sperren von Objekten, deswegen wird bei ei-nem fast zeitgleichen Hochladen einer Datei der Zeitstempel herangezogen. Die Datei mitdem aktuelleren Zeitstempel wird dann als korrekt angesehen und abgespeichert.

Für die Zugangssicherung wird IAM bzw. Policies von Amazon genutzt. Dort muss einBenutzer für den Zugang hinterlegt sein und entsprechende Berechtigungen besitzen, damiter Dateien lesen oder schreiben kann.

7.2.2 Datenbank

Für die Speicherung der Daten wird im MVP eine MySQL Instanz genutzt. Wenn für dieseeine Skalierung durchgeführt werden soll, ist eine komplett neue Instanz notwendig. Fürdas MVP ist die Nutzung einer bestehenden Architektur eine sinnvolle Maßnahme. DieKosten für eine solche Instanz bzw. Instanzen können jedoch weiter verringert werden.Denn Amazon bietet einen NoSQL Datenbank Dienst an, der ein monatliches kostenlosesKontingent besitzt.

Unterscheidung zwischen SQL und NoSQL Datenbank

Nachfolgend werden die Unterschiede zwischen SQL und NoSQL Datenbanken aufgezeigt.Als Grundlage wird [HMM14] herangezogen.

Ein Relational Database Management System (RDBMS) setzt als SQL Datenbank das ACID(Atomicity, Consistency, Isolation, Durability) Prinzip um. Dies ist zwingend erforderlich,wenn eine strikte Konsistenz über die Daten benötigt wird. Als Beispiel ist hier der Finanz-sektor zu nennen, wo keine zwei verschiedene Zustände herrschen dürfen. Gleichzeitigermöglicht ein solches System eine gute Kontrolle über die Struktur der zu speicherndenDaten. Es ermöglicht eine Abbildung von komplexen Datenstrukturen, die wiederum mitanderen Strukturen Abhängigkeiten abbilden können. Ein RDBMS besitzt den Vorteil ge-

51


genüber eines NoSQL Datenbank, dass mit Hilfe von Join-Operationen komplexe Abfragenan die Daten gestellt werden können. Das bedeutet, dass für hoch strukturierte Daten mitkomplexen Strukturen eine SQL einer NoSQL Datenbank zu bevorzugen ist. Dies bringtallerdings den Nachteil mit sich, dass für die Erstellung der Struktur bzw. Schemas viel Zeitbenötigt wird. Außerdem muss für die Bereitstellung der Daten in einem Frontend Systemu.a. auf komplexe Abfragen zurückgegriffen werden. Der am häufigsten genannte Nachteilist jedoch die Skalierung. Grundsätzlich sind beide Datenbank Typen bis zu einem gewissenGrad gleichermaßen Skalierbar. Erst wenn die Datensätze sehr häufig aktualisiert werden,kommt dieser Nachteil zum Tragen. Denn eine Aktualisierung sperrt den entsprechendenDatensatz bis alle Instanzen der Datenbank den Eintrag aktualisiert haben.

Die NoSQL Datenbanken hingegen setzen das BASE (Basically available, Soft state, Even-tually consistent) Konzept ein. Bei den Anforderungen Skalierbarkeit, Verfügbarkeit undEinfachheit ist dieser Typ häufig die bevorzugte Wahl. Denn sie gelten als die beste Möglich-keit unstrukturierte Daten abzubilden. Deswegen wird kein Schema verwendet um die Datenzu beschreiben, wodurch auch keine Tabellenstruktur notwendig ist. Es können aber alleTypen von Informationen gespeichert und auf einfache Weise für Frontendsysteme bereitge-stellt werden, ohne die Notwendigkeit von komplexen Anfragen. Die Verfügbarkeit zähltzu den wichtigsten Eigenschaften der Datenbank. Durch die Redundanz der Daten wirdversucht den Datenverlust bei einem Ausfall zu reduzieren. Ebenso wie SQL Datenbankenexistieren für diesen Typen Nachteile. Einer davon ist die Konsistenz. Denn werden kurznach einem Schreibvorgang zwei Anfragen gestellt, können beide unterschiedliche Resultate(aktualisiert und veraltet) liefern. Mit einer schnellen Schreibgeschwindigkeit wird versuchtdem entgegenzuwirken und das System letztendlich Konsistent zu bekommen. Im Vergleichzu SQL Datenbanken gibt es die NoSQL Technologie noch nicht so lange.

Alle Datenbanken unterliegen dem CAP-Theorem. Für RDBMS gelten die beiden Eigenschaf-ten Verfügbarkeit und Konsistenz. Für NoSQL Datenbanken hingegen Verfügbarkeit undPartitions Toleranz.

Bisher nutzt die Anwendung ein fest definiertes Datenbank Schema in einem RDBMS.Das Schema wird nur in selten Fällen verändert oder aktualisiert. Ebenso sind die Datensätzemit einem Fremdschlüssel untereinander referenziert. Allerdings ist die Anwendung sostrukturiert, dass nicht mit einer einzelnen Anfrage die vollständigen Daten gelesen werden.Sie ist modular gestaltet, damit jeder Teilbereich eigenständige Schnittstellen besitzt undseine Daten unabhängig aktualisieren kann. Deshalb ist eine Umstrukturierung der Datenvon einer SQL zur NoSQL Datenbank möglich. Die strikte Konsistenz eines RDBMS istnicht erforderlich. Die Attribute der Fremdschlüssel müssen weiterhin in den Datensätzenvorhanden sein, damit sie eindeutig zugeordnet werden können. Nachfolgend wird eineAmazon NoSQL Datenbank erläutert.

Amazon DynamoDB

Amazon nennt diesen Dienst DynamoDB und er basiert auf einer NoSQL Datenbank. Sie bie-tet eine Speicherung auf dem Datenmodell eines Dokuments oder auf Schlüsselwertpaaren.Ebenso bietet sie eine durchschnittliche Servicelatenz im einstelligen Mikrosekundenbereichund passt die Datenverwaltung selbständig an, falls die Latenzen zu hoch werden. Gleichzei-tig hat sie eine gute Skalierbarkeit, da Einheiten wie die Anzahl virtueller Prozessoren oder

52


die Größe des Arbeitsspeichers nicht vorhanden sind. Die Leistung der Datenbank kann nurüber Schreib- oder Lesekapazitäten definiert werden. Durch ein automatisches Skalieren derKapazitäten, kann jederzeit der optimale Bedarf für die aktuelle Last genutzt werden.

Lese- und Schreibkapazitäten

Bei der Erstellung einer Tabelle oder eines Indexes in der DynamoDB kann angegebenwerden, wie viele Kapazitätseinheiten zur Verfügung stehen. Die Lese- und Schreibkapazi-täten sind geringfügig unterschiedlich definiert. Eine Einheit hat grundsätzlich immer nureine Operation pro Sekunde, jedoch unterscheidet sich die Menge an verarbeiteten Datenpro Operation. Eine Leseeinheit kann bis zu vier KB an Daten pro Operation lesen. EineSchreibeinheit kann bis zu einem KB schreiben. Wenn mehr Daten pro Anforderung gelesenoder geschrieben werden müssen, sind weitere Einheiten notwendig. So können bspw. mitvier Leseeinheiten bis zu 16 KB pro Sekunde gelesen werden und mit vier Schreibeinheiten,vier KB geschrieben. Für die DynamoDB beträgt die maximale Größe eines Eintrags 400 KB.

Eine gute Auswahl der richtigen Kapazitäten ist eine entscheidende Größe die, ohne Autoska-lierung, gut überlegt werden sollte. Wenn die Lese- oder Schreibanforderungen das Limit fürdie Tabelle oder Index überschreiten, werden die Anforderungen ausgebremst bzw. mit demHTTP Statuscode 400 und einer Fehlermeldung zurückgewiesen. Bei der Verwendung vonAutoskalierung wird ein Minimum und Maximum von Kapazitäten sowie eine prozentualeGrenze für die Auslastung angegeben. Das System versucht immer an dieser Grenze zuoperieren, bei einer geringen Auslastung werden Kapazitäten immer weiter abgeschaltet,bis zu der minimalen Anzahl. Analog gilt, dass auch für höhere Lasten, bei der weitereKapazitäten bis zum eingestellten Maximum hinzugefügt werden, falls die gesetzte Grenzefür die Auslastung überschritten wird. Die Kapazitäten verursachen dabei nur Kosten proStunde, solange sie aktiv sind.

Preisberechnung

Das macht die Preisberechnung komplizierter als bei einer festen MySQL Instanz. Durch dasvon Amazon pro Monat kostenlos bereitgestellte Kontingent von 25 Lese- und Schreibkapa-zitätseinheiten sowie 25 GB Datenspeicher, können bereits pro Sekunde 100 KB gelesen und25 KB geschrieben werden, ohne das Kosten dafür entstehen. Eine zusätzliche Leseeinheitkostet 0,0001586$ pro Stunde und die Schreibeinheit 0,000793$ und stellen somit sehr geringeGebühren dar. Durch automatisches Skalieren entstehen nur zu Stoßzeiten höhere Kosten.

Datenkonsistenz

Da die DynamoDB automatisch skalieren kann und die Datenverwaltung übernimmt, mussauch der Aspekt der Datenkonsistenz betrachtet werden. Eine DynamoDB ist immer nurinnerhalb einer AWS Region vorhanden und kann sich nicht mit anderen Regionen über-schneiden. So kann die Tabelle in zwei Regionen gleichzeitig sein, aber unterschiedlicheDaten besitzen. Des Weiteren sind die Daten auf mehrere Verfügbarkeitszonen innerhalbeiner Region verteilt. Das stellt sicher, dass Ausfälle in einer Zone die Daten in einer an-deren Zone nicht zerstören. Die Zonen sind untereinander mit Verbindungen geringerLatenz verbunden. Bei einem Schreibvorgang werden alle Datensätze in den Zonen meis-tens innerhalb von weniger als einer Sekunde aktualisiert, danach erst vollständig Konsistent.

53


Die Leseoperation einer DynamoDB unterstützt zwei verschiedene Konsistenzen:

• Letztendlich konsistente LesezugriffeBei einer Anfrage verhält sich die Datenbank wie ein S3 Bucket. Die Antwort kannsomit noch ältere Daten beinhalten ohne dass der letzte Schreibvorgang enthalten ist.Kurz darauf können die neuen Daten in einer Anforderung enthalten sein.

• Stark konsistente LesezugriffeBei einer starken Konsistenz enthält die Antwort die aktuellsten verfügbaren Daten. Indenen alle vorherigen erfolgreichen Schreiboperationen enthalten sind. Ausnahmenstellen dabei Netzwerkverzögerungen oder Ausfälle

Für die Lesekapazitätseinheit ist die verwendete Konsistenz entscheidend, denn eine Ein-heit mit Anfragen auf der Basis von letztendlicher Konsistenz, können doppelt so vieleOperationen ausführen wie stark konsistente Einheiten. So können nicht kritische Datengünstiger geladen werden. Dieser Umstand macht es erforderlich, dass der Programmcodeauf hintereinander folgende Schreib/Lese Anforderungen untersucht wird.

Zugangskontrolle

Der Zugang zur DynamoDB ist über eine Authentifizierung und Zugangskontrollebenegeschützt. Ersteres ist über drei Typen möglich:

• AWS Root Benutzer:Der Zugang als Root Benutzer entfällt grundsätzlich.

• IAM Benutzer:Einen Benutzer in der IAM Verwaltung hinzufügen und dort mit der richtigen Berech-tigung Zugang gewähren. Über diesen Benutzer können Zugangsschlüssel generiertwerden. Die einen programmatischen Zugang zum System ermöglichen.

• IAM RolleÄhnlich zu dem Benutzer, jedoch sind die erstellten Zugangsschlüssel nur temporärfür den Zugang zu Diensten und Ressourcen nutzbar.

Für die Integration der DynamoDB müsste ein neuer Benutzer angelegt werden, da derZugangsschlüssel dauerhaft verfügbar sein muss, damit die Anwendung auf Daten innerhalbder DynamoDB zugreifen kann. Ebenso muss über die IAM Policies die notwendigenBerechtigungen gesetzt werden, da sonst die einzelnen Anforderungen an die Datenbanknicht erlaubt sind. Besondere Beachtung sollte an dieser Stelle der Zugang zur Datenbankfinden. Da diese ist nicht wie die anderen Services innerhalb des VPC angesiedelt ist,sondern außerhalb davon in der gesamten Region liegt, besitzt die Datenbank eine öffentlicheSchnittstelle und ist somit vom Internet erreichbar. Das hat den Grund, dass alle Systeme inderselben Region auch den selben Datenbank Service nutzen. Dies kann jedoch eingeschränktwerden, indem eine IAM Policy vorhanden sein muss, die explizit nur Verbindungen voneinem VPC Endpunkt erlaubt und alle anderen blockiert. Die Policy kann auch nur speziellauf die notwendigen Tabellen ausgerichtet sein.

54


Notwendige Änderungen am Code

Bei einer Änderung der dahinter liegenden Datenbank, müssen auch immer Änderungen imCode berücksichtigt werden. Die Analyse erfolgt auf Grundlage des Tutorials von [bae17].Für die Nutzung der neuen Datenbank müssen verschiedene Aspekte berücksichtigt werden.Es sind zwei zusätzliche Abhängigkeiten in die Anwendung notwendig. Das SDK vonAmazon und zusätzlich das Module „Spring Data DynamoDB“. Der Endpunkt und dieZugangsschlüssel für die DynamoDB müssen in die Konfigurationsdateien eingefügt werden.Diese sind innerhalb einer Konfigurationsklasse notwendig, damit ein DynamoDB Mappererstellt werden kann. Anschließend müssen für die Datenmodelle sowohl die Annotationenals auch die Objektreferenzen zu Attributen umgeändert werden, weil keine Join-Operationenmöglich sind. Der Primärschlüssel muss auf den String Datentyp geändert werden, da dieDynamoDB nur dann eine automatische Generierung eines Schlüssels ermöglicht. Die Syn-chronisierung der Schlüssel zu anderen Modellen bzw. Tabellen muss von der Anwendungübernommen werden. Dies ist gleichzeitig auch der kritischste Punkt in dem Übergang zueiner anderen Datenbank. Eine Kontrolle, dass alle Objektwerte korrekt aufgelöst werden,ist an diesem Punkt essenziell. Die Repositories für die Datenbankabfragen können dannohne weitere Änderung wiederverwendet werden. Es gilt außerdem zu beachten, dass fürdie lokale Entwicklung eine eingesetzte MySQL Instanz zu einer DynamoDB ersetzt werdenmuss.

Migration

Ein wichtiger Punkt bei einem Wechsel der Datenbank ist das Thema Migration bestehenderDaten. Amazon bietet dafür den Database Migration Service (DMS) an. Dabei werden dieDatenbanken als Endpunkte definiert und eine EC2 Instanz für die Replikation gestartet.Diese übernimmt die Übertragung von einer Datenbank in die andere. Mithilfe von erstelltenTasks kann eine Beschreibung der Migration durchgeführt werden. Jeder Task besteht ausder Definition des Quell und Zielsystems sowie Regeln für die Migration. Über letztereswird einerseits das entsprechende Schema mit den gewünschten Tabellen ausgewählt undandererseits kann damit eine Transformation der Daten durchgeführt werden, z.B. kann einPrefix für jede Tabelle angefügt werden. Das Prefix erlaubt es die Tabellen eindeutiger zuidentifizieren als es vielleicht in der relationalen Datenbank notwendig gewesen wäre, daalle vorhandenen Tabellen in der DynamoDB Ansicht angezeigt werden.

DMS unterliegt speziellen Limitierungen, auf die geachtet werden muss.

• Der Datentyp Number unterliegt einer Limitierung von 38 Stellen. Wird diese Anzahlüberschritten, wird die eingegebene Zahl als String Datentyp gespeichert.

• Ein Datentyp für das Datum ist in der DynamoDB nicht vorhanden und wird deshalbals String gespeichert.

• Der Service unterstützt nur die Migration von Tabellen mit einem einzelnen Primär-schlüssel und erzeugt bei zusammengesetzten Schlüssel einen Fehler, außer es wirdeine Transformation mit einem Objekt-Mapping durchgeführt. Dadurch weiß derService wie das zu erzeugende aus dem alten Objekt erstellt werden muss.

• Enthält die Datenbank ein Large Object (LOB), kann es nur in seinem Format gespei-chert werden, wenn es als Character Large Object (CLOB) vorliegen. Ansonsten wird

55


Abbildung 7.5 Darstellung des CloudWatch Systems mit möglichen Funktionen [Ama17a]

auf den String Datentyp zurückgegriffen.

Gerade der dritte Punkt führt bei der Migration von MySQL auf DynamoDB zu einem Fehler,da dort eine Mapping Tabelle vorhanden ist, die zwei IDs als Primärschlüssel besitzt. Deshalbmuss dafür bei der Migration ein Sonderfall eingeplant werden, weil keine Transformationund Object-Mapping in einem Migrationtask durchgeführt werden können.

Als letztes ist noch die Möglichkeit zu nennen eine Integration von Triggern für Lambda-Funktionen in der AWS durchzuführen. Dabei kann DynamoDB ein Event auslösen auf daseine Lambda-Funktion achtet. Diese kann anschließend automatisch Code ausführen undz.B. Daten nachbearbeiten oder Fotos skalieren.

7.3 CloudWatch

Mit CloudWatch bietet Amazon einen Dienst an, der zwei verschiedene Funktionen vereinigt.Darunter zählt das Monitoring und, mit CloudWatch Logs, auch das Logging. In diesemKapitel wird auf die beiden Punkte näher eingegangen und wie diese sich in das bestehendeSystem eingliedern lassen.

Monitoring

CloudWatch ermöglicht Datenwerte über Ressourcen und Anwendungen in der Cloud zusammeln. Abbildung 7.5 zeigt wie das System von CloudWatch aufgebaut ist. Es dientdabei als eine Art Repository für verschiedene Metriken. Diese zählen dabei als eine derKernkomponenten des Systems. Es existieren aktuell bis zu 722 vordefinierte Metriken in derCloud. CloudWatch ist aber nicht auf diese Anzahl beschränkt, sondern es erlaubt ebenfallsdie Definition von eigenen Metriken falls dies notwendig ist.

56

7.4 Skalierung

Mithilfe der Metriken können zwei verschiedene Aktionen durchgeführt werden. Zunächstermöglichen sie, die Erstellung von Statistiken. Diese können in einem Dashboard in derAWS Konsole dargestellt oder von einem eigenen Statistiksystem genutzt werden. Die ent-scheidende Funktion ist jedoch, die Nutzung eines erstellten Alarms. Sie ermöglichen dieBenachrichtigung auf Engpässe oder eine direkte Skalierung mithilfe einer automatischenSkalierung. Ein Alarm wird dabei auf eine Metrik angewendet und mit einem Schwellenwertwird definiert, wann dieser auslösen soll.

Die Nutzung benötigt keine Änderung an dem bisherigen Monolithen. Unter der Vorausset-zung, dass vorgefertigte Metriken wie z.B. die Prozessorauslastung, für die Überwachunggenutzt werden. Da die eingesetzte Metrik außerhalb des Monolithen angesteuert wird.Sollten die vorhandenen Metriken nicht ausreichend sein, ist eine Änderung im Monolithennotwendig, damit die gewünschten Daten an CloudWatch gesendet werden. Dies ist z.B.notwendig, wenn die vollständige Zeit eines Requests überwacht werden soll.

Die Nutzung der Prozessorauslastung als Metrik ergänzt die bestehende Architektur, wo-durch keine grundlegenden Änderungen durchgeführt werden müssen. Es ist nur erforder-lich die entsprechenden Einstellungen in der AWS zu setzen.

Logging

CloudWatch Logs ermöglicht die Überwachung, Speicherung und den Zugriff auf Log Da-teien verschiedenster Services. Über das Interface von CloudWatch Logs kann von zentralerStelle aus, auf alle Einträge der verbundenen Logs zugegriffen werden.

Der Dienst kann auf zwei verschiedene Weisen genutzt werden. Zunächst ist es möglich,eine Integration von CloudWatch in die Anwendungslogik durchzuführen, um den eigenenLogging Dienst zu ersetzen. Dies Bedeutet einen größeren Einfluss bzw. Veränderung auf dieArchitektur des Systems. Eine Alternative wäre die Nutzung eines AWS Dienstes, welcherauf den Instanzen selbst und nicht im Container ausgeführt wird. Dort kann während derErstellung einer Instanz oder auch nachträglich ein Agent installiert werden. Mithilfe derAgent Konfiguration können bestimmte Verzeichnisse im Dateisystem überwacht und diedarin enthaltenen Logdateien in den CloudWatch Dienst übertragen werden. Die letzteVariante erweitert nur die Architektur, ohne die bestehende zu verändern.

Ein wesentlicher Vorteil von CloudWatch ist die Nutzung von Metriken auf Log Einträge.Durch ein Filter und Pattern Matching können Einträge in den Logs analyisiert und aucheinzelne Werte extrahiert werden. Dadurch wird es ermöglicht anhand von LogdateienStatistiken oder Alarme zu erstellen wie beispielsweise Requestzeiten.

7.4 Skalierung

Durch eine horizontale Skalierung des monolithischen Backendservers kann auf einfacheWeise die Last auf mehrere Server verteilt werden. In diesem Kapitel sind verschiedeneMöglichkeiten, die jeweils unterschiedlichen Aufwand benötigten, erläutert.

57


7.4.1 Manuell

Die manuelle Skalierung des Servers ist die erste und naheliegende Möglichkeit. Sie ist fürden gegebenen Server nicht schwer durchzuführen, benötigt aber dennoch eine gewisseZeitspanne und ist nicht dynamisch. Für eine solche Skalierung wird zunächst eine weitereEC2 Instanz mit gewünschter Konfiguration erzeugt. Des Weiteren ist die Installation vonDocker und EFS notwendig. Wenn die Instanz grundlegend fertig konfiguriert ist, mussdas Deployment der Anwendung innerhalb der Jenkins Pipeline angepasst werden. Dafürist eine Duplizierung des Deploymentschritts innerhalb der Pipeline notwendig, mit einerAnpassung des Zielservers. Dadurch wird die Aktualisierung auf beiden bzw. mehrerenInstanzen möglich. Als letzter Schritt muss die Target Group vom Load Balancer angepasstwerden, damit die Requests auch an die neue Instanz geschickt werden.

Es ist ersichtlich, dass jede durchgeführte Skalierung diesen Aufwand erzeugt und dement-sprechend Arbeitszeit kostet. Die entsprechenden Arbeitsschritte können nach einer Zeitschneller ausgeführt werden, da bekannt wird, wo welche Funktionen sind. Jedoch mussberücksichtigt werden, dass manche Aktionen auf vorherig Aufbauen und somit eine Grund-wartezeit einhergeht, z.B. kann erst eine gestartete EC2 Instanz einer Target Group zugeordnetwerden.

Entscheidend ist der Zeitpunkt, wann eine Skalierung notwendig wird. Es bieten sichzwei Möglichkeiten an, um diese Entscheidung zu treffen. Zunächst kann, ebenfalls manuell,darauf geachtet werden, wann und wie viele Konferenzen zur selben Zeit sind und vorallem, wie viele Personen den Dienst aktiv nutzen. Jedoch sind das nur sehr ungenaue Anga-ben, die vielleicht auch teilweise unbekannt sind. Ebenso kann nur durch Erfahrungswertebestimmt werden, ob wirklich eine hohe Last erzeugt wird. Die zweite Möglichkeit ist dasKonfigurieren eines Alarms, der aktiviert wird, sobald die Last eine bestimmte Grenze, z.B.die CPU Auslastung, überschreitet. Dafür muss für die Instanzen bzw. mindestens eine, jenach Verteilungsstrategie des Load Balancers, überwacht werden. Der Alarm kann einenAdministrator benachrichtigen, der die Befugnis hat eine Skalierung durchzuführen. Dasführt zu einem weiteren Problem, wenn die folgende Überlegung eintritt. Angenommen dieLast wird am Wochenende, am Abend oder in der Urlaubszeit des AWS Verantwortlichenerzeugt. Eine Skalierung könnte infolgedessen nicht stattfinden.

7.4.2 Automatisch

Eine manuelle Skalierung ist zwar möglich, bringt aber eine Reihe von Nachteilen mitsich, die unpraktikabel und unzuverlässig sind. Amazon bietet eine Möglichkeit mit einerautomatischen Skalierung von Diensten diese Nachteile zu umgehen.

Die Autoskalierung beinhaltet drei Hauptfunktionen:

1. Überwachung des Zustands einer InstanzVon der Autoskalierung wird überwacht, ob die Instanz Daten empfangen kann undfunktionsfähig ist.

2. Automatisches Ersetzen einer InstanzSchlägt die Zustandsprüfung aus irgendeinem Grund fehl, ersetzt der Dienst dieInstanz automatisch durch eine neue.

58

7.4 Skalierung

3. Ausgleich auf mehrere VerfügbarkeitszonenDer Dienst kann über mehrere Verfügbarkeitszonen konfiguriert werden. Er sorgt dannfür die gleichmäßige Verteilung auf alle Zonen.

Die automatische Skalierung basiert auf der Nutzung einer Auto Scaling Group (ASG).Durch diese können Einstellungen für die Instanzen definiert werden, z.B. eine gewünsch-te Anzahl von Instanzen. Eine Startkonfiguration ermöglicht es, die vollständige Instanzzu beschreiben und Benutzerdaten mitzugeben. Die eingetragenen Daten können auchKommandozeilenbefehle sein. Für den Start einer EC2 Instanz ist eine Startkonfigurationnotwendig. Wenn Benutzerdaten mit angegeben sind, werden diese als letzten Schritt imBootprozess ausgeführt, nach der Ausführung ist die Instanz einsatzbereit.

Durch die Benutzerdaten ist eine Einbindung des EFS und die Installation von Dockerdurchzuführen. Durch die Möglichkeit Befehle für die Shell mitzugeben, kann ein DockerContainer mit der Anwendung gestartet werden. Daraus folgen jedoch zwei Bedingungen.Bisher wurde das Docker Image mit einer Datei kopiert und würde somit der skaliertenInstanzen nicht vorliegen. Deshalb muss ein Container Repository als Bezugspunkt erstelltwerden. Dafür eignet sich ein eigenes Repository oder das von Amazon bereitgestellte EC2Container Registry (ECR). Der Deploymentprozess wird dann dahingehend geändert, dassdas Image nicht mehr nur Lokal bereitgestellt, sondern ebenfalls in das ECR hochgeladenwird. Beim Ausführen der Startbefehle wird das Image aus dem Repository geladen undanschließend starten. Da der Nachteil durch das neue Repository so minimal und einfach zubeheben ist, stellt es keinen kritischen Aspekt dar.

Über die Startkonfiguration kann eine Instanz einer Target Group zugewiesen werden,dadurch wird die Last auf alle vorhandenen Instanzen verteilt und das Skalierungsziel wur-de erreicht. Daraus entsteht jedoch ein durchaus kritischer Punkt, denn wenn eine Instanzdurch die Autoskalierung erstellt wird, nutzt der Startbefehl das aktuelle bzw. eingestellteImage aus dem Repository. Das führt solange zu keinem Problem, wie keine Aktualisierungder Versionen durchgeführt wird. Denn dafür müsste mit dem aktuellen Systemaufbauder Container auf einer Instanz gestoppt und neu gestartet werden. Da einige Instanzendynamisch sind, können diese im Deploymentprozess nicht berücksichtigt werden und dieseälteren Container bleiben weiterhin bestehen. Das führt letztendlich dazu, dass die Requestsüber verschiedene Anwendungsversionen beantwortet werden und ggf. falsche Logik nutzen.

Dafür kann einen weiteren Dienst eine Lösung fungieren. Der Send-Command Dienstermöglicht einen Befehl an eine Gruppe von EC2 Instanzen zu schicken. Sie können dafürüber zwei mögliche Wege ausgewählt werden. Entweder durch eine explizite Auswahl derInstanzen oder durch das Selektieren anhand der zugewiesenen Tags einer Instanz. Beider Skalierung kann der erste Weg nicht genutzt werden, daher bleibt nur der zweite Weg.Das System ermöglicht es, anzugeben wie viele Instanzen gleichzeitig den Befehl ausfüh-ren sollen. Durch eine Beschränkung würde das Prinzip des Rolling Updates erzeugt undsomit eine permanente Verfügbarkeit gewährleisten. Dadurch wäre eine dynamische undautomatische Skalierung ohne Benutzerinteraktion möglich.

59


Abbildung 7.6 Schematische Darstellung des EC2 Container Service mit einem Cluster über zweiVerfügbarkeitszonen [Ama17a][modifiziert]

7.4.3 EC2 Container Service (ECS)

Die Umsetzung der beschriebenen Skalierungen ist nicht sonderlich komplex. Aber stattauf viele eigene Prozesse für die Skalierung zu setzen, ist ebenfalls die Nutzung des EC2Container Service (ECS) möglich. Damit bietet Amazon einen skalierbaren Container Mana-gement Service an, welcher den Betrieb von Container auf einem Cluster von EC2 Instanzenermöglicht. Dadurch muss sich, in Zusammenhang mit der automatischen Skalierung, nichtmehr um die Infrastruktur gekümmert werden. Statt eine eigene Methodik zum Verwalteneines Clusters zu erstellen und somit mögliche Schwachstellen oder Aspekte nicht zu be-rücksichtigen, kann auf eine bereits vorhandene Architektur von Amazon gesetzt werden.

In Abbildung 7.6 ist der grundlegende Aufbau des Container Dienst aufgezeigt:

• ClusterFür die Nutzung des ECS ist es notwendig ein Cluster zu erstellen. Dieser besteht ausbeliebig vielen EC2 Instanzen in einer oder mehreren Verfügbarkeitszonen innerhalbeines VPC Bereichs. Amazon setzt einen ECS Agenten auf jeder Instanz ein, um dieContainer zu verwalten und überwachen.

• TaskEin Task ist die kleinste Ausführungseinheit im Cluster von ECS. Er kann über verschie-dene Arten gestartet werden. Das manuelle Starten eignet sich für einmalige Tasks, dienach ihrer Arbeit wieder stoppen. Für wiederkehrende Aufgaben kann der manuelleTask periodisch eingeplant werden. Daneben existieren noch ein Service Scheduler fürlanglaufende Anwendungen und auch die Möglichkeit eigene Scheduler zu erstellen.

60

7.4 Skalierung

• ServiceEbenso wie der Task wird ein Service über eine Beschreibung definiert. Der ECSService steuert die Anzahl der laufenden Tasks und welche Revision der Taskdefinitionherangezogen wird. Wenn ein Task abstürzt oder nicht mehr reagiert, wird dieser durcheinen neu gestarteten ersetzt. Das Zusammenspiel der Service Definition und einemLoad Balancer wird dafür genutzt, um Anfragen auf die enthaltenen Container zuverteilen damit ein Lastausgleich stattfindet. Wenn eine Mindestanzahl von verfügbarenSystemen angegeben wird, kann ECS auch ein Rolling Update durchführen.

ECS Deployment

Für die Nutzung von ECS ist es erforderlich, dass ein paar Änderungen vorgenommen wer-den. Aus denselben Gründen wie Kapitel 7.4.2 wird ein erreichbares Container Repositorybenötigt. Nur dann können alle Instanzen das Image laden und starten.

Abhängig von der Task Definition und dem darin eingesetzten Docker Image existieren zweiMöglichkeiten eine Aktualisierung durchzuführen.

1. Wenn der Name und das Tag des Container Images gleich bleibt. Ist es nicht notwendig,eine neue Task Definition zu erstellen. Eine Aktualisierung des Service reicht aus, damitder Task aktualisiert wird. Da immer versucht wird das Image aus dem Repositoryzu laden, sobald ein Task gestartet wird, erhält die Instanz automatisch die aktuellsteVersion. Das Problem dabei ist, dass wenn das Repository nicht erreichbar ist oderNetzwerkprobleme auftreten, wird das lokal zwischengespeicherte Image genutzt. Dieneu gestartete Anwendung ist damit noch auf dem alten Stand.

2. Die bessere Variante ist, für jede Version des Container Images ein eigenes Tag zuverwenden. Dieses Tag sollte in einer neuen Task Definition als Container Imageherangezogen werden. Sobald der Service einen neuen Task mit der aktualisiertenTask Definition starten will, muss zunächst das neue Image geladen werden, da esnicht lokal vorhanden ist. Sollte dabei die Netzwerkverbindung abbrechen oder andereFehler auftreten, kann der Task nicht gestartet werden und der Service versucht eserneut.

Unabhängig davon, welche Variante eingesetzt wird, müssen zwingend die Parameter fürminimale und maximale Anzahl von laufenden Container berücksichtigt werden. Wennbspw. nur eine Instanz genutzt wird und eine minimale Verfügbarkeit größer null gewolltist, kann der Service die bestehende Anwendung nicht beenden. Gleichzeitig kann aber keinneuer Task gestartet werden, da der Port bereits genutzt ist oder nicht genügend Ressourcenvorhanden sind. Letzteres ist abhängig von der reservierten Zuweisung von Ressourcen andie Container.

Wenn ein Application/Network Load Balancer mit dem Service verbunden ist, kann einedynamisches Port Zuweisung stattfinden. Dann besteht nur noch die Restriktion mit denverfügbaren Ressourcen. Die dynamische Zuweisung ermöglicht es, eine beliebigen Port derInstanz in den Target Group zu registrieren, dadurch lassen sich mehrere Anwendungengleichzeitig auf der Instanz betreiben. Unter der Voraussetzung, dass die Task Definitiondahingehen konfiguriert ist.

61


Abbildung 7.7 Schematischer Aufbau für ein neue Deployment in einen ECS Cluster [eigene Darstel-lung]

62

7.4 Skalierung

Für eine Aktualisierung des Servers muss der Prozess auf dem Buildserver geringfügigangepasst werden. Abbildung 7.7 zeigt die neue Struktur. Das Artefakt wird vom BuildServer des Unternehmens erzeugt, anschließend wird es wie bisher auf eine EC2 Instanzübertragen. Das Docker Image wird über die Instanz in ein Repository hochgeladen. Überdie SSH Verbindung AWS CLI Befehle ausgeführt über die der bestehende ECS Clusteraktualisiert wird. Die Instanzen laden das neue Image aus dem Repository und startenanschließend einen neuen Container.

ECS Skalierung

Es gibt zwei, ineinandergreifende, Ansatzpunkte um eine Skalierung durchzuführen

• Cluster SkalierungFür die Skalierung der EC2 Instanzen innerhalb des Clusters ist eine ASG notwendig.Diese ist wie beim Kapitel 7.4.2 mit einer Startkonfiguration auszustatten. Jedochunterscheidet sich die Konfiguration, denn für eine Clusterinstanz ist der ECS Agentnotwendig. Es gibt zwei Möglichkeiten die Konfiguration zu gestalten. Aufwändigerund fehleranfälliger ist die Nutzung eines freien Betriebssystems und die nachträglicheInstallation des Agents mithilfe der Benutzerdaten. Die einfachere und sicherereVariante ist die Nutzung eines von Amazon bereitgestellten und für ECS optimiertenSystems. In beiden Fällen muss in den Benutzerdaten der Startkonfiguration dieKonfiguration des Agents durchgeführt werden, damit dieser sich an einem Clusteranmelden kann.

• Task SkalierungHierbei ist zwischen manuelle bzw. eingeplanten Tasks und denen innerhalb einesService zu differenzieren. Erstere besitzen nur die Möglichkeit eine Anzahl von ausfüh-renden Tasks zu definieren, basiert also auf keiner automatischen Skalierung und kannnur durch eine Änderung des Tasks selbst skaliert werden. Durch die Verwendungeines Service kann eine automatische Skalierung des enthaltenen Tasks durchgeführtwerden. Dafür muss bei der Erstellung des Service eine automatische Skalierung akti-viert sein. Anhand der Beschreibung kann die minimale, maximale und gewünschteAnzahl an Tasks sowie Richtlinien, ab wann ein hoch- bzw. runter skalieren stattfindetauf die eigenen Wünsche angepasst werden.

In den Richtlinien wird ein Vergleich der Metriken aus CloudWatch und der ge-wünschten Auslastung getroffen. Im ECS Bereich bietet CloudWatch Metriken fürden Prozessor und Speicher an. Dabei kann zwischen dem Cluster als Ganzes undeinzelnen Services differenziert werden. Bei letzterem sind die Datenpunkte der ServiceInstanzen aggregiert zu einem einzelnen Datenpunkt.

Erst das Zusammenspiel beider Skalierungen erreicht eine vollständige Automatisierung derInfrastruktur eines Container Clusters.

63

64

8 Aufteilung der monolithischen Architektur inkleinere Segmente

In den vorangegangenen Kapiteln wurde das System um verschiedene Services erweitertund skaliert. Dabei lag zu Grunde, dass die Anwendung als vollständiger Monolith weiterbetrieben wird. Allerdings ist die Skalierung des voll umfassenden Monolithen nicht not-wendig, da manche Teile des Systems nicht so umfangreich ausgelastet werden als andereund somit die Last nicht gut verteilt wird. In diesem Kapitel wird die Anwendung aufgeteilt,sodass nur die notwendigen Teile einer Skalierung unterliegen.

Abbildung 8.1 soll einen Eindruck vermitteln, in welchen Bereichen die meiste Last erzeugtwird. Die zugrundeliegenden Daten sind hypothetisch anzusehen, da von der Anwendungkeine Messwerte für die erzeugte Last vorliegen. Diese können auch nicht mehr im zeitlichenRahmen dieser Arbeit ermittelt werden. Durch die kumulierte Darstellung der Daten, stelltdie grüne Linie, die aktuelle Last auf dem Server dar. Sie teilt sich in drei Bereiche auf:

• statische DatenBei den statischen Daten handelt es sich um die Single Page Webseiten, welche vomBenutzer über den Server angefordert werden können. Sie nehmen nur einen sehrgeringen Teil der Last ein, da sie nur einmalig geladen werden müssen. Die weitereKommunikation geschieht über Anfragen auf einen anderen URL Endpunkt.

• teilweise dynamische DatenUnter diese Kategorie fallen Daten, die dynamisch erzeugt werden können, aberdie nach Veröffentlichung nur wenige Male geändert werden. Ein Beispiel dafürsind die Daten einer Konferenz, denn während diese eingetragen wird, verändertsich permanent. Sobald die Konferenz veröffentlicht wurde, sind die Daten fest undverändern sich nur noch geringfügig.

• dynamische DatenWährend einer Konferenz verändern sich manche Daten fortlaufend, z.B. durch dasStellen und Bewerten von Fragen. Die erzeugte Last hängt dabei sehr stark vonden aktiven Benutzern ab, da viele Anfragen an den Server geschickt werden. Diedynamischen Daten können zu hohen und kurzen Lastspitzen führen.

Durch die Unterteilung in die Bereiche soll gezeigt werden, an welchen Stellen die Last gene-riert wird und weiter betrachtet werden muss. Für den Bereich der statischen Daten wurdebereits in Kapitel 7.1 eine Möglichkeit aufgezeigt, diese vom Backend Server loszulösen. Fürdie anderen beiden Bereiche, wird in diesem Kapitel eine Lösung vorgestellt.

8.1 Die Anwendung als Datenbezugspunkt

Der Backend Server dient für einen Großteil der Anwendung als reiner Datenlieferant. DieseTeile beinhalten grundsätzlich keine Logik, da dort nur die Daten aus der Datenbank gelesen

65

8 Aufteilung der monolithischen Architektur in kleinere Segmente

Abbildung 8.1 Lastverteilung auf dem Server. Linien sind akkumuliert dargestellt. Die Darstellungnutzt hypothetische Daten [eigene Darstellung]

und für die Antwort in das JSON Format umgewandelt werden.

Das vorhandene System nutzt eine Kombination aus den Headerfeldern Etag und If-None-Match, um die Datenübertragung so gering wie möglich zu halten. Der Server generiert beieiner Anfrage ein Hashwert des resultierenden Objekts und sendet ihn bei der Antwort imEtag Headerfeld mit. Bei einer Anfrage hingegen, wird dem Server im If-None-Match Feldder letzte Wert des Etags übermittelt. Er berechnet seinerseits den aktuellen Hashwert. Nurwenn sich diese Werte unterscheiden, findet eine Datenübertragung statt. Bei einer Über-einstimmung der Werte wird mit dem HTTP Statuscode 304 „Not Modified“ geantwortet,wodurch eine unnötige Datenübertragung vermieden wird.

Nachteil des aktuellen Systems

Dieses Vorgehen hat allerdings einen gravierenden Nachteil. Damit der Server den Hashwertgenerieren kann, ist es erforderlich, dass die angeforderten Daten zunächst aus der Datenbankgeladen werden. Der Hashwert kann erst gebildet werden, wenn die Daten im Servervorhanden sind. Da die Anwendungen häufig Anfragen mit einem Etag generieren undüberprüfen, ob sich Daten geändert haben, sind immer Datenbankabfragen notwendig. Jehöher die Anzahl der Benutzer ist, desto häufiger wird die Datenbank beansprucht ohneMehrwert zu generieren. Abhängig vom Benutzerverhalten besteht die Möglichkeit, dasszuerst eine Skalierung der Datenbank erforderlich ist. Gleichzeitig sind die Ressourcen desServers durch diese Anfragen gebunden. Wodurch weniger Leistung für die eigentliche Logikzur Verfügung steht. Nachfolgend werden verschiedene Lösungsansätze dafür aufgezeigt.

8.1.1 Aufteilung in mehrere Server

Zunächst ist es möglich, den vorhandenen Monolithen in zwei separate Server aufzuteilen.Der erste Server übernimmt dabei die Anfragen für die teilweise dynamischen Daten unddient somit als reiner Datenbezugspunkt. Während die Logik für dynamischen Daten aufdem zweiten Server ausgelagert sind. Durch die Aufteilung wird es möglich, die Einheitenunterschiedlich zu skalieren. Somit wäre die Last auf den Servern verteilt, jedoch besteht

66


Abbildung 8.2 Aufbau des neuen Systems um wenig verändernde Daten vom Backend auszulagern[eigene Darstellung]

immer noch Handlungsbedarf bei der Datenbank, da die Anfragen unverändert hochbleiben. Der Vorteil dieser Lösung ist, dass keine Änderungen am Backend Server selbstdurchgeführt werden muss. Es existieren dadurch lediglich zwei verschiedene Endpunkte,die in der Anwendung oder Webseite berücksichtigt werden müssen.

Reduzierung der Datenbankabfragen

Die Datenbankabfragen können durch die Einführung eines Caches auf den Servern redu-ziert werden. Wenn nur ein einzelner Server genutzt wird, ist die Umsetzung erleichtert. Dajedoch der Server in einer Cloud betrieben wird und gleichzeitig einer Skalierung unterliegt,müssen zwei Aspekte berücksichtigt werden.

Es ist möglich den Cache auf jedem Server zu Nutzen. Dann muss jedoch dafür gesorgtwerden, dass bei einer Aktualisierung der Daten eine Invalidierung des Caches auf jedemServer durchgeführt wird. Das setzt voraus, dass ein Server die Verbindung zu allen ande-ren Servern kennt um den Befehl für die Invalidierung zu übermitteln. Alternative kannauch ein zentraler Cache für alle Server zur Verfügung gestellt werden. Somit wäre nur füreben diesen eine Invalidierung notwendig. Folglich wird die Last von der Datenbank aufden Server des Cache umgeleitet. Dieser muss wiederum überwacht und eventuell skaliertwerden können.

Beide Varianten haben somit nicht die optimalen Eigenschaften um das Problem effek-tiv zu lösen. Zumal selbständig für die Verfügbarkeit des Caches gesorgt werden muss.

8.1.2 AWS Dienste als Alternative

Mit CloudFront und S3 kann die Notwendigkeit eines Caches verhindert werden. Dabei wirddurch die bereits hohe Verfügbarkeit und Skalierbarkeit von S3 und CloudFront als CDNprofitiert. Abbildung 8.2 zeigt den Aufbau mit vier verschiedenen, miteinander agierendenAmazon Diensten. Dies ist nur der Ausschnitt für die teilweise dynamischen Daten undspiegelt nicht die gesamte Architektur wieder.

67


Für die Umstellung auf AWS Dienste ist eine generelle Änderung der Speicherlogik für dieDaten erforderlich. Statt in eine Datenbank zu speichern, werden die Daten direkt als JSONin einem Bucket gespeichert. Eine generelle Verarbeitungslogik in der Funktion kann weitergenutzt werden, da nur eine Anpassung der Speicherlogik notwendig ist. Im folgendenListing 8.1 ist Beispielcode dargestellt, welcher die neue Speicherlogik beschreibt. Werdenbeide Speichervarianten verglichen, ist die Nutzung von Hibernate definitiv einfacher. DurchCodeauslagerung kann die neuen Speicherlogik an anderen Speicherstellen wiederverwendetwerden.

Listing 8.1 Codebeispiel die notwendige Arbeit zum Ändern der Speicherlogik

@Overridepublic Set<PointOfInterest> updateOrCreatePoi(int conferenceId,

List<PointOfInterest> pois) {if(pois == null || pois.length() == 0){

return new ArrayList<>();}// ------------ old logic ------------return poiRepository.save(pois);// ------------ new logic ------------AmazonS3 s3client = new AmazonS3Client(new

ProfileCredentialsProvider());ObjectMapper objectMapper = new ObjectMapper();String key = "conference/" + conferenceId + "/pois"

S3Object object = s3Client.getObject(new GetObjectRequest(bucketName,key));

InputStream is = object.getObjectContent();BufferedInputStream bis = new BufferedInputStream(is);

StringBuffer jsonBuffer = new StringBuffer();String line;while((line = bis.readLine()) != null){

jsonBuffer.append(line);}

List<PointOfInterest> s3Pois =Arrays.asList(objectMapper.readValue(jsonBuffer.toString(),PointOfInterest[].class));

List<PointOfInterest> mergedPois = Stream.concat(s3Pois.stream(),pois.stream())

.distinct()

.collect(Collectors.toList());

String jsonObjectBytes = objectMapper.writeValueAsByte(mergedPois);s3client.putObject(new PutObjectRequest(bucketName, key, new

ByteArrayInputStream(jsonObjectBytes)));

return pois;}

68


Die Änderung der Speicherung hat einen erheblichen Änderungsaufwand für die Anwen-dung zur Folge. Durch eine Auslagerung in Dateien beinhaltet die Datenbank keine teilweisedynamischen Daten mehr. An dieser Stelle muss jedoch berücksichtigt werden, dass dieReferenten an zwei verschiedenen Stellen eingetragen sind, da sie eine 1:n Beziehung zu denVorträgen besitzen. Sie sind somit gleichzeitig als Datensatz unter einem Vortrag und alsvollständige Liste für den Administrator vorhanden. Das hat zur Folge, dass die Datenbankzusätzlich zu den dynamischen Daten eine Mapping Tabelle beinhalten muss, in der dieBeziehung zwischen Referent und Vortrag abgebildet ist. Denn wenn eine Änderung stattfin-det, benötigt die entsprechenden Aktualisierungsmethoden zusätzliche Logik. Damit sowohldie gespeicherten Referenten in der Vortragsliste als auch in den einzelnen Konferenzenaktualisiert werden können.

Die dargestellte Lösung sieht vor, dass im ersten Verarbeitungsschritt das API Gatewayund eine Lambda Funktion genutzt wird. Im nächsten Verarbeitungsschritt ist eine Kombi-nation von CloudFront und dem S3 Dienst umgesetzt.

API Gateway

Mit dem Gateway wird die Handhabung einer beliebigen Anzahl von APIs vereinfacht. Alszentraler Endpunkt ermöglicht er eine Abstraktion über die Verteilung der Anfragen aufverschiedenen Server oder Funktionen. In diesem Aufbau ist der API Gateway nur dafürzuständig, dass die Lambda Funktion vom Internet aus erreichbar ist. Der Endpunkt desGateways ist in zwei Bereiche unterteilt. Wird beispielsweise der Endpunkt www.iterakonf.de/api/konferenz/1/infos betrachtet, bildet der erste Teil www.iterakonf.de/api/den festen Bestandteil, der bei allen Anfragen gleich ist. Darüber wird die Anfrage andas API Gateway gerichtet. Der verbleibende Teil konferenz/1/infos beschreibt dieangeforderten Daten. Für das Gateway ist der hintere Teil unwichtig und wird durch eineWildcard ignoriert, wodurch er alle Anfragen an www.iterakonf.de/api/ an die LambdaFunktion weiterleitet.

Lambda Funktion

Die Lambda Funktionen sind Programmbausteine die einen kleinen Teil Logik des Pro-gramms enthalten und außerhalb einer vollständigen Anwendung ausgeführt werden kön-nen. Durch die Abstraktion der Serverinfrastruktur wird der komplette Verwaltungsauf-wands der Infrastruktur auf den Cloud Dienstleister ausgelagert. Dieser kümmert sichgleichzeitig auch um die automatische Skalierung, so dass jede Anfrage im Bereich vonMillisekunden beantwortet werden kann, unter Berücksichtigung der Funktionslaufzeit.Zusätzlich wird bei einer Lambda Funktion nur für die Ausführung gezahlt, solange keineAnfragen verarbeitet werden müssen, entstehen auch keine Kosten.

Die Anfragen der Anwendung enthalten wie bisher ein JWT im Authentication Header.Durch die Überprüfung des Tokens weiß die Lambda Funktion, dass der Benutzer korrektangemeldet ist und kann die Mandanten ID aus dem Token extrahieren. Aus der Anfrageheraus kann die Funktion den zweiten Teil aus der URL herauslesen und zusammen mitder Mandanten ID eine CloudFront URL für die angeforderte Datei erstellen. Die URL wirdmit einem privaten Schlüssel signiert, damit CloudFront den Zugriff gewährt. Die LambdaFunktion Antwortet mit einem redirect auf die CloudFront URL.

69

www.iterakonf.de/api/konferenz/1/infos

www.iterakonf.de/api/konferenz/1/infos

www.iterakonf.de/api/

konferenz/1/infos

www.iterakonf.de/api/


Abbildung 8.3 Resultierender Aufgabenbereich des Monolithen nach der Anbindung von verschiede-nen Amazon Diensten [eigene Darstellung]

CloudFront und S3

Die Anwendung selbst führt direkt den redirect aus und stellt eine Anfrage bei CloudFront.Der Dienst überprüft die Signierung der URL anhand des öffentlichen Schlüssels. Wenn derZugriff gewährt wird erhält die Anwendung die angeforderte Datei aus dem zugehörigenBucket. Sollte keine Datei dafür vorhanden sein wird der HTTP Statuscode 404 zurückgege-ben. Bei dieser Architektur wird ebenfalls auf die Kombination von Etag und If-None-Matchgesetzt, da die genutzten Dienste diese Felder im Header unterstützen und somit die Datennicht doppelt übertragen werden müssen.

Wird die vorgestellte Architektur betrachtet, könnte theoretisch die Lambda Funktion auchdirekt die Daten zurückliefern, wenn die Logik für den Datenvergleich implementiert wird.Hier kommt jedoch die Laufzeit der Lambda Funktion zu tragen, denn ein Zugriff auf dasBucket erzeugt eine Latenz. Dadurch wird die Bearbeitungszeit und somit die Kosten erhöht.Eine Erstellung der URL ist deutlich schneller durchgeführt als der Datenzugriff.

Die Architektur nutzt die vorhandenen Vorteile von den verschiedenen Diensten um einehohe Verfügbarkeit und Skalierbarkeit zu erreichen. Diese Faktoren werden vollständigvon Amazon übernommen und gewähren dadurch eine gewisse Sicherheit. Die LambdaFunktion bietet eine sehr geringe Laufzeit und wird ebenfalls automatisch von Amazonskaliert, falls eine höhere Last auftritt. Zusätzlich fallen nur Kosten an, wenn diese ausgeführtwird. Aber gleichzeitig erzeugt dieser Aufbau auch einen Nachteil, denn die Anwendungmuss sehr genau die JSON Dateien im Bucket administrieren und bei einer Änderung einesDatensatzes, alle referenzierenden JSON Dateien aktualisieren. Trotz dieses Umstandes istdies die beste Möglichkeit, teilweise dynamische Daten vom Server zu entfernen, damitdieser nur noch die dynamische Logik beinhaltet.

8.2 Analyse des verbleibenden Funktionsumfangs

In diesem Abschnitt wird festgelegt, welche Bereiche der Anwendung noch untersuchtwerden müssen. Abbildung 8.3 sind die Kernaufgaben des Servers abgebildet. In Kapitel7.1 wurde bereits das Ausliefern der statischen Webseite aus dem Monolithen entferntund durch eine Kombination von CloudFront und S3 ersetzt. Für das Bereitstellen der

70


Abbildung 8.4 Architektur für die Konfiguration von Microservices [eigene Darstellung]

Konferenzdaten wurde in Kapitel 8.1 eine Lösung über CloudFront, S3, API Gateway undLambda Funktionen erläutert. Der Monolith beinhaltet deshalb nur noch Aufgaben für dieVerwaltung der Daten, das Senden von Push Benachrichtigungen sowie die Abwicklung vonFragen und ihrer Bewertungen.

Zuerst müssen jedoch noch zwei wesentliche Punkte erläutert werden. Zunächst wirdbeschrieben, wie die Konfiguration für eingesetzten Microservices oder Lambda Funktio-nen durchgeführt werden kann. Der zweite Punkt ist die Veranschaulichung einer ServiceDiscovery für Microservices, um die Interaktion untereinander zu ermöglichen.

8.2.1 Konfiguration von Microservice und Lambda Funktionen

Im bisherigen Monolithen wurde alle notwendigen Werte durch eine zentrale Konfigura-tionsdatei gesetzt. Bei Mikroservices oder Lambda Funktionen ist eine Betrachtung desbisherigen Konfigurationsweges sinnvoll, denn durch die Anzahl und Verteilung der ver-wendeten Elemente kann sich der Konfigurationsaufwand stark erhöhen. Beispielsweisemüssen bei einer Änderung alle Konfigurationsstellen gesucht und geändert werden, wirdeine Konfiguration übersehen, können Fehler entstehen. Deshalb ist eine zentrale Stelleoder Mechanismus für die Bereitstellung der Parameter wünschenswert. Außerdem ist eineAufteilung sinnvoll, damit jede Teilanwendung nur die notwendigen Parameter enthält,z.B. braucht eine Entwicklungsphase keine Einstellungen für die Produktionsumgebung. Indiesem Kapitel wird deshalb kurz erläutert, wie die Konfiguration für Mikroservices oderLambda Funktionen durchgeführt werden kann.

Microservices

Über die Konfiguration können die Parameter für einen Microservice gesetzt werden. AlsBeispiel kann der Endpunkt für die Push Benachrichtigungen genannt werden. An dieserStelle gibt es zwei sinnvolle Möglichkeiten:

1. Konfigurationsdatei im ProgrammcodeWie beim Monolithen kann die Konfigurationseinstellungen für jeden Microservice ineiner eigenen Datei im Quellcode abgelegt werden. Durch mehrere Dateien könnenfür die unterschiedlichen Entwicklungsphasen, Konfigurationen bereitstehen. Je nacheingestellter Phase wird die entsprechende Datei geladen. Dadurch wird für jeden

71


Service eine Anzahl an Konfigurationsdateien notwendig. Solange kein Parametergeändert wird, der in mehreren Services genutzt wird, ist dies grundsätzlich keinProblem. Ansonsten müssten für alle betroffenen Services die Konfiguration ange-passt, der Service neu erstellt und deployt werden. Je nach Anzahl der eingesetztenMicroservices kann dadurch ein sehr hoher Aufwand entstehen.

2. Spring Cloud ConfigPrivotal stellt eine alternative bereit. Die Konfiguration der jeweiligen Microserviceskann durch einen Spring Cloud Config Server ausgelagert werden. Diese könnenbeim dem Server nach einer Konfiguration anfragen. Es ist ein einfaches Client-ServerModell bei dem die Konfiguration geladen wird.

Abbildung 8.4 zeigt, wie ein Spring Cloud Config System aufgebaut werden kann. Zunächsthaben wir im Unternehmen eine Versionsverwaltung, z.B. Git. Wenn ein Commit für dieKonfigurationskomponenten durchgeführt wird, erhält der Spring Cloud Config Server übereinen Webhook die Information, dass sich die Daten geändert haben. Der Server aktualisiertseinerseits die vorhandenen Parameter. Bei einem Start des Microservices wird einmaligdie Konfiguration vom Server geladen, sobald jedoch eine Änderung an den Parameterndurchgeführt wird, aktualisieren sich die Parameter in den Microservices automatisch.

Der Spring Cloud Config Server ist eine sehr einfache Möglichkeit, dynamische Konfi-gurationen für Microservices bereitzustellen. Dadurch das bereits Spring Boot eingesetztwird, entsteht nur ein geringer Aufwand das in Abbildung 8.4 dargestellte System um-zusetzen. Somit erscheint es die beste und einfachste Möglichkeit die Konfiguration vonMicroservices auszulagern.

Lambda

In [Mar17] wurden vier verschiedene Konfigurationsmethoden miteinander verglichen:

1. UmgebungsvariablenFür jede Lambda Funktion können eigene Umgebungsvariablen spezifiziert werden,über die es möglich ist, die Konfigurationsparameter zu übergeben. Die eingestelltenParameter können zudem über eine Verschlüsselung gesichert werden. Die Funktionkann einfach auf die Umgebungsvariablen zugreifen. Allerdings entstehen damit aucheinige große Nachteile, denn die Variablen sind fest an die Funktionen gebunden undkönnen nicht in Abhängigkeit der Phase gesetzt werden. Das bedeutet, wenn eineFunktion in die Produktionsphase hoch gestuft wird, müssen andere Parameter gesetztwerden. Damit dies nicht notwendig ist, könnte eine Funktion für alle Phasen (z.B. Dev,Test, Produktion) alle Umgebungsvariablen gleichzeitig besitzen. Dies würde je nachAnzahl von Parametern eine Vielzahl von Variablen bedeuten, wodurch gleichzeitigein neues Problem auftritt, da es leicht ist aus versehen eine Variable zu löschen.

2. Konfigurationsdatei in S3Als weitere Möglichkeit, kann eine Konfigurationsdatei in ein S3 Bucket abgelegtwerden. Innerhalb des Buckets können die Dateien für jede Phase abgelegt werden,jede beinhaltet nur die notwendigen Parameter und isoliert Fehler auf eine Phase.Allerdings muss die Funktion beim jedem Start die Datei aus dem Bucket laden,wodurch eine Latenz pro Aufruf entsteht.

72


3. Konfigurationswerte in DynamoDBStatt eine Konfigurationsdatei in S3 abzulegen, kann auch als Konfigurationspunkt eineDynamoDB genutzt werden. Dort können für die verschiedenen Phasen unterschied-liche Parameter hinterlegt werden. Auch hier verhält es sich so, dass jeder Start derFunktion eine Latenz erzeugt, da erst eine Anfrage an die DynamoDB durchgeführtwird.

4. Konfigurationsdatei neben dem FunktionscodeDie vermutlich einfachste und naheliegende Methode ist, das Erstellen einer Konfi-gurationsdatei die neben dem Funktionscode liegt. Das würde Vorgehen, wie es imaktuellen System betrieben wird, am nächsten entsprechen. Da dort auch pro Phaseeine Konfigurationsdatei liegt. Ein wesentlicher Nachteil wird sichtbar, wenn einegrößere Anzahl von Funktionen betrachtet wird. Denn wenn sie einen gemeinsamenParameter besitzen und dieser geändert wird, dann muss von allen Funktionen dieKonfigurationsdatei angepasst, die Funktion neu gebaut und hochgeladen werden.

[Mar17] hat ebenfalls die entstehenden Latenzen für die letzten drei Varianten untersucht.Die S3 Lösung würde eine Latenz von ca. 110 Millisekunden erzeugen, da eine LambdaFunktion aber im 100 Millisekunden Takt abgerechnet wird, müssen mindestens 200 Milli-sekunden bezahlt werden. Die Latenz für eine Konfiguration mit der DynamoDB liegt beica. 70ms und ist schon deutlich kleiner. Jedoch hebt sich die Konfigurationsdatei mit einerLatenz von zwei Millisekunden deutlich ab.

Welche Konfigurationsmethode ausgewählt wird, hängt somit stark von dem Anwendungs-fall ab. Je mehr Funktionen mit vielen Parametern existieren desto sinnvoller wird eineKonfiguration mit der DynamoDB, damit eine Änderung weniger Aufwand erzeugt. DieKonfiguration über S3 ermöglicht eine sehr einfache Änderung der Parameter, da mit wenigAufwand eine neue Datei hochgeladen werden kann. Bei einer eingeschalteten Versionierungdes Buckets ist jederzeit auch ein Rollback möglich. Allerdings geht das deutlich auf Kostender Latenz. Sowohl bei der DynamoDB als auch bei S3 muss sehr genau auf die Formatierungder Daten geachtet werden. Da bei einem Fehler die Parameter nicht geladen und somit dieFunktion nicht korrekt ausgeführt wird. Bei zeitkritischen Anwendungen bleibt einem nurdie Variante mit den Umgebungsvariablen oder der Konfigurationsdatei im Funktionscode,da die Parameter deutlich schneller geladen werden können.

Für die in diesem Projekt verwendeten Lambda Funktionen, ist es nur sinnvoll die Va-riante vier zu nutzen. Denn für die jeweiligen Phasen muss nur zwischen den Datenbankenunterschieden werden. Die Größe der Anwendung ist aktuell zu gering, dass sich eineKonfiguration über DynamoDB oder S3 lohnen würde.

8.2.2 ECS Service Discovery für Microservices

Bei der Verwendung von Microservices muss über die interne Kommunikation zwischenden Services nachgedacht werden. Denn sie müssen wissen, zu welcher Adresse sie welcheAnfrage schicken können. Gerade bei Microservices, die in einer fluktuierenden Umgebungsind, können sich die Adressen schnell ändern [SSV16][Ama17b]. Beispielsweise wenn einMikroservice oder Instanz ausfällt, wird einfach eine Neue erstellt, die eine andere Adressebesitzt. Die eingesetzten Mikroservices müssen ihre Anfragen daraufhin an die neue Instanzumleiten können.

73


Abbildung 8.5 Darstellung der Microservices Discovery anhand vorhandener Amazon Dienste [SSV16]

Eine solche Discovery kann auf zwei verschiedene Weg durchgeführt werden. Eine ma-nuelle Variante ist möglich, jedoch wird es schnell komplexe und umständliche bei einergrößeren Anzahl von Microservices oder einer häufigen Skalierung. Die bessere Variante istdie automatische Service Discovery, diese legt für jeden Microservice die richtigen Endpunk-te fest. [SSV16]

In diesem Kapitel werden zwei Möglichkeiten für eine automatisierte Service Discovery fürECS dargestellt. Die erste Variante wird vollständig mithilfe von Amazon Diensten erzeugt.Die zweite Möglichkeit ist die Nutzung einer Drittanbieter Lösung, wie beispielsweise NetflixEureka.

Verwendung von Amazon Diensten

Die Überlegungen zu diesem Kapitel stammen aus [Ama17b] und [SSV16]. In der Abbildung8.5 sind die eingesetzten Dienste aufgezeigt. Grundsätzlich funktioniert das Routing überden Route 53 DNS Dienst und eingesetzten Load Balancern.

Bei einem Erstellen oder Löschen eines Services in ECS wird mithilfe von CloudTrailein Event erzeugt, welches in CloudWatch verarbeitet werden kann. Dort wird auf dessenBasis ein Auslöser für eine Lambda Funktion ausgeführt. Die ausgelöste Funktion erzeugtbeziehungsweise löscht einen DNS Eintrag im Route 53 Dienst und den dazugehörigenLoad Balancer. Für die DNS Bezeichnung des Dienstes kann in der Lambda Funktion einNamensschema definiert werden.

Die eingesetzten Mikroservices müssen in dieser Architektur nur noch mit dem richtigen

74


Abbildung 8.6 Vereinfachte Darstellung der Architektur für die Nutzung von Netflix Eureka [eigeneDarstellung]

Namensschema definiert werden, dann löst das DNS die Anfragen auf und leitet sie an denLoad Balancer des Services weiter. Dieser übernimmt dabei die Aufteilung auf verfügbareMicroservices vor. Über Route 53 sowie den Load Balancer kann eine Verfügbarkeitsprüfungeingesetzt werden um Fehler in der Verfügbarkeit zu registrieren.

Über dieses System können auch Systeme für verschiedene Entwicklungsphasen, wie z.B.Development, Test oder Produktion, eingerichtet werden. Die Services können dabei ihreNamen beibehalten, nur laufen unter einer anderen DNS Zone.

Netflix Eureka

In [Ama17b] werden auch Drittanbieter Lösungen wie bspw. Netflix Eureka oder HashiCorpConsul genannt. In diesem Abschnitt basiert auf Überlegungen zu Netflix Eureka, die andereLösungen sind aber ähnlich aufgebaut.

In Abbildung 8.6 ist der Aufbau dafür dargestellt. Die Nutzung von Netflix Eureka setztvoraus, dass dafür eine Instanz bereitgestellt wird. Damit ein Failover möglich ist, unterliegendie Instanzen einer ASG, denen mehrere elastische IPs zur Verfügung stehen. Jeder vonden gestarteten Eureka Servern versucht sich eine der verfügbaren elastische IP zuzuweisen.Wenn ein Server ausfällt, wird die elastische IP wieder frei und ein neue gestarteter EurekaServer kann diese übernehmen. Bei mehreren gleichzeitigen Servern wird eine Replikationunter ihnen durchgeführt.

Wenn der Microservices startet ist der erste Schritt sich beim Eureka Server zu registrieren.Danach können alle Microservices am Eureka eine Service Discovery durchführen unddarüber den gewünschten Microservice ansprechen.

Die Integration mit Spring Boot ist dabei einfach durchzuführen, da bereits ein Modul

75


für Netflix Eureka existiert. Durch wenige Annotationen und Konfigurationsvariablen kannder Eureka Client in den Spring Boot Microservices aktiviert werden. Für entsprechendeAnfragen muss anschließend nur noch ein RestTemplate genutzt werden. Die Auflösunggeschieht automatisch durch Spring Boot. Ein Nachteil besteht jedoch für die Lambda Funk-tionen, da nicht auf das allgemeine DNS zugegriffen wird, muss auch die Funktion beiAnfragen an Microservices eine Service Discovery am Eureka Server durchführen. Weil dortaber kein Spring Boot eingesetzt wird, muss selbstständig der Server angesprochen werden.

Fazit für die Service Discovery

Beide Varianten sind eine sinnige Lösung dar, um die Service Discovery aufzulösen. DieLösung über Amazon hat den Vorteil, dass auf das DNS von überall zugegriffen werden kannund somit die Lambda Funktionen keine Service Auflösung implementiert haben müssen.Gleichzeitig wird durch den Route 53 Dienst eine optimale Verfügbarkeit gewährleistet,ohne dass weitere Aktionen notwendig sind. Das gleiche gilt für die Verwendung der LoadBalancer für die Services. Für sehr kleine Anwendungen, wie es aktuell bei diesem Projekt ist,wäre eine manuelle Lösung ohne Lambda und Events ebenfalls möglich, da die notwendigeKonfiguration begrenzt ist.

Bei Eureka hingegen muss eine interne Lösung aufgebaut und die Verwaltung der Anwen-dung selbst übernommen werden, da Amazon lediglich die Server Infrastruktur bereitstellt.Ebenso ist eine Integration in Lambda Funktionen mit mehr Aufwand verbunden. Hier istkeine vorläufige manuelle Konfiguration möglich. Es hätte jedoch den Vorteil, dass keineDNS Einträge vorhanden sind und Anfragen von außerhalb, die nicht explizit erlaubt sind,nicht aufgelöst werden können.

Beide Systeme ermöglichen eine Nutzung der Sicherheitsaspekte von der Cloud. Allerdingsist die Integration mit den Amazon Diensten besser. Da beide Systeme leicht umzusetzensind, aber der Netflix Eureka Aufbau laufende Instanzen benötigt, fällt die Wahl für auf dieDNS Lösung. Dafür ist zunächst auch eine manuelle Einstellung für wenige Dienste möglich,deshalb wird die Lambda Funktion nicht benötigt.

8.2.3 Feature: Fragen und Bewertungen

In Abbildung 8.1 wurde eine erhöhte Last bei vielen Nutzern durch die dynamischen Datenaufgezeigt. Unter diese Daten fallen die Fragen und Bewertungen, da sie sich zu jedemZeitpunkt einer Konferenz verändern können. Denn, jeder Benutzer hat die Möglichkeit,Fragen zu stellen und alle vorhandenen zu bewerten. Durch die sehr schnellen Änderungenist es nicht sinnvoll diese Daten als ein JSON Objekt in einem S3 Bucket zu speichern, wie esbei den teilweise dynamischen Daten möglich ist.

Deswegen besitzt diese Funktionalität Schnittstellen um Daten zu lesen und ändern. Dies istin der Architektur die einzige Stelle an dem der Server noch als Datenlieferant auftritt. Dielesende Operation wird jedoch nur beim initialen Laden der Fragen und bei Anfragen fürBewertungsdetails einer Frage benötigt. Ansonsten werden die neuen Fragen über die PushBenachrichtigungen übermittelt. Daher wird die meiste Last über die schreibende Operationgeneriert. Für das Entfernen des Bereichs aus dem Monolithen können zwei unterschiedlicheAnsätze verfolgt werden.

76


Abbildung 8.7 Vereinfachte Darstellung der Architektur mit einem Microservice für die Fragen [eigeneDarstellung]

Microservice als Betriebskomponente

Zunächst liegt die Überlegung nahe, die bestehenden Methoden in einen eigenen Micro-service auszulagern und diesen in der Cloud zu betreiben. In Abbildung 8.7 wird einestark vereinfachte Darstellung der entstehenden Architektur aufgezeigt. Der Load Balancerbekommt eine Filterregel, die zwischen den Anfragen für die Fragen und Bewertungensowie denen des Monolithen unterscheiden kann. Abhängig vom Filter werden die Anfragenan unterschiedliche Services weitergeleitet. Wie bereits erwähnt, werden neue Fragen überPush Benachrichtigungen verteilt, aber da diese Komponente noch im Monolith ist, wirdeine Verbindung zum Monolithen benötigt.

Diese Methode würde einen aktiven Service auf einer vorhandenen EC2 Instanz benötigen.Über den ECS Cluster kann eine automatische Skalierung für die Komponente durchgeführtwerden. Bei einer Skalierung benötigt die Komponente eine gewisse Startzeit um erreichbarzu sein. Jedoch wäre der volle Funktionsumfang über einen Endpunkt zu erreichen. Durchdie Möglichkeit weiterhin Spring Boot zu nutzen kann auf die Repositories zurückgegriffenwerden. Damit einher geht ein geringer Änderungsaufwand, weil die Funktionalität aus demBackend extrahiert werden kann.

Lambda Funktion als Plattform

Eine andere Alternative besteht in der Nutzung von Lambda Funktionen, da die Funktio-nalität nur für aktive Konferenzen notwendig ist und in kleine Logikbereiche aufgeteiltwerden kann. Außerdem muss sich um die Infrastruktur nicht weiter gesorgt werden, da sievon Amazon abstrahiert wird. Bei einer hohen Last wird die Funktion automatisch skaliert,ohne das eine hohe Startzeit notwendig ist. Allerdings erzeugt die Nutzung von LambdaFunktionen auch einen gravierenden Nachteil, denn eine Funktion kann nur einen einzelnenEndpunkt darstellen. Da diese Komponente lesende und schreibende Operationen besitztmüssen auch mehrere Funktionen vorhanden sein. Zusätzlich muss dafür das API Gatewayfür die Erreichbarkeit der Lambda Funktionen konfiguriert werden.

77


Abbildung 8.8 Vereinfachte Darstellung der Architektur mit Lambda Funktionen für die Fragen[eigene Darstellung]

Die Abbildung 8.8 zeigt eine resultierende Architektur mit Lambda Funktionen. Zunächstsind zwei separate Endpunkte notwendig, einer für den Monolithen und einer für die ausge-lagerte Komponente. Um Fragen stellen oder bewerten zu können, werden die Anfragen voneinem API Gateway an die entsprechende Lambda Funktion weitergeleitet. Die schreibendenLambda Funktionen müssen dabei eine Verbindung zum Monolithen besitzen um PushBenachrichtigungen absenden zu können.

Für die Nutzung der Lambda Funktion ist eine Änderung am Quellcode notwendig. InListing 8.2 ist der Beispielcode einer Lambda Funktion für das Stellen einer Frage darge-stellt. Die notwendigen Zugangsdaten für die DynamoDB Datenbank werden von der APIautomatisch aus einer speziellen Konfigurationsdatei im Klassenpfad gelesen. Anschließendwird die Datenbankverbindung aufgebaut und die Frage gespeichert. Weitere Logik kannaus der bestehenden Anwendung extrahiert und in die Lambda Funktion überführt werden.Insgesamt müssen für eine Auslagerung der Funktionalität sieben verschiedene LambdaFunktionen erzeugt werden um die bisherigen Schnittstellen und die damit verbundeneLogik abzubilden.

Es gibt zwei Möglichkeiten die Implementierungen zu organisieren:

1. Jede Funktion erhält ein eigenes Projekt, in welchem nur die eine Funktion imple-mentiert ist. Diese Lösung bietet den Vorteil, dass die Lambda Funktion keinerleiSeiteneffekte besitzt. Gleichzeitig aber den Nachteil, dass sowohl die Models als auchdie Datenbank Initialisierung im jedem Projekt vorhanden sein muss. Dadurch entstehteine hohe Redundanz für ein Funktionsgebiet.

2. In AWS muss bei der Konfiguration einer Funktion sowohl die Java Klasse als auchdie auszuführende Methode angegeben werden. Dadurch ist es möglich, dass alleFunktionen in einem Projekt realisiert sind. Diese Methodik hat den Vorteil, dasssowohl Model- als auch Code Duplizierung nicht notwendig ist. Allerdings mussdarauf geachtet werden, dass keine Seiteneffekte zwischen den Funktionen auftreten.Für jede Lambda Funktion muss eine JAR-Datei hochgeladen werden, welche deutlich

78


mehr als nur die notwendige Funktion beinhalten. Bei Änderungen muss daraufgeachtet werden, die richtige Funktion zu aktualisieren.

Für die hier genutzten sieben Lambda Funktionen ist die zweite Variante besser. Sie bieteteinen Überblick über alle Logikbausteine und reduziert gleichzeitig die Projektanzahl. Mitsteigender Anzahl der Funktionen sollten dennoch weitere Projekte erzeugt werden, damitdie JAR-Datei nicht zu groß wird und der Umfang zum Nachteil wird.

Listing 8.2 Codebeispiel als Lambda Funktion für das Stellen einer Frage

public class AskQuestionHandler implementsRequestHandler<QuestionVoting, QuestionResponse> {

private String DYNAMODB_TABLE_NAME = "QuestionVoting";private Regions REGION = Regions.EU_CENTRAL;

public QuestionResponse handleRequest(QuestionVoting voting, Contextcontext) {

AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard().withRegion(REGION).build();

DynamoDBMapper mapper = new DynamoDBMapper(client);

mapper.save(voting);

// Request an den Push Microservice senden

return voting;}

}

Entscheidung über die Ausführungsplattform

Grundsätzlich dienen beide Varianten als gute Lösung für die Entkopplung der dynamischenKomponente. Ebenfalls ermöglichen beide eine separate Skalierung der Schnittstelle, sodass auf eine höhere Last gut reagiert werden kann. Allerdings tritt bei einer Skalierungdes Microservice die Startzeit des enthaltenen Programms in den Vordergrund. Auch wenndiese mit Spring Boot sehr gering ist, bedeutet es dennoch eine Verzögerung, bei der dieLast bereits wieder sinken kann. Bei den Lambda Funktionen muss hingegen keine Startzeitberücksichtigt werden, diese wird direkt ausgeführt und ermöglicht dadurch eine schnellereund genauere Skalierung. Für die EC2 Instanz fallen laufende Kosten an, solange diesebesteht. Für die Funktionen fallen nur Gebühren für die tatsächliche Ausführung an.

Der Aufwand für die Konfiguration und Einrichtung zwischen beiden Varianten unter-scheidet sich leicht, jedoch ist diese nur einmalig durchzuführen. Da die Lambda Funktionenbesser auf Last reagieren sind sie einem Microservice gegenüber zu bevorzugen.

79


Abbildung 8.9 Vereinfachte Darstellung der Integration des Mikroservices für Push Benachrichtigun-gen [eigene Darstellung]

8.2.4 Feature: Push Benachrichtungen

Die Push Benachrichtigungen benötigen keine Skalierung, sie müssten theoretisch auch nichtaus dem Monolithen herausgenommen werden. Da sich die Logik in der Komponente aufdas Zusammensetzen von JSON und dem Senden an einen Firebase Endpunkt beschränkt.Bei der Implementierung und Inbetriebnahme traten in diesem Bereich jedoch einige Fehlerin der Struktur des JSON auf, wodurch ein häufiges Aktualisieren des Servers notwendigwurde. Das Herausziehen der Funktionalität ermöglicht eine Modularität zu erreichen,sodass Änderungen an der Struktur des JSON kurzfristig im System aktualisiert werdenkann.

Auch hier könnte eine Überlegung zwischen Microservice und Lambda durchgeführt wer-den. Aufgrund der Notwendigkeit von Websockets entfällt die genauere Betrachtung vonLambda Funktionen. Da diese nur dafür gedacht sind, kleine Logikbausteine schnell undkurz auszuführen. Sie sollen keine dauerhafte Anwendung ausführen und können es auchnicht, da die Zeit einer Ausführung auf maximal 300 Sekunden beschränkt ist. Websocketsversuchen jedoch eine permanente Verbindung zu einem Endpunkt aufzubauen, über diedann Daten geschickt werden können ohne immer wieder eine neue Verbindung aufzubauenzu müssen [FM11].

Deshalb bleibt der Microservice als mögliche Lösung übrig. In Abbildung 8.9 wird dieentstehende Architektur vereinfacht dargestellt. Sendende Serverdienste schicken ihre An-fragen an den Microservice und können danach ihre eigene Bearbeitung fortsetzen ohne,dass auf eine Antwort des Microservice gewartet werden muss. Es wird ein Load Balancermit eingestellter Filterregel genutzt, um die Anfragen zwischen dem Microservice undMonolithen aufzuteilen. Dies ist notwendig, damit die Web Anwendungen eine WebsocketVerbindung zum Service aufbauen können. Als Load Balancer kann nur der ein ApplicationLoad Balancer genutzt werden, denn nur er kann eine Weiterleitung für das WebsocketProtokoll durchführen.

80


Abbildung 8.10 Vereinfachte Architektursicht auf die drei entkoppelten Bereiche des ehemaligenMonolithen [eigene Darstellung]

Da die Verbindung mit einem dauerhaft laufenden Microservice aufgebaut wird, besteht sieüber die komplette Laufzeit des Service oder der iteraKonf Anwendung. An den Endpunktdes Microservice kann der Monolith die zu sendende Benachrichtigung schicken.

Grundsätzlich bedarf es für diesen Microservice keine Skalierung, da die erzeugte Lastsehr gering ist. Sollte dennoch eine Skalierung notwendig werden, ist eine Entscheidungzu treffen, ob eine vertikale oder horizontale Skalierung durchgeführt werden kann odersoll. Eine Vergrößerung der zur Verfügung stehenden Rechenressourcen ist leichter, alseine horizontale Skalierung. Denn der Load Balancer leitet die Websocketverbindungen zuunterschiedlichen Mikroservices weiter. So besitzt jeder Microservice einen Bruchteil vonallen Verbindungen. Damit alle Services die Nachrichten übertragen können, muss jedervon ihnen die Nachricht erhalten. Bei der jetzigen Architektur, würde gleichzeitig jedereine Push Benachrichtigung an die nativen Anwendungen schicken. Dadurch würde dieAnwendung mehrmals dieselbe Benachrichtigung erhalten. Damit eine horizontale Skalie-rung möglich wird, müsste die Funktionalität des Websockets zusätzlich in eine isolierteUmgebung gezogen werden, bei der nur die Websockets zu behandeln sind.

8.2.5 Feature: Daten Verwaltung

Wird an dieser Stelle nochmals die Abbildung 8.3 betrachtet, beinhaltet der ehemaligeMonolith nur noch eine Funktionalität. Die Verwaltung der Daten bezieht sich in ersterLinie auf die administrativen Schnittstellen über die der Administrator Konferenzdatenverändern kann. Da der Monolith im Grunde nur noch diese Funktionalität darstellt, kann erals Microservice für diesen Bereich angesehen werden. Mit ggf. Änderungen um die letztenÜberreste des Monolithen zu bereinigen.

81


Abbildung 8.11 Endgültiger Architekturaufbau mit den genutzten Diensten für die Umsetzungder betrachteten Themen. Ausgenommen davon ist der CloudWatch Dienst, der für die Übersichtweggelassen wurde [eigene Darstellung]

Die Last auf diesem Teil der Anwendung ist gering einzustufen, denn die Anzahl derbearbeitenden Benutzer ist sehr gering. Auch wenn eine Skalierung nicht zwangsweisenotwendig ist, kann der Service dennoch skaliert werden, wenn sich die Last erhöht. Esist nicht notwendig, dass die vorhandenen Mikroservices automatisch auf einzelne EC2Instanzen zugewiesen wird. Bei geringer Last können auch alle gemeinsam auf einer Instanzbetrieben werden.

Durch die Aufteilung der letzten drei Aufgabenbereiche des Monolithen ist, die in Abbildung8.10 dargestellte Architektur entstanden. Der Zugriff funktioniert über zwei unterschiedlicheEndpunkte. Diese können jedoch durch einen Route 53 DNS Eintrag noch so auf einenEndpunkt gelegt werden, dass sie über eine ähnliche URL aufrufbar sind.

8.3 Resultierende Gesamtarchitektur

Nachdem in den vorangegangenen Kapiteln viele Architekturänderungen vorgenommenwurden, ist in Abbildung 8.11 die komplette Architektur vereinfacht dargestellt. Vereinfachtbedeutet hier, dass z.B. ASG, Security Groups oder der CloudWatch Dienst nicht eingezeich-net sind, diese aber dennoch verwendet werden. Sie sind nicht in der Zeichnung enthalten,damit die Abbildung übersichtlich bleibt.

Die Anfragen werden alle vom Route 53 DNS aufgelöst und entsprechend weitergeleitet. Aufder linken Seite von der Abbildung 8.11 wurde CloudFront mit seinen zwei Verbindungenzu den Buckets der Webseiten und Daten eingezeichnet. CloudFront wird als CDN für eine

82

8.3 Resultierende Gesamtarchitektur

gute Verteilung über einem HTTPS Endpunkt eingesetzt.

Im mittleren Bereich der Abbildung 8.11 ist der Aufbau mit Lambda Funktionen dar-gestellt. Die Anfragen werden über das API Gateway zu den entsprechenden Funktionenweitergeleitet. Eine Funktion ist für die Bereitstellung der teilweise dynamischen Datenverantwortlich. Sie überprüft die Autorisierung für den Zugriff der Daten und erzeugt einesignierte CloudFront URL. Die Antwort der Funktion leitet ein redirect zu der erzeugtenURL ein. Deshalb ist auch eine Verbindung zu CloudFront eingezeichnet, um die Beziehungzwischen den Systemen darzustellen, obwohl diese eigentlich über einen neue Anfrage vonaußen dargestellt werden müsste. Die anderen Lambda Funktionen kümmern sich um dieFrage-Funktionalität indem sie eine Verbindung zu der Datenbank aufbauen und Benachrich-tigungen an die Geräte schicken kann. Dabei handelt es sich um lesende und schreibendeFunktionen. Die Lambda Funktionen werden nur für ihre Ausführungszeit berechnet und un-terliegen einer eigenständigen Optimierung, die vollständig von Amazon übernommen wird.

Im rechten Bereich ist das Microservice System in einem ECS Cluster dargestellt. Zweiverschiedene Microservices werden in ECS betrieben. Die notwendige Service Discoverywird über den Route 53 Dienst und die Load Balancer durchgeführt. Nur einer der beidenLoad Balancer ist aus dem Internet erreichbar, da der andere nur für internes Routing genutztwird. Die Services unterliegen jeweils eigenen Skalierungen und Überwachungsregeln.

83

84

9 Validierung der Anforderung

Die in Kapitel 5 gestellten Anforderungen werden in diesem Abschnitt auf ihre Umsetzunggeprüft.

Die erste Anforderung AN-1: Kosten versucht, das System mit minimalen Änderungenund angebundenen Amazon Diensten umzusetzen. In Kapitel 6 wurde dies mithilfe desMVP behandelt. Bei der Weiterentwicklung der Architektur fällt dieser Punkt jedoch weiterzurück, da mit jeder weiteren Optimierung und Erweiterung auch weitere Kosten erzeugtwerden. Wird allein die Skalierung des Monolithen betrachtet, erhöhen sich dadurch die ent-standenen Kosten. Die Anforderung kann deshalb dennoch als umgesetzt angesehen werden.

Für AN-2: Programmierumgebung sollte möglichst auf Java 8 und Spring Boot gesetztwerden. Die Microservices ermöglichen das Spring Boot Frameworks weiter zu nutzen.Für die Nutzung der Amazon Dienste, wie bspw. S3 muss das Amazon SDK zusätzlicheingebunden werden. Die Lambda Funktionen hingegen können kein Spring Boot benutzen,sie erlauben aber eine Programmierung in Java. Somit gilt auch diese Anforderung als erfüllt.

AN-3: Horizontale Skalierung wurde in mehreren Teilbereichen der Anwendung unter-schiedlich umgesetzt. Dazu wurde in Kapitel 7.4.2 der Monolith in einem ECS Clusterbetrieben. Bei einer hohen Auslastung wird dieser automatisch durch eine ASG skaliert.Die Skalierung der Anwendung wird über ein Alarmsystem von CloudWatch durchgeführt.Wenn der Alarm ausgelöst wird, skaliert der Cluster automatisch die Anwendung auf weitereInstanzen. In Kapitel 8 wurde das System auf Microservices umgestellt, wobei jeder Micro-service einer Skalierung unterliegen kann. Die Lambda Funktionen werden von Amazonautomatisch an die entsprechende Last skaliert. Durch die Abstraktion von Amazon musssich, für diesen Punkt, nicht weiter um Lambda Funktionen gekümmert werden. Durch dieAufteilung können einzelne Lastpotenziale der Anwendung separat skaliert werden. Wegender genauen Betrachtung der Skalierungsmöglichkeiten und den aufgezeigten Lösungen,kann diese Anforderung ebenfalls als erfüllt angesehen werden.

Bei AN-4: Austauschbarkeit soll das System modularer gestaltet werden, damit einzel-ne Programmteile unabhängig voneinander aktualisierbar sind. Diese Anforderung ist durchdie Entkopplung der Webseiten, dem Extrahieren der teilweise dynamischen Daten und demAufteilen in Lambda Funktionen sowie Microservices umgesetzt. Jeder einzelne Teilbereichkann separat über einen Deploymentschritt angestoßen und somit unabhängig voneinanderaktualisiert werden.

Für die AN-5: Verfügbarkeit sind in erster Linie die Amazon Dienste verantwortlich. SowohlDNS, ELB, EFS, S3 als auch Lambda Funktionen und das dazugehörige API Gateway sindhoch verfügbare Systeme die von Amazon kontrolliert und bei einem Fehlerfall ersetztwerden. Sowohl der Route 53 Dienst als auch ELB ermöglichen die Überprüfung der Verfüg-barkeit von angeschlossenen Systemen. Das gleiche gilt auch für ECS. Dort wird bei einem

85

9 Validierung der Anforderung

fehlerhaften Task automatisch versucht einen neuen zu starten. In Zusammenhang mit AN-4:Austauschbarkeit werden nur einzelne Teilbereiche der Anwendung ersetzt. Dies kann auchdurch ein Rolling Update durchgeführt werden, bei dem die Tasks innerhalb eines Servicenacheinander aktualisiert werden. Damit einher geht jedoch, dass der Cluster etwas größersein muss, damit die notwendigen Container gestartet werden können.

Als letzte Anforderung wurde die AN-6: Multimandantenfähigkeit aufgestellt. Dafür wirddem System eine weitere Komponente hinzugefügt, welche bei einer Anmeldung ein JWTerstellt, indem die Mandanten Kennung enthalten ist. Dieses Token muss bei jeder Anfragemitgeschickt werden, damit der Mandant identifiziert wird. Das System enthält dann dieLogik um nur Daten des entsprechenden Mandanten zu lesen oder zu ändern. Dadurch sinddie Daten von unterschiedlichen Mandanten voneinander getrennt.

Über den kompletten Entwicklungsprozess können alle Anforderungen umgesetzt wer-den. Wird nur die Endarchitektur betrachtet, muss die Anforderung AN-1: Kosten als nichtumgesetzt gelten. Da sie im Widerspruch zu den anderen Anforderungen steht, denn eineErweiterung mit mehreren Diensten ist nicht ohne weitere Kosten möglich. Die AnforderungAN-2: Programmierumgebung muss auch nur als teilweise umgesetzt angesehen werden, dadie Lambda Funktionen nicht auf Spring Boot basieren.

86

10 Fazit

Die Cloud wird immer wichtiger und interessanter. Amazon, Microsoft oder Google bauenmit ihren Plattformen die Bereiche IaaS, PaaS oder SaaS immer weiter aus. Die Cloud erleich-tert es, für kurze Zeit oder längere Zeiträume neue Instanzen zu mieten. Dies ist besondersim Bereich der Skalierung herausragend, da so optimal auf die Last reagiert werden kann.

Amazon wurde als möglicher Cloud Betreiber ausgewählt. Die Unterschiede zwischenden Betreibern sind jedoch so minimal, dass keine pauschale Aussage getroffen werdenkann, welcher Anbieter besser ist. Viel mehr hängt es davon ab, welche Anforderungen dieAnwendung besitzt. Bspw. kann die Nutzung von der Microsoft Cloud Vorteile bringen,wenn viele verschiedene Dienste und Anwendungen von Microsoft an das System angebun-den sind, da eine bessere Integration der Dienste möglich ist. Weil im Unternehmen bereitsdie Grundlage für AWS vorhanden ist, wurde Amazon als Anbieter ausgewählt.

Zunächst wurde Kubernetes als Orchestrierungstool in Betracht gezogen. Aber im Ver-lauf der Arbeit stellte sich heraus, dass es für diesen Anwendungsfall nicht erforderlich ist.Denn zunächst stehen die erzeugten Kosten keinem nennenswerten Mehrwert entgegen.Deswegen wurde der Amazon ECS Dienst genutzt. Beide Tools sind sich sehr ähnlich,der Hauptvorteil von Kubernetes ist die Entwicklung als OpenSource Software mit vielenUnterstützern. ECS hingegen ist eine reine Entwicklung von Amazon und deshalb aufdiese Plattform beschränkt. Das bedeutet, dass mit der Entwicklung für Kubernetes dieMöglichkeit besteht, die Anwendung auf vielen Plattformen ausführen zu können.

Azure [Cora] oder Googles eigene Compute Cloud [LLCb] bieten bereits einen Servicean, um direkt Kubernetes in der Cloud zu nutzen. Dadurch entfällt für die Benutzer eben-falls das Management für den Cluster, er kann somit den Fokus auf die Struktur des Clustersund die Anwendung legen. Während der Erstellung dieser Arbeit hat Amazon auf seinerhauseigenen re:invent Konferenz, ebenfalls einen solchen Dienst angeboten [Amaa]. DasKubernetes Grundlagenkapitel erhält dadurch wiederum eine höhere Bedeutung.

Diese Arbeit sollte als Analyse für eine Transformation einer internen monolithischenAnwendung in einen digitalen Service dienen. Dazu müssen notwendige Schritte für dieTransformation betrachtet und gleichzeitig auf wichtige Anforderungen eingegangen werden.Mit einem MVP wurde gezeigt, dass ein einfacher Betrieb in der Cloud auch für Monolithenmöglich ist. Dennoch bedarf es bei einer Transformation meistens Änderungen, die je nachumzusetzender Anwendung unterschiedlich aufwändig sind. Die Arbeit zeigt zudem, dassviele Vorteile der Cloud durch Nutzung weiterer Dienste hinzugefügt werden können, ohneeine massive Änderung an der bestehenden Anwendung.

Sollte die Anwendung für andere Personen oder Unternehmen außerhalb von iteratecgeöffnet werden. Ist für den Betrieb eine Betrachtung der Cloud definitiv sinnvoll. Dieentstehenden Betriebskosten liegen, für dieses Projekt, im Bereich von 100€ pro Monat und

87

10 Fazit

sind im Vergleich mit einer berechneten Entwicklerstunde minimal. Durch die Skalierungkann das System optimal für größere Lasten ausgelegt werden. Gleichzeitig kann die Arbeitals Hilfe bei der Beratung von anderen Kunden in ähnlichen Situationen herangezogenwerden.

88

A Datenbank Modell

conference

id INT(11)

code VARCHAR(50)

name VARCHAR(50)

hashtag VARCHAR(50)

date DATETIME

date_end DATETIME

image_name VARCHAR(200)

image_type VARCHAR(200)

teaser_headline TEXT

teaser_subheadline TEXT

wlan_ssid VARCHAR(200)

wlan_password VARCHAR(200)

Indexes

file

id INT(11)

speech_id INT(11)

title VARCHAR(255)

filename VARCHAR(255)

filetype VARCHAR(255)

Indexes

image

id INT(11)

conference_id INT(11)

name VARCHAR(50)

type VARCHAR(50)

path TEXT

thumbnail TEXT

ts TIMESTAMP

Indexes

info

id INT(11)


question TEXT

answer TEXT

order_position SMALLINT(5)

ts TIMESTAMP

Indexes

message

id INT(11)

msg_id VARCHAR(200)


from_user VARCHAR(200)

text TEXT

image_name VARCHAR(200)


image_path VARCHAR(200)

image_thumbnail VARCHAR(200)

created DATETIME

ts TIMESTAMP

Indexes

poi

id INT(11)


title VARCHAR(200)

location_name VARCHAR(200)

latitude DECIMAL(8,6)

longitude DECIMAL(8,6)

address TEXT

additional_text TEXT

is_main_place TINYINT(1)

Indexes

pushdevices

id INT(11)


device_token TEXT

platform VARCHAR(20)

ts TIMESTAMP

Indexes

question_vote

id INT(11)

question_id INT(11)

user_fingerprint VARCHAR(255)

vote TINYINT(4)

comment VARCHAR(100)

ts TIMESTAMP

Indexes

question_voting

id INT(11)

speech_id INT(11)

question TEXT

answered TINYINT(4)

score INT(11)

ts TIMESTAMP

Indexes

speaker

id INT(11)

title VARCHAR(50)

firstname VARCHAR(50)

lastname VARCHAR(50)

position VARCHAR(100)

company VARCHAR(100)

image VARCHAR(150)


vita TEXT

ts TIMESTAMP

Indexes

speech

id INT(11)


title VARCHAR(150)

keyword VARCHAR(50)

start DATETIME

end DATETIME

time_add_on VARCHAR(20)

place VARCHAR(50)

abstract TEXT

copyright VARCHAR(50)

isbreak TINYINT(1)

has_voting TINYINT(1)

allow_up_vote TINYINT(1)

allow_down_vote TINYINT(1)

allow_comments_by_vote TINYINT(1)

ts TIMESTAMP

Indexes

speech_speaker

speech_id INT(11)

speaker_id INT(11)

Indexes

weather_forecast

id INT(11)

time_of_retrieval TIMESTAMP

degrees SMALLINT(3)

weather_type VARCHAR(255)

poi_id INT(11)

Indexes

Abbildung A.1 Darstellung der Datenbankstruktur als Enitity-Relationship Modell [eigene Darstel-lung]

89

90

Glossar

ACM AWS Certificate ManagerAPI Application Programming InterfaceASG Auto Scaling GroupAWS Amazon Web Services

CDN Content Delivery NetworkCLI Command Line InterfaceCLOB Character Large Object

DMS Database Migration ServiceDNS Domain Name Service

EBS Elastic Block StorageEC2 Elastic Compute CloudECR EC2 Container RegistryECS EC2 Container ServiceEFS Elastic File SystemELB Elastic Load Balancing

FAAS Function-as-a-Service

IaaS Infrastructure-as-a-ServiceIAM Identity and Access Management

JWT JSON Web Token

LCU Load Balancer Capacity UnitLDAP Lightweight Directory Access ProtocolLOB Large Object

MVP Minimal Viable Product

PaaS Platform-as-a-Service

RDBMS Relational Database Management SystemRDS Relational Database Service

91

Glossar

S3 Simple Storage ServiceSaaS Software-as-a-ServiceSDK Software Development KitSLA Service Level Agreement

VPC Virtual Private CloudVPN Virtual Private Network

92

Literatur

[Amaa] Amazon Web Services, Inc. Amazon Elastic Container Service. url: https://aws.amazon.com/de/about-aws/whats-new/2017/11/introducing-amazon-elastic-container-service-for-kubernetes/ (besucht am29. 11. 2017).

[Amab] Amazon Web Services, Inc. Serverlose Datenverarbeitung und serverlose Anwen-dungen. url: https://aws.amazon.com/de/serverless/ (besucht am07. 12. 2017).

[Ama17a] Amazon Web Services, Inc. AWS-Dokumentation. 2. Okt. 2017. url: https://aws.amazon.com/de/documentation/.

[Ama17b] Amazon Web Services, Inc. Microservices on AWS. 2017. url: https://d0.awsstatic.com/whitepapers/microservices-on-aws.pdf.

[Atk14] Sam Atkinson. Why I hate Spring. 23. März 2014. url: http://samatkinson.com/why-i-hate-spring/ (besucht am 01. 08. 2017).

[bae17] baeldung. DynamoDB in a Spring Boot Application Using Spring Data. 24. Apr. 2017.url: http://www.baeldung.com/spring-data-dynamodb (besucht am20. 10. 2017).

[Ben+17] Christopher Bennage u. a. AWS to Azure services comparison. 24. März 2017. url:https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services (besucht am 20. 10. 2017).

[Cora] Microsoft Corporation. Introduction to Azure Container Service (AKS). url: https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes (be-sucht am 13. 11. 2017).

[Corb] Microsoft Corporation. Serverless Computing. url: https://azure.microsoft.com/en-us/overview/serverless-computing/ (besucht am 07. 12. 2017).

[Doca] Docker Inc. Docker Documentation. url: https://docs.docker.com/ (be-sucht am 11. 09. 2017).

[Docb] Docker Inc. What is a Container. url: https://www.docker.com/what-container#/virtual_machines (besucht am 07. 09. 2017).

[Doc16] Docker Inc. Docker for the Virtualization Admin. 2016.

[Dria] Drifty Co. Ionic - Build Amazing Native Apps and Progressive Web Apps with IonicFramework and Angular. url: https://ionicframework.com/ (besucht am31. 07. 2017).

[Drib] Drifty Co. Ionic - Developer Survey. url: https://ionicframework.com/survey/2017 (besucht am 31. 07. 2017).

[FM11] Ian Fette und Alexey Melnikov. The WebSocket Protocol. RFC 6455. InternetEngineering Task Force, Dez. 2011, S. 1. url: https://tools.ietf.org/rfc/rfc6455.txt.

93

https://aws.amazon.com/de/about-aws/whats-new/2017/11/introducing-amazon-elastic-container-service-for-kubernetes/



https://aws.amazon.com/de/serverless/

https://aws.amazon.com/de/documentation/

https://aws.amazon.com/de/documentation/

https://d0.awsstatic.com/whitepapers/microservices-on-aws.pdf

https://d0.awsstatic.com/whitepapers/microservices-on-aws.pdf

http://samatkinson.com/why-i-hate-spring/

http://samatkinson.com/why-i-hate-spring/

http://www.baeldung.com/spring-data-dynamodb

https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services

https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services

https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes

https://docs.microsoft.com/en-us/azure/aks/intro-kubernetes

https://azure.microsoft.com/en-us/overview/serverless-computing/

https://azure.microsoft.com/en-us/overview/serverless-computing/

https://docs.docker.com/

https://www.docker.com/what-container#/virtual_machines

https://www.docker.com/what-container#/virtual_machines

https://ionicframework.com/

https://ionicframework.com/survey/2017

https://ionicframework.com/survey/2017

https://tools.ietf.org/rfc/rfc6455.txt

https://tools.ietf.org/rfc/rfc6455.txt

Literatur

[Fou] The Apache Software Foundation. Architectural overview of Cordova platform -Apache Cordova. url: https://cordova.apache.org/docs/en/latest/guide/overview/ (besucht am 24. 07. 2017).

[Fow] Martin Fowler. Microservices Resource Guide. url: https://martinfowler.com/microservices/ (besucht am 10. 12. 2017).

[fre17] freelancermap. Freelancer-Kompass 2017. 17. Okt. 2017. url: https://www.freelancermap.de/marktstudie (besucht am 20. 10. 2017).

[Gita] GitHub Inc. Ionic GitHub Repository. url: https://github.com/ionic-team/ionic (besucht am 23. 08. 2017).

[Gitb] GitHub Inc. NativeScript GitHub Repository. url: https://github.com/NativeScript/NativeScript (besucht am 23. 08. 2017).

[GL02] Seth Gilbert und Nancy Lynch. “Brewer’s Conjecture and the Feasibility ofConsistent, Available, Partition-tolerant Web Services”. In: SIGACT News 33.2(Juni 2002), S. 51–59. issn: 0163-5700. doi: 10.1145/564585.564601. url:http://doi.acm.org/10.1145/564585.564601.

[Gmb17] GULP Information Services GmbH. GULP Freelancer Studie 2017. 2017. url:https://www.gulp.de/ (besucht am 20. 10. 2017).

[Goo] Google Inc. Container und ihre Vorteile | Google Cloud Platform. url: https://cloud.google.com/containers/ (besucht am 07. 09. 2017).

[HMM14] D. Hammes, H. Medero und H. Mitchell. “Comparison of NoSQL and SQLDatabases in the Cloud”. In: Proceedings of the Southern Association for Infor-mation Systems Conference. Macon, Georgia, USA, 2014. url: https://pdfs.semanticscholar.org/6ba4/407e8354020adfb0f9bbdb3524ec11630d30.pdf.

[Hof10] Benjamin Hoffmann. Hostvirtualisierung - Vergleich der Konzepte und Produkte. In:Virtualisierung: Techniken und sicherheitsorientierte Anwendungen. Aug. 2010.

[it] manage it. Umsatz mit Cloud Computing im B2B-Bereich in Deutschland von 2011bis 2015 und Prognose für 2020 (in Milliarden Euro). Hrsg. von Statista Statista -Das Statistik-Portal. url: de.statista.com/statistik/daten/studie/165388/umfrage/prognose- zum- umsatz- mit- cloud- computing/(besucht am 11. 12. 2017).

[KMK12] Rouven Krebs, Christof Momm und Samuel Kounev. “Architectural Concernsin Multi-Tenant SaaS Applications”. In: CLOSER 2012 - Proceedings of the 2ndInternational Conference on Cloud Computing and Services Science. Apr. 2012.

[Leo+17] Lydia Leong u. a. Gartner - Magic Quadrant for Cloud Infrastructure as a Service,Worldwide. 15. Juni 2017. url: https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519 (besucht am 30. 09. 2017).

[LLCa] Google LLC. Google Trend - Microservices. url: https://trends.google.com/trends/explore?date=today%205-y&q=Microservices (besuchtam 08. 12. 2017).

[LLCb] Google LLC. Kubernetes Engine. url: https://cloud.google.com/kubernetes-engine/ (besucht am 13. 11. 2017).

94

https://cordova.apache.org/docs/en/latest/guide/overview/

https://cordova.apache.org/docs/en/latest/guide/overview/

https://martinfowler.com/microservices/

https://martinfowler.com/microservices/

https://www.freelancermap.de/marktstudie

https://www.freelancermap.de/marktstudie

https://github.com/ionic-team/ionic

https://github.com/ionic-team/ionic

https://github.com/NativeScript/NativeScript

https://github.com/NativeScript/NativeScript

https://doi.org/10.1145/564585.564601

http://doi.acm.org/10.1145/564585.564601

https://www.gulp.de/

https://cloud.google.com/containers/

https://cloud.google.com/containers/

https://pdfs.semanticscholar.org/6ba4/407e8354020adfb0f9bbdb3524ec11630d30.pdf



de.statista.com/statistik/daten/studie/165388/umfrage/prognose-zum-umsatz-mit-cloud-computing/

de.statista.com/statistik/daten/studie/165388/umfrage/prognose-zum-umsatz-mit-cloud-computing/

https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519

https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519

https://trends.google.com/trends/explore?date=today%205-y&q=Microservices

https://trends.google.com/trends/explore?date=today%205-y&q=Microservices

https://cloud.google.com/kubernetes-engine/

https://cloud.google.com/kubernetes-engine/

[LLCc] Google LLC. SERVERLESS. url: https://cloud.google.com/serverless/(besucht am 07. 12. 2017).

[Mar17] Ernesto Marquez. Configure your Lambda functions like a champ and let your code sailsmoothly to Production. 25. März 2017. url: https://www.concurrencylabs.com/blog/configure-your-lambda-function-like-a-champ-sail-smoothly/ (besucht am 10. 11. 2017).

[McK16] John McKimm. Abstracting the Back-end with FaaS. 5. Juli 2016. url: https:/ / serverless . zone / abstracting - the - back - end - with - faas -e5e80e837362 (besucht am 20. 09. 2017).

[New15] Sam Newman. Building Microservices. O’Reilly Media, Inc., 10. Feb. 2015.

[NY89] M. Naor und M. Yung. “Universal One-way Hash Functions and Their Cryp-tographic Applications”. In: Proceedings of the Twenty-first Annual ACM Sym-posium on Theory of Computing. STOC ’89. Seattle, Washington, USA: ACM,1989, S. 33–43. isbn: 0-89791-307-8. doi: 10.1145/73007.73011. url: http://doi.acm.org/10.1145/73007.73011.

[PBG11] Torsten Posch, Klaus Birken und Michael Gerdom. Basiswissen Software-Architektur.dpunkt.verlag, 2011.

[PM] Niels Provos und David Mazières. “A Future-Adaptable Password Scheme”. In:Proceedings of the FREENIX Track: 1999 USENOX Annual Technical Conference.

[Pria] Privotal Software. Spring Boot. url: https : / / projects . spring . io /spring-boot/ (besucht am 31. 07. 2017).

[Prib] Privotal Software. Working with Spring Data Repositories. url: https://docs.spring.io/spring-data/data-commons/docs/1.6.1.RELEASE/reference/html/repositories.html (besucht am 04. 09. 2017).

[Rie11] Eric Ries. The Lean Startup. Crown Business, 2011.

[Rob] Mike Roberts. Serverless Architectures. url: https://martinfowler.com/articles/serverless.html (besucht am 07. 12. 2017).

[RV16] Rajesh RV. Spring Microservices. Packt Publishing, 28. Juni 2016.

[San15] Surasak Sanguanpong. “COMPARISON OF HASH STRATEGIES FOR FLOW-BASED LOAD BALANCING”. In: 6 (Dez. 2015), S. 259–268.

[Sba17] Peter Sbarski. Serverless Architectures on AWS. Apr. 2017.

[Sch14] Mathijs Jeroen Scheepers. Virtualization and Containerization of Application Infra-structure: A Comparison. University of Twente, 2014.

[SS75] J. H. Saltzer und M. D. Schroeder. “The protection of information in com-puter systems”. In: Proceedings of the IEEE. Bd. 63. Sep. 1975. url: http://ieeexplore.ieee.org/document/1451869/.

[SSV16] Pierre Steckmeyer, Chad Schmutzer und Nicolas Vautier. Service Discovery:An Amazon ECS Reference Architecture. 16. Mai 2016. url: https : / / aws .amazon.com/de/blogs/compute/service-discovery-an-amazon-ecs-reference-architecture/ (besucht am 30. 11. 2017).

[Staa] Stack Exchange Inc. Stackoverflow - Tag Search. url: https://stackoverflow.com/tags?tab=popular (besucht am 23. 08. 2017).

95

https://cloud.google.com/serverless/

https://www.concurrencylabs.com/blog/configure-your-lambda-function-like-a-champ-sail-smoothly/



https://serverless.zone/abstracting-the-back-end-with-faas-e5e80e837362



https://doi.org/10.1145/73007.73011

http://doi.acm.org/10.1145/73007.73011

http://doi.acm.org/10.1145/73007.73011

https://projects.spring.io/spring-boot/

https://projects.spring.io/spring-boot/

https://docs.spring.io/spring-data/data-commons/docs/1.6.1.RELEASE/reference/html/repositories.html



https://martinfowler.com/articles/serverless.html

https://martinfowler.com/articles/serverless.html

http://ieeexplore.ieee.org/document/1451869/

http://ieeexplore.ieee.org/document/1451869/

https://aws.amazon.com/de/blogs/compute/service-discovery-an-amazon-ecs-reference-architecture/



https://stackoverflow.com/tags?tab=popular

https://stackoverflow.com/tags?tab=popular

Literatur

[Stab] Statista. Quarterly revenue of Amazon Web Services from 1st quarter 2014 to 2ndquarter 2017 (in million U.S. dollars). url: https://www.statista.com/statistics/250520/forecast-of-amazon-web-services-revenue/(besucht am 06. 10. 2017).

[Syn17] Synergy Research Group. The Leading Cloud Providers Continue to Run Away withthe Market. 27. Juli 2017. url: https://www.srgresearch.com/articles/leading-cloud-providers-continue-run-away-market (besucht am30. 09. 2017).

[The] The Linux Foundation. Open Container Initiative | FAQ. url: https://www.opencontainers.org/faq (besucht am 07. 09. 2017).

[VMw] VMware Inc. Virtualization. url: https://www.vmware.com/de/solutions/virtualization.html (besucht am 07. 09. 2017).

[Web15] Phil Webb. How not to hate Spring in 2016. 29. Nov. 2015. url: https://spring.io/blog/2015/11/29/how-not-to-hate-spring-in-2016 (besuchtam 31. 07. 2017).

[YT15] Murat Yener und Alex Theedom. Professional Java EE Design Patterns. Wrox, 2015.

96

https://www.statista.com/statistics/250520/forecast-of-amazon-web-services-revenue/

https://www.statista.com/statistics/250520/forecast-of-amazon-web-services-revenue/

https://www.srgresearch.com/articles/leading-cloud-providers-continue-run-away-market

https://www.srgresearch.com/articles/leading-cloud-providers-continue-run-away-market

https://www.opencontainers.org/faq

https://www.opencontainers.org/faq

https://www.vmware.com/de/solutions/virtualization.html

https://www.vmware.com/de/solutions/virtualization.html

https://spring.io/blog/2015/11/29/how-not-to-hate-spring-in-2016

https://spring.io/blog/2015/11/29/how-not-to-hate-spring-in-2016

Documents

Fakultät für Informatik - iteratec...Fakultät für Informatik Studiengang Informatik (Master) Transformation einer internen Anwendung in einen digitalen Service Master Thesis von