Vergleich einer monolithischen Web-Applikation mit einer Microservice basierten Lösung
Evaluation and examination of web-technologies
Comparison of a monolithic web application with a microservice based solution
Masterarbeit
Zur Erlangung des akademischen Grades Master of Science in Engineering
der Fachhochschule Campus Wien
Masterstudiengang: Software Design and Engineering
Vorgelegt von:
Thomas Czilinger, BSc
Personenkennzeichen:
1810838033
Erstbetreuer / ErstbegutachterIn:
FH-Prof. Dipl.-Ing. Philipp Rosenberger Eingereicht am:
16.08.2020
Ich erkläre, dass die vorliegende Masterarbeit von mir selbst verfasst wurde und ich kei- ne anderen als die angeführten Behelfe verwendet bzw. mich auch sonst keiner unerlaubter Hilfe bedient habe.
Ich versichere, dass ich diese Masterarbeit bisher weder im In- noch im Ausland (einer Beur- teilerin/einem Beurteiler zur Begutachtung) in irgendeiner Form als Prüfungsarbeit vorgelegt habe.
Weiters versichere ich, dass die von mir eingereichten Exemplare (ausgedruckt und elek- tronisch) identisch sind.
Datum: 16.08.2020 Unterschrift:
Seit mehr als einer Dekade befinden sich Cloud-Technologien im Aufschwung. Neue Infra- strukturmöglichkeiten haben den Weg geebnet, um in der Welt der modernen Softwareent- wicklung neue Maßstäbe zu setzen. Hinzu kommt, dass sich auch Programmiersprachen und ihre zugehörigen Frameworks stark in die Materie des Cloud Computings entwickelt haben.
Die vorliegende Masterabeit beschäftigt sich mit dem Vergleich zweier Software Architektu- ren. Für den Vergleich werden dazu eine monolithische- und eine microservice-basierte Lösung herangezogen. Konkret wird damit die Fragestellung untersucht, welche Architekturform aus Sicht der Entwicklung in Bezug auf Implementierung, Performance und Skalierbarkeit besser geeignet ist, um in einer Cloud Umgebung betrieben zu werden. Der Vergleich wird mithilfe des Lasttest-Tools Apache JMeter durchgeführt, indem Requestoperationen mit einem, fünf, zehn und zwanzig Threads durchgeführt werden. Die Ergebnisse des Vergleichs zeigen deutli- che Schwächen bei der Umsetzung des Monolithen. Im niedrigen zweistelligen Thread-Bereich liefert der Test schon eine Fehlerrate von knapp 50%. Bei Verdoppelung der Requestanzahl liefern nur noch knapp 13% der Requests ein positives Ergebnis. Die microservice-basierte Lösung liefert sowohl in punkto Skalierbarkeit, als auch beim Lasttest positive Ergebnisse.
Die Durchsatzrate der Requests zeigt ein effizienteres Verhalten und verursacht deutlich we- niger Speicherverbrauch der Applikation im verwendeten Cloud Container. Außerdem zeigen Unterschiede in der Implementierung einen Mehraufwand im Bereich der Microservices ge- genüber des Monolithen. Dem hingegen steht jedoch der erhöhte Wartungsaufwand und die enge Koppelung einer monolithischen Implementierung.
Die Forschungsergebnisse dienen als klare Empfehlung, veraltete Architekturkonzepte zu überdenken und neu zu designen. Der historische Hintergrund eines Monolithen wirft einige Probleme in Bezug auf Wartung und Weiterentwicklung auf.
Cloud technologies have been on the rise for more than a decade. New infrastructure pos- sibilities have paved the way for setting new standards in the world of modern software development. In addition, programming languages and their associated frameworks have also developed strongly in the field of cloud computing.
This master thesis deals with the comparison of two software architectures. For the compari- son a monolithic and a microservice based solution are used. In concrete terms, the question is investigated which architecture form is better suited from the development point of view in terms of implementation, performance and scalability to be operated in a cloud environment.
The comparison is performed with the help of the load test tool Apache JMeter by performing request operations with one, five, ten and twenty threads. The results of the comparison show clear weaknesses in the implementation of the monolith. In the low double-digit thread range, the test already delivers an error rate of almost 50%. If the number of requests is doubled, only just under 13% of the requests deliver a positive result. The microservice-based solution delivers positive results both in terms of scalability and in the load test. The throughput rate of the requests shows a more efficient behaviour and causes significantly less memory consumption of the application in the used Cloud Container. Furthermore, differences in im- plementation show an additional effort in the area of microservices compared to the monolith.
However, this is offset by the increased maintenance effort and the close coupling of a mono- lithic implementation.
The research results serve as a clear recommendation to rethink and redesign outdated archi- tectural concepts. The historical background of a monolith raises some problems regarding maintenance and further development.
SQL Structured Query Language
.NET Dotnet
KPI Key Performance Indicator IaaS Infrastructure as a Service PaaS Plattform as a Service SaaS Software as a Service FaaS Function as a Service
SOA Service-Oriented Architecture
CNCF Cloud Native Computing Foundation DevOps Development and Operations
CI Continous Integration
CD Continous Delivery & Deployment UI User Interface
DEV Development Stage
FAT Factory Acceptance Test Stage PROD Production Stage
HTTP Hypertext Transfer Protocol CPU Central Processing Unit RAM Random Access Memory SPA Single-Page Applications DOM Document Object Model AWS Amazon Web Services CLI Command Line Interface NoSQL No Structured Query Language SOAP Simple Object Access Protocol XML Extensible Markup Language REST Representational State Transfer JSON Javascript Object Notation
API Application Programming Interface ORM Object Relational Mapping
EF Core Entity Framework Core
IDE Integrated Development Environment DTO Data Transfer Object
MB MegaByte
GDPR General Data Protection Regulation
Software Architecture Software Performance Web-Technologien Cloud Native Monolith Microservices
1. Einleitung 1
1.1. Motivation . . . 1
1.2. Zielsetzung . . . 3
1.3. Verwandte Arbeiten . . . 4
1.4. Struktur der Arbeit . . . 6
2. Herleitung der Bewertungskriterien durch Analyse von Cloud-Technologien 7 2.1. Cloud Computing . . . 7
2.1.1. Infrastructure as a Service . . . 9
2.1.2. Platform as a Service . . . 10
2.1.3. Software as a Service . . . 10
2.1.4. Function as a Service . . . 10
2.2. Cloud Native . . . 10
2.2.1. Microservices . . . 11
2.2.2. Container . . . 12
2.2.3. Continuous Integration & Continuous Delivery . . . 13
2.2.4. DevOps . . . 15
2.3. Monolith . . . 15
2.4. Twelve Factor App . . . 16
2.5. Bewertungsparameter . . . 18
2.5.1. Software-Performance . . . 18
2.5.2. Skalierbarkeit . . . 19
2.5.3. Implementierung . . . 21
3. Bewertungskriterien 22 3.1. Implementierung . . . 22
3.2. Software Performance . . . 22
3.2.1. Load Test . . . 22
3.2.2. Skalierbarkeitstest . . . 23
4. Technologien 24 4.1. .NET & .NET Core . . . 24
4.2. Blazor . . . 25
4.3. Entity Framework Core . . . 26
4.4. Heroku . . . 27
4.5. GitHub . . . 27
4.6. PostgreSQL . . . 28
4.7. MongoDB . . . 28
4.8. RESTful . . . 28
4.9. Apache JMeter . . . 30
5.1.1. Anforderungsmethode . . . 32
5.1.2. Funktionale Anforderungen . . . 32
5.1.3. Nicht-funktionale Anforderungen . . . 35
5.1.4. Use Case Diagramm . . . 36
5.2. Architektur . . . 37
5.2.1. Monolith . . . 38
Vorteile . . . 39
Nachteile . . . 39
Services . . . 39
5.2.2. Microservice-Architektur . . . 40
Vorteile . . . 41
Nachteile . . . 42
Services . . . 42
5.3. Implementierung . . . 44
5.3.1. Charakteristika der Backend Applikationen . . . 44
Entwicklungsumgebung . . . 45
API-Controller & Serviceimplementierung . . . 45
Authorisierung . . . 47
5.3.2. Datenbank . . . 48
Datenbankkontext in .NET Core . . . 49
5.3.3. Deployment Pipeline . . . 50
Buildpack . . . 51
5.3.4. Testkonfiguration . . . 51
Monolith . . . 51
Microservices . . . 52
6. Ergebnisse 54 6.1. Monolith . . . 54
6.1.1. Load-Test . . . 54
6.1.2. Skalierbarkeitstest . . . 56
6.1.3. Implementierung . . . 58
6.2. Microservice . . . 59
6.2.1. Load-Test . . . 60
6.2.2. Skalierbarkeitstest . . . 62
6.2.3. Implementierung . . . 68
7. Conclusio 70 7.1. Ausblick . . . 72
Literaturverzeichnis 74
Abbildungsverzeichnis 78
Tabellenverzeichnis 80
A. Anhang/Ergänzende Information 81
Die Evolution des Internets hat in den vergangenen Dekaden immer wieder revolutionäre Konzepte und Technologien hervorgebracht. Neben Weiterentwicklungen im Bereich der Pro- grammiersprachen und der Frameworks, haben sich auch die Möglichkeiten der Infrastruktu- ren verändert. Bis zur Einführung des Cloud Computings und sogenannter Prozess Container im Jahr 2006 [Bla20] [Osn20] war es für Unternehmen üblich, Applikationen auf eigener Infra- struktur zu betreiben. Durch die Veränderung, haben aber auch Unternehmen umgedacht und erkannt, dass das Hosting von Applikationen in der Cloud sinnvoll ist. Eigenschaften, wie et- wa Performance, Skalierbarkeit oder beispielsweise Ausfallsicherheit von Web-Applikationen, haben deutliche finanzielle Vorteile mit sich gebracht. Ein sehr starker finanzieller Vorteil hat sich auch in der Konzeption von Web-Architekturen, sogenannter „Microservices“ ergeben.
Vor der Einführung von Cloud-Systemen, mussten verteilte Systeme immer vorausschauend und sehr kostenintensiv geplant werden, um nicht irgendwann mit fehlender Erweiterbar- keit oder Performance-Engpässen kämpfen zu müssen. Verglichen damit, ist bei modernen Containerlösungen, sowohl vertikale als auch horizantale Skalierbarkeit meist durch konfi- gurierbare Management-Plattformen unterschiedlicher Anbieter, sehr einfach möglich. Der moderne Ansatz Microservices zu implementieren, bedeutet aber nicht, dass sie der einzi- ge Weg sind native Cloud-Applikationen zu erstellen. Im Gegensatz steht der sogenannte Monolith, der einen sehr zentralisierten Architekturansatz darstellt, Web-Applikationen zu veröffentlichen. Durch die Anwendung der Twelve Factor Methode, können auch zentrali- sierte Architekturen für das Hosting in der Cloud fit gemacht werden. [RK19, vgl. Seite 125]
Twelve Factor beschreibt zwölf Elemente, die erfüllt werden sollen, um Software-As-A-Service Applikationen, unabhängig von Programmiersprache und Datendiensten zu implementieren.
Die Faktoren werden im weiteren Verlauf der Arbeit beschrieben, da Sie zum Basiswissen der Arbeit beitragen. Monolithen werden heute durch den evolutionsbedingten Wandel des technologischen Fortschritts meist nicht mehr in Betracht gezogen, da die Verteilung von Systemen viel mehr Möglichkeiten bietet, um Ausfallssicherheits-, Skalierbarkeits- und Per- formanceszenarien maßgeblich zu verbessern.
1.1. Motivation
Die steigenden Anforderungen an Betriebe und deren Produkte bewirken, dass Anforderun- gen an Software und ihrer Auslieferungskette stetig steigen. Web-Technologien, Datenbanken und Container- Lösungen sind heutzutage so gut wie in jeder Branche und jedem Sektor
zu finden. Die Erwartungen von Kunden an ein Unternehmen steigen mittlerweile in viel kürzeren Zyklen und auch die Basisanforderungen werden immer selbstverständlicher. Ein gutes Vergleichsbeispiel stellt der Banking-Sektor dar. In den letzten Jahren hat sich die Nutzung von Online-Banking und digitalen Services stark vermehrt, da Kund*innen ihre Bankgeschäfte lieber von zu Hause aus erledigen und auf den Besuch einer Filiale verzichten.
Das untermauert die Gegenüberstellung der Nutzung von Online-Banking Diensten von 2007 bis 2019:
Abbildung 1.1.: Bevölkerungsanteil in Österreich, die Online-Banking nutzen von 2007 bis 2019 [Fig20]
Wie in Abbildung 1.1 zu erkennen ist, stieg die Nutzung von digitalen Bankdiensten von 2007-2019, österreich- und europaweit um über einhundert Prozent. Das bedeutet aber auch, dass die dafür vorgesehene Hard- und Softwareinfrastruktur, in dieser Dekade stark verän- dert werden musste. Aus den hohen Sicherheitsanforderungen für Dienste wie Online-Banking ergibt sich, dass diese nicht in einer öffentlichen Cloud gehostet werden können. Um die Per- formance und Skalierbarkeit in öffentlichen Bereichen gewährleisten zu können, wurde auf private Dienste gesetzt. Das bedeutet, dass man Cloud-Technologien in eine private Infra- struktur eingebettet hat und somit eine private Cloud geschaffen hat. Die Beliebtheit von Cloud-Diensten zeigt der nachfolgende Vergleich zwischen lokalen- und Cloudspeicherdien- sten.
Abbildung 1.2.: Vergleich Prognose lokaler vs Cloudspeicherdienste von 2015 bis 2025 [Fig19]
In Abbildung 1.2 ist erkennbar, dass die Speicherung des weltweiten Datenaufkommens im Jahre 2020 erstmals im Cloud-Sektor stärker sein wird, als auf lokalen Medien. Das Aufkom- men von dezentralen Speicherdiensten, wird sich laut Prognose, bis zum Jahr 2025 mehr als verdoppeln, hingegen werden sich lokale Speicherdienste um mehr als die Hälfte reduzieren.
Es ist anzunehmen, dass sich dieser Trend in den folgenden Jahren fortsetzen wird, da die Digitalisierung voranschreitet und in Zukunft immer mehr Services digital abrufbar sein wer- den.
1.2. Zielsetzung
Im Rahmen dieser Arbeit werden zwei unterschiedliche Softwararchitektur-Ansätze beleuch- tet, die heutzutage allgegenwärtig diskutiert werden und ein Hauptkriterium bei der Planung von Web-Applikationen darstellen. Es wird ein Vergleich angestrebt, der Aufschluss dar- über geben soll, welcher Architekturansatz für die Implementierung einer Web-Applikation besser geeignet ist. Bezugnehmend darauf, werden Implementierung, Performance und Ska- lierbarkeit als Mess- und Entscheidungskriterien betrachtet. Im Beitrag [ANS+17, vgl. Seite 3] wird gezeigt, dass die Komplexität einer Applikation durch Neu-Implementierung eines microservice-basierten Ansatzes vermindert wird, während die Skalierbarkeit ansteigt. Zu- sätzlich werden die Vor- und Nachteile beider Web-Technologien wissenschaftlich erarbeitet, um eine Abgrenzung in der Evaluierung zu schaffen. Daraus ergibt sich folgende wissenschaft- liche Frage:
Welche Software-Architekturform ist unter Verwendung von .NET Core 3.1 aus Sicht der Entwicklung in Bezug auf Implementierung, Performance und Skalierbarkeit in einer Cloud- Umgebung effizienter, Microservices oder Monolith?
Als Technolgien, wie schon in der Einleitung der Zielsetzung angedeutet, werden Microsoft Blazor und .NET Core 3.1 verwendet. Als Use-Case der Masterarbeit, wird eine Projektmanagement- Evaluierungs-Plattform entwickelt. Die Anforderungen an die Web-Applikation der vorlie- genden Forschungsarbeit werden vom Betreuer FH.Prof. Dipl.Ing. Philipp Rosenberger zur Verfügung gestellt, um seine Forschung im Bereich des IT-Projektmanagements zu unterstüt- zen.
Die Vorgehensweise dieser Masterarbeit gestaltet sich wie folgt:
• Konzeption und Umsetzung einer Web-Applikation mit einem monolithischen Ansatz
• Konzeption und Umsetzung einer Web-Applikation mit einem Microservice-basierten Ansatz
• Untersuchung der Vor- und Nachteile beider Softwarearchitekturansätze
• Analyse beider Web-Applikationen durch Vergleich der Implementierung, Skalierbarkeit und Software-Performance
• Diskussion und Gegenüberstellung der Ergebnisse aus den Messungen
1.3. Verwandte Arbeiten
In diesem Kapitel werden verwandte Arbeiten beschrieben, die in der Vergangenheit ähnliche Vergleiche in Bezug auf Implementierung, Software-Performance und Skalierbarkeit ange- stellt haben. Weiters soll diese Sektion der vorliegen Arbeit eine Abgrenzung zu anderen Forschungsarbeiten zeigen. Nachstehend werden die gewählten Thesen beschrieben und der Inhalt der Forschungsarbeiten wird genau erläutert.
In der Arbeit [MM18] wird eine Software-Performance Analyse von zwei unterschiedlichen RESTful Webservices untersucht. Dabei wird ein Vergleich zwischen einer Microsoft .NET basierten und einer Java basierten Schnittstelle angestellt. Interessant ist, dass beide Webser- vices auf einer State of the Art Datenbank operieren, nämlich MySQL und die vom Her- steller hauseigenen objektrelationalen Datenmapper. Die Repräsentativität ergibt sich also daraus, dass die Technologie-Stapel nicht durchmischt wurden und beide Services wirklich nur herstellerspezifische Bibliotheken benützen, einzig die Datenbank ist eine State of the Art Datenbank, die von beiden Services benützt wird, aber weder von Oracle noch von Mi- crosoft stammt. Es handelt sich dabei um MySQL. In verschiedenen Testszenarieren werden REST-Aufrufe unterschiedlicher Methoden wie zum Beispiel GET oder PUT gestartet. Die Ergebnisse geben an, dass das in .NET implementierte Webservice bei PUT Aufrufen um über 10% schneller ist und bei GET Operationen sogar um über 80% mehr Einträge verar- beitet werden können, gegenüber dem Java basierten Service.
Die Untersuchungen des Papers [GT17] zeigen einige gewonnene Erkenntnisse, die aus der Analyse der Software-Modernisierung bei einem französischen Unternehmen entstanden sind.
Dabei war das primäre Ziel Monolithen in Microservices umzubauen und zu prüfen, welche Granularität die Beste ist, welches Deployment am passendsten ist und welche Art der Orche- strierung am effizientesten ist. Besonders interessant an dieser Arbei ist, dass ein deutlicher Performanceanstieg im Produktivbetrieb untersucht werden konnte. Vor der Umstellung war die Reaktionszeit der alten Services in 95 Prozent aller Fälle bei knapp 3 Sekunden. Durch die Änderung konnte die Zeit in 99 Prozent aller Fälle um zwei Drittel verkürzt werden.
Eine weitere themenverwandte Arbeit beschreibt eine Vergleichsimplementierung, ähnlich wie in der vorliegenden Masterarbeit. Die Fallstudie [VGC+15] vergleicht die Umsetzung einer Unternehmensanwendung auf Monolith- und auf Microservice Basis und unterzieht beide Applikationen einer Performanceanalyse. Die Webanwendungen werden in unterschiedlichen Architekturzustammenstellungen in die Cloud verteilt und einem Test mit Apache JMeter un- terzogen. Dieser Test liefert ein erstaunliches Ergebnis. Während die durchschnittliche Reak- tionszeit des Monolithen bei 2800 Millisekunden bei Service S1 liegt, liegt sie bei der Variante mit Microservices bei über 3200 Millisekunden. Die höheren Kosten beim Aufruf ergeben sich aber wahrscheinlich durch das verwendete API-Gateway des eingesetzten Cloud-Providers.
Der Aufruf des zweiten Services zeigt aber, dass die Implementierung mit den Microservices um knapp 700 Millisekunden schneller ist. Laut den Autor*innen sind aber Punkte, wie bei- spielsweise die Softwareauslieferung, die Skalierbarkeit und die API-Versionierung der Grund warum man auf Microservices setzen sollte.
Der Artikel [Lin17] von David S. Linthicum beschreibt im wesentlichen die Vor- und Nachteile von Cloud-Native Applikationen und zeigt auf, warum wir zukünftig mit einem Best-Practice Ansatz in diesem Bereich rechnen können. Es wird beschrieben, dass Faktoren wie Performan- ce, Effizienz, Kosten und Skalierbarkeit Punkte sind, die für die Migration oder Umsetzung in eine cloud-Native Architektur sprechen. Weiters wird erwähnt, dass über Portabilität nicht mehr disktutiert werden muss, denn solche Anwendungen haben bereits einen betriebssy- stemunabhängigen Architekturansatz. Die Nachteile dieses Ansatzes sind nicht technischer Natur, sondern beziehen sich auf den Aufwand und die Zeit, um eine Migration einer tra- ditionellen Applikationsarchitektur in eine Cloud-zentrierte Architektur zu überführen. Es geht dabei vor allem nicht nur darum, den Quellcode anzupassen, sondern es müssen auch beispielsweise die Plattform, die Bibliotheken und die Konfigurationen angepasst werden. Be- sonders interessant ist die Conclusio in der erwähnt wird, dass es trotzdem klüger ist einen nativen Cloud-Ansatz zu wählen und die Software-Gemeinde bald von Best Practices profi- tieren könnte.
1.4. Struktur der Arbeit
Die vorliegende Masterarbeit ist in vier Hauptkapitel unterteilt, die von der Einführung und Definition der Forschungsfrage bis hin zur Umsetzung des Hauptteils und der Beantwortung der aufgestellten These führt.
Der erste Teil der Arbeit beschäftigt sich mit der Einleitung in das Thema Cloud Compu- ting und Microservices und beinhaltet sowohl die Motivation des Autors als auch verwandte Arbeiten, die zur Orientierung bei der Erstellung der Masterarbeit dienten.
Das zweite Kapitel gibt dem*er Leser*in ein Basiswissen, um ein tieferes Verständnis beim Lesen des Hauptkapitels zu schaffen. Konkret werden in diesem Teil der Arbeit Themen be- handelt, die maßgebliche Bestandteile der Definition der Forschungsfrage beinhalten. Dabei handelt es sich um die Themendefinitionen von Cloud-Native und Monolithen und die allge- meine Defintion von Cloud Computing. Außerdem wird beschrieben, was Implementierung, Software-Performance und Skalierbarkeit von Applikationen bedeutet.
Im dritten Kapitel der vorliegenden Arbeit, werden die Bewertungskriterien für die Messung der Ergebnisse definiert. Im darauffolgenden vierten Kapitel, werden die zur Implementierung verwendeten Technologien beschrieben.
Kapitel Fünf hat den Titel Konzeption und Implementierung und stellt den Hauptteil der Arbeit dar. Darin werden zuerst die funktionalen und nicht-funktionalen Anforderungen an die Applikation, sowie die Priorisierungsmethode der Requirements beschrieben. Anschlie- ßend werden Bewertungskritieren zur Messung der Ergebnisse definiert und die verwendeten Technologien zur Umsetzung vorgestellt. Im letzten Teil dieses Kapitels werden die definierten Architekturen und deren Vor- und Nachteile zur Umsetzung vorgestellt und die Implemen- tierung textuell und grafisch beschrieben.
Das vorletzte Kapitel der Masterarbeit, beinhaltet die umfassende Dokumentation der aus- gewerteten Ergebnisse. Am Ende des Kapitels werden nochmals die End-Resultate zusam- mengefasst und gegenübergestellt.
Das letzte Kapitel der vorliegenden Arbeit trägt den Namen Conclusio und beinhaltet ne- ben der Ergebnisdiskussion, auch den Ausblick der Informationen über weitere potenzielle Forschungsgebiete gibt und beendet somit die Forschungsarbeit.
Analyse von Cloud-Technologien
In diesem Kapitel werden Informationen für Leser*innen aufbereitet, die als Grundlage für den weiteren Verlauf der vorliegenden Arbeit dienen. Einerseits werden die Hauptbegriffe der Arbeit unter Zuhilfenahme diverser Statistiken beleuchtet, um die Relevanz der Themen auf- zuzeigen und auf der anderen Seite werden auch die Bedeutungen der Bewertungsparameter Implementierung, Software Performance und Skalierbarkeit erläutert.
2.1. Cloud Computing
Auch wenn Cloud Technolgien schon mehr als zehn Jahre am Markt verfügbar sind, entwickeln sich die Technologie und die Infrastruktur immer noch rasend schnell. Cloud Computing öff- net neue Wege, um Applikationen und ganze Technologielandschaften zu restrukturieren.
Was versteht man eigentlich unter Cloud Computing?
Bis heute haben Unternehmen mit hohen Kosten ihrer Infrastruktur zu kämpfen, allen voran müssen Systeme immer performant laufen, sie müssen ausfallsicher gehostet werden mit Re- plikationsdiensten, es müssen zyklische Sicherungen erstellt werden und die Systeme müssen zuverlässig und ständig verfügbar sein. All diese Eigenschaften zusammengenommen haben ihren Preis. Genau hier setzt das Cloud Computing an, denn im Grunde genommen beschreibt es die Bereitstellung von computerbasierenden Ressourcen [CCM20]. Dabei werden Kapazitä- ten nicht von einem bestimmten Rechner an eine*n Benutzer*in zugewiesen [CCN20], sondern das Cloud Netzwerk besteht aus einem Rechnerverbund, beziehungsweise beschreibt es einen Cluster. Ein Cluster ist ein Zusammenschluß mehrerer Server zu einem großen System. Man nennt die einzelnen Serverelemente Nodes. Der Vorteil daraus ergibt sich einerseits durch Bündelung von Ressourcen und andererseits werden dadurch Eigenschaften wie Verfügbar- keit, Zuverlässigkeit und Skalierbarkeit gewonnen [Clu18]. Sollten einzelne Nodes ausfallen, kann der Rest der Infrastruktur die Ausfälle kompensieren.
Die Cloud wird in unterschiedliche Modelle eingeordnet. Die Wichtigsten sind Public Clouds, Private Clouds und die Hybrid Clouds. Unter Public Cloud versteht man externe Cloudanbie- ter, die für Unternehmen oder Privatpersonen unterschiedliche Servicemodelle anbieten. Die
Kosten werden je nach Nutzung oder gekauftem Servicemodell berechnet. Der Vorteil hier ist, dass schnell Infrastruktur bereitgestellt werden kann und dass beispielsweise keine Kosten und Aufwände für Wartungsarbeiten anfallen. Dieses Modell macht aber nur dann Sinn, wenn die Anwendung keine sicherheitskritischen Daten oder Prozesse verwaltet. Beispielsweise im Bankenbereich wird auf Private Clouds gesetzt, da es sich um besonders schützenswerte Da- ten und Infrastrukturen handelt. Die Technolgie wird dabei auf eigener Hardware gehostet und somit ein abgeschottetes Cloud-Netzwerk aufgebaut. Der Vorteil ergibt sich aus Sicht der Security, allerdings ist dieses Modell sehr viel teurer als eine öffentliche Cloud, weil War- tungskosten anfallen und die Planung bezüglich Performance und Skalierbarkeit muss selbst übernommen werden. Die hybride Cloud vereint öffentliche und private Cloud Netzwerke und somit auch die Vorteile beider. Der Wartungsaufwand fällt aber auch in diesem Szenario nicht weg, da trotzdem eine Private Cloud betrieben werden muss, um die schützenswerten Daten zu verwalten [Clo20].
Mit der Markteinführung in den frühen Zweitausenderjahren, wurde auch der Begriff der ser- viceorientierten Architektur geboren. Die SOA beschreibt eine Form der Softwarearchitektur, die dazu dient das Applikationsnetzwerk in Webservices aufzuteilen und damit Geschäftspro- zesse miteinzubeziehen. Das bedeutet, dass das Service einen aussagekräftigen Namen für die auszuführende Methode beinhaltet, der den darunter liegenden Geschäftsprozess beschreibt.
Serviceorientierte Architekturen haben eine Reihe an Vorteilen, die in Kombination mit Cloud Computing verwendet werden können. Zum Beispiel kann sie eingesetzt werden, um verteilte Systeme über ein Netzwerk umzusetzen. Außerdem ist es möglich, bestehende Systeme zu integrieren und über neu definierte Schnittstellen, anderen Anwendungen zur Verfügung zu stellen. Aber der größte Vorteil von SOA ist die Sprachen- und Plattformunabhängigkeit, denn verschiedene Services können miteinander kommunizieren, obwohl sie mit unterschied- lichen Frameworks und Programmiersprachen implementiert wurden [SOA20]. Die Elemente einer serviceorientierten Architektur werden nachstehend grafisch erläutert:
Abbildung 2.1.: Elemente der serviceorientierten Architektur [SOA20]
In Abbildung 2.1 kann man gut erkennen, dass das eigentliche Service durch drei wesentliche Faktoren beschrieben wird. Der Contract definiert, wie der Konsument und der Provider des Services miteinander kommunizieren. Damit wird der Standard beschrieben, wie das Service aufgerufen werden kann, heutzutage meist über SOAP oder REST. Die Implementierung ist gekapselt, hinter der Servicebeschreibung verborgen und setzt sich aus der eigentlichen Businesslogik und den Datenzugriffen zusammen. Sie beschreibt den Quellcode der dazu be- nützt wird, einen Serviceaufruf durchzuführen. Das Interface stellt den Zugriffspunkt für das Service dar, über den es aufgerufen werden kann. Ein weiteres zentrales Element ist das Ap- plication Frontend, welches die Zugriffsoberfläche für Benutzer*innen darstellt. Das Service Repository beinhaltet einerseits den kompletten Sourcecode des Services und andererseits ei- ne Deployment Pipeline, die zur Softwareauslieferung dient. Der Services Bus ist im Kontext einer serviceorientierten Architektur ein sogenannter Messagebroker, der die Nachrichten an die angebundenen Services verteilt. SOA besitzt unterschiedliche Servicemodelle die immer granularer geworden sind.
Abbildung 2.2.: Granularität der serviceorientierten Architektur
In Abbildung 2.2 ist gut erkennbar, dass die Granularität von Infrastructure as a Service ausgehend, immer feiner wird. Am Ende der Kette findet sich das Modell Function as a Ser- vice, welches vergleichsweise noch sehr neuartig und modern ist. Die einzelnen Servicemodelle werden nachstehend beschrieben.
2.1.1. Infrastructure as a Service
Den Anfang macht Infrastructure as a Service oder auch kurz IaaS genannt. Historisch ge- sehen ist dieses Modell auch das Erste das von großen Cloud Anbietern wie beispielsweise Amazon Web Services oder Google Cloud Plattform angeboten wurde. IaaS ist auf hierarchi- scher Ebene ganz oben angesiedelt und hat die gröbste Form der Granularität. Bei diesem Modell wird dem*er Kund*in Infrastruktur in Form von Server-, Netzwerk- oder Speicherin- frastruktur zur Verfügung gestellt. Diese Basisinfrastruktur kann dann dazu benützt werden,
gewünschte Softwarekomponenten zu installieren. Dafür werden keine Vorkonfigurationen ge- leistet. Einzig die Virtualisierungstechnologie wird zur Verfügung gestellt [BJJ10, vgl. Seite 3].
2.1.2. Platform as a Service
Das Modell PaaS geht um einen Schritt weiter und stellt dem*er Benutzer*in nicht nur die Basisinfrastruktur zur Verfügung, sondern auch ein vorkonfiguriertes Betriebssystem und sogar eine Entwicklungs- und Datenbankmanagement Software, die dazu genutzt werden kann, um Applikationen zu verwalten. Diese müssen aber zusätzlich deployed werden [BJJ10, vgl. Seite 2]. Typische Beispiele dafür sind Plattformen wie Heroku, Cloud Foundry oder Digital Ocean und im privaten Bereich beispielsweise OpenShift von RedHat.
2.1.3. Software as a Service
SaaS geht noch einen Schritt weiter in der Granularitätskette und steuert Apps von Drittan- bietern bei. SaaS-Anbieter hosten Applikationen als Service für Kund*innen. Im Normalfall werden solche Softwarelösungen einmal in einem Rechenzentrum installiert und für mehrere Benutzer*innen, frei oder gegen Bezahlung, zugänglich gemacht. Bei diesem Modell muss kein Quellcode selbst geschrieben werden, sondern die gewünschte App kann per Klick auf Cloud Container deployed werden. Es gibt auch Szenarieren, wo Software as a Service Lösungen von Anbieter A, auf der IaaS oder PaaS Infrastruktur eines Anbieters B angeboten wird [BJJ10, vgl. Seite 2]. Meist erfolgt das über eine Art „Appstore“.
2.1.4. Function as a Service
Function as a Service ist neuartig und repräsentiert derzeit die State of the Art Umsetzung von Softwarelösungen. Bei FaaS handelt es sich um Quellcode, der als Service in einer Cloud Umgebung gehostet wird. Der Container ist dabei zustandslos. Das Programm läuft technisch immer noch auf einem physischen Server, aber Benutzer*innen sind dabei nicht für die War- tung verantwortlich. Es handelt sich bei diesem Servicemodell um eine Kombination von der Wartung des eigenen Programmcodes und der zur Verfügung gestellten Infrastruktur [SS18, vgl. Seite 1]. Microservices werden unter Verwendung des FaaS-Modells erstellt.
2.2. Cloud Native
In diesem Subkapitel werden die Charakteristika rund um das Thema „Cloud Native“ vor- gestellt, insbesondere wird der Zusammenhang mit Microservices und Cloud-Technologien erläutert und anhand umfassender Literatur-Recherche gegenübergestellt. Außerdem werden die Vor- und Nachteile von Cloud Native Applikationen beleuchtet.
Native Cloud Anwendungen werden häufig mit Microservices in Verbindung gebracht. Das ist kein Zufall, denn im Kern sind sie sogenannte verteilte Systeme. In der Theorie handelt es sich dabei um einzelne Computer, die über ein gemeinsames Netzwerk miteinander verbunden sind und dabei als ein Gesamtsystem erscheinen [BS19, vgl. Seite 1-3]. Ein Microservice ist in diesem Szenario also ein Teil von einem verteilten System. Es bedeutet aber nicht, dass es sich bei Elementen eines verteilten Systems zwingend um Microservices handelt. Die Cloud Native Computing Foundation hat die sogenannte „Cloud Native Defition“ herausgegeben und dabei erklärt, dass diese Art von Technologie ermöglicht, skalierbare und dynamische Applikations- landschaften zu implementieren. Außerdem schaffen die zugrundeliegenden Infrastrukturen, wie schon in Punkt 2.1 Cloud Computing beschrieben, Möglichkeiten um entkoppelte und robuste Systeme zu entwickeln. Der wichtigste Punkt, um native Cloud-Implementierungen von verteilten Systemen zu unterscheiden, ist das sogenannte Ökosystem. Es definiert unter- schiedliche Paradigmen, um die Gesamtheit einer solchen Awendung zu definieren [CNC19].
Abbildung 2.3.: Besandteile und Paradigmen einer Cloud Native Applikation
Wie Eingangs erwähnt, wird der Fokus in diesem Unterkapitel auch auf die Charakteristika einer Cloud native Applikation gelegt. Darunter fallen Microservices, Continous Integration
& Delivery, Container und DevOps, wie man in Abbildung 2.3 erkennen kann. Sie werden in den nachfolgenden Unterpunkten beschrieben.
2.2.1. Microservices
Bei einem Microservice handelt es sich um ein Architekturmuster, dass in zustandslosen Um- gebungen seine Anwendung findet. Die Zustandslosigkeit entsteht daraus, dass der Applikati- onsquellcode, unabhängig von der darunterliegenden Hardware der Infrastruktur ausgeführt werden kann. Das impliziert auch, dass die Portabilität sehr hoch ist, da die Infrastruktur eines Cloudanbieters eine untergeordnete Rolle spielt. Microservices werden für den Betrieb in sogenannten Containern oder auch oft Cloudcontainer genannt, umgesetzt. Die Kommuni- kation dieser verteilten Services, erfolgt über ein gemeinsames Netzwerk und standardisierter Protokolle, wie zum Beispiel „HTTP“. Durch die Standardisierung, profitieren Microservices auch von der Unabhängigkeit der Programmiersprachen [RK19, vgl. Seite 81-83], [BS19, vgl.
Seite 22-23]. Ein in Java implementiertes Service, kann problemlos mit einem Service kom- munizieren das beispielsweise mit .NET Core implementiert wurde. Durch die sehr leicht erweiterbaren Ressourcen eines Clusters in der Cloud, skalieren Anwendungen viel besser.
Außerdem kann die Performance dadurch gesteigert werden und auch die Verfügbarkeit von Applikationen verbessert sich, da bei Cloudprovidern Replikation eingsetzt wird.
Selbstverständlich haben Microservices auch Nachteile, denn sie sind nicht für jeden An- wendungsfall geeignet. Ist die nötige Infrastruktur nicht vorhanden, um Software as a Service oder Function as a Service Lösungen umzusetzen, können Implementierungen dieser Art einen deutlichen Mehraufwand verursachen. In Szenarien, in denen sich Benutzer*innen oder Un- ternehmen selbst um Eigenschaften, wie Verfügbarkeit, Replikation, Performance oder Ska- lierbarkeit kümmern müssen, würde die Anzahl der zu wartenden Applikationen durch die feine Granularität von Microservices steigen. Weiters wird die Migration bestehender An- wendungen, die Microservices nutzen komplexer, da es schlagartig eine Vielzahl von kleinen Services gibt, die auch alle getestet werden müssen.
2.2.2. Container
Bei einem sogenannten Container handelt es sich um eine Technologie, die es ermöglicht Ap- plikationen zu hosten. Genauer gesagt, ermöglichen Container das Zuweisen von Computing- Ressourcen zu einer Instanz. Dabei können die Ressourcen dynamisch über eine Benutzero- berfläche oder entsprechende Änderung in der Konfigurationsdatei angepasst werden. Weiters handelt es sich bei Containern um eine Art von Virtualisierung. Während gängige Virtua- lisierungstechnologien wie Microsofts Hyper-V oder vSphere von VMware auf den Einsatz von Betriebssystemen setzen, kommen Cloud Container ganz ohne Betriebssystem aus und bedienen sich nur an den Kernfunktionalitäten des operierenden Systems [RK19, vgl. Seite 74-75]. Das bedeutet, dass in einer Containerinstanz die nötigen Bibliotheken und Image- Funktionalitäten zur Verfügung stehen. Dadurch wird der Vorteil geschaffen, dass ein Groß- teil der Clusterressourcen geschont wird, da nicht noch zusätzlich leerlaufende Dienste und sogar die Oberfläche eines Betriebssystems ausgeführt werden müssen. In einem Container, insbesondere bei Microservices werden beim Programmaufruf ein oder mehrere Prozesse syn- chron bzw. asynchron ausgeführt, bis der Aufruf terminiert. Die State of the Art Technologie in diesem Bereich ist Docker, die die Eigenschaft eines Containers zur Verfügung stellt. Ge- hostet werden Container auf sogenannten „PaaS“ Plattformen. In nachstehender Grafik wird nochmals der Unterschied zwischen virtuellen Maschinen und Containern visualisiert und an- schließend erklärt.
Abbildung 2.4.: Unterschied zwischen virtuellen Maschinen und Containern [Vir17]
Wie die Abbildung 2.4 veranschaulicht, unterscheiden sich klassische virtuelle Maschinen sehr stark von Cloud Container Technologien. Während bei den Containern direkt nach der Ser- verschicht erst das eigentliche Betriebssystem des physischen Servers folgt, stellt bei einer VM der sogenannte Hypervisor eine Art „Vermittlungsschicht“ zwischen einem Gastbetriebs- system und der Infrastruktur dar. Der Einsatz einer Container-Technologie ermöglicht es, unterschiedlichste Container-Images mit stark reduzierten Ressourcen zu betreiben, während bei virtuellen Maschinen über der Hypervisor-Schicht vollwertige Betriebssysteme installiert werden müssen, die verstärkt vertikale Ressourcen verbrauchen.
Da nun ein Verständnis für Containertechnologien geschaffen wurde, folgt nachstehend der Rolloutprozess von Containerservices. Weiters wird auf den Unterschied zwischen Continuous Integration und Continuous Delivery eingegangen.
2.2.3. Continuous Integration & Continuous Delivery
Der technologische Wandel ist allgegenwärtig und zwingt Unternehmen der ganzen Welt, Vorkehrungen zu treffen um Systeme hochverfügbar zu machen. Der Einsatz von Cloud Technologien bringt auch in diesem Bereich Verbesserungen. Während früher Applikationen auf Webservern ausgerollt werden mussten oder ganze Serversysteme neu gestartet werden mussten und Deploymentszenarien mit Einsatzdrehbüchern eingesetzt werden mussten, ver- wenden Cloud Applikationen andere Rollout Szenarien. Die unterschiedlichen Prozesse der sogenannten Deployment Pipline, werden nachstehend beschrieben.
Continous Integration
Als Continuous Integration bezeichnet man den Prozess der fortlaufenden Zusammenführung von Software-Quellcode in einem sogenannten „Branch“. Branches werden in einem gemeinsa- men Versionskontrollsystem verwaltet, welches eher unter dem Namen „Repository“ bekannt ist. Ein Branch ist eine Verzweigung von Programmcode, dabei wird der aktuelle Code dupli- ziert, sodass in einem Projekt mehrere Versionen des Programmes gleichzeitig bearbeitet und
unabhängig von einander deployed werden können. Das hat den Vorteil, dass zu festgelegten Zeitpunkten, potenziell releasefähige, Programme in einem Zielbranch vorhanden sind. Au- ßerdem ist es wichtig Änderungen so schnell wie möglich mit dem Team zu teilen. [Vir15, vgl.
Seite 2]. Weiters ist Continuous Integration ein Teil von Continuous Delivery und Deployment.
Continous Delivery & Deployment
Continuous Delivery beschreibt einen Prozess der Softwareauslieferung. Es handelt sich dabei um eine Vorgehensweise, die von der Code-Zusammenführung (CI) bis hin zu den automati- sierten Kundentests reicht [Vir15, vgl. Seite 2]. Die nachfolgende Grafik veranschaulicht den Prozess von Continuous Delivery.
Abbildung 2.5.: Veranschaulichung des Continuous Delivery Prozesses [Con17]
In Abbildung 2.5 ist gut erkennbar, dass das Software-Rollout in die Produktionsumgebung nicht automatisch ausgeführt wird. Es wird zwar der ganze Quellcode automatisiert zusam- mengeführt, danach werden alle Unit-Tests und automatisierten Kundentests ausgeführt, aber der letzte Schritt passiert bei dem Delivery-Modell manuell. Betrachtet man hingegen das Deployment-Modell sieht das anders aus.
Abbildung 2.6.: Veranschaulichung des Continuous Deployment Prozesses [Con17]
Wie in der Grafik 2.6 erkennbar ist, werden Softwareauslieferungen aus Sicht des Deploy- mentprozesses automatisch ausgeführt. Das heißt, jede Quellcodezusammenführung im Stan- dardbranch löst ein ganzheitliches Deployment der Software bei Kund*innen aus.
Continuous Delivery und Deployment verhindern Rolloutszenarien, in denen ganze Systeme für Stunden offline genommen werden müssen. Es besteht aber auch die Gefahr, dass durch
die häufigen Commits in das Repository, fehlerhafter Code eingecheckt wird und somit zu Produktionsproblemen führen kann. Allgemein gesehen sind beide Paradigmen aber eine große Errungenschaft.
2.2.4. DevOps
Beim Begriff „DevOps“ handelt es sich um um ein Konzept zur Entwicklung und gleichzeitiger Wartung von Softwaresystemen im Cloud Computing Bereich. In klassischen Vorgehensweisen wird Software von Entwicklern dem Testteam übergeben und anschließend zusammengeführt oder ausgerollt. Das bedeutet aber auch, dass das Team aus einer Menge an Einzelfaktoren besteht und die Kommunikation durch die Informationsweitergabe an Qualität verliert. Bei DevOps haben sich Teams komplett neu aufgestellt, sogenannte Produktteams wurden ge- boren. Bei Produktteams sind Softwareentwickler in der Verantwortung die Programme zu entwickeln, Tests durchzuführen und die Wartung im Produktivbetrieb zu übernehmen. Ziel von DevOps ist es die Zusammenarbeit der unterschiedlichen Rollen in Softwareentwicklungs- projekten mehr Effizienz zu erzielen [AR19, vgl. Seite 2].
CI und DevOps sind Konzepte, die auch in starkem Zusammenhang mit agilen Vorgehens- weisen in der Softwareentwicklung stehen.
2.3. Monolith
Webarchitekturen haben sich in den letzten Jahren stark weiterentwickelt und geändert. Im Subkapitel 2.2 wurden Microservices und ihre Eigenschaften vorgestellt, nachfolgend wird nun das historische Gegenstück, der Monolith vorgestellt.
Bei monolithischen Ansätzen spricht man von einem Software-Architektur Stil, der alle Funk- tionen der Applikation in eine komplette Anwendung kapselt. Im Gegensatz zu Microservices gibt es nicht mehrere Services, die verbunden zu einer Applikation verschmelzen, sondern ein Monolith beinhaltet den kompletten Programmcode der Softwarelösung. Anfangs über- wiegen die Vorteile dieses Architekturstils, da Quellcodeanpassungen nur in einem Projekt durchgeführt werden müssen. Das hat aber auch zur Folge, dass das Projekt in kürzester Zeit stark anwächst und das Software-Projekt immer größer wird. Genau hier beginnen dann die Probleme, denn die Komplexität steigt stark an und Deployments dauern aufgrund der Größe des Projekts viel länger. Auch Continuous Delivery und Deployment im Sinne der Fehlerbe- hebung dauern länger, da immer das komplette Softwareprodukt deployed werden muss und nicht nur einzelne Microservices, die durch das Backend gekapselt werden [CLL17, vgl. Seite 1-2].
Abbildung 2.7.: Visualisierung des Unterschieds zwischen Monolith und Microservice [Mon18]
In Abbildung 2.7 zeigt deutlich den Unterschied zwischen Software-Monolithen und Micro- services. Während der Monolith das User-Interface, die vollständige Programmlogik und die Datenbank auf einer Maschine kapselt, ist die Microservices-Architektur aufgeteilt. Die Mög- lichkeiten des UI, setzen sich aus den Funktionalitäten der einzelnen Microservices zusammen.
Jedes Service beherrscht dabei einen exklusiven Datenbankzugriff oder mehrere Microservices können sich Datenbankzugriffe untereinander als Ressource teilen. Es besteht also keine so enge Kapselung.
Zusammenfassend bieten Monolithen gerade am Anfang eines Softwareprojekts große Vortei- le, da durch die nur einmalige Erstellung der Basisinfrastruktur Zeit eingespart werden kann.
Somit kann die Entwicklung schneller vorangetrieben werden. Durch die steigende Komplexi- tät wird es aber zunehmend schwieriger eine monolithische Architektur zu warten und auch Faktoren, wie Wartbarkeit und Skalierbarkeit verlieren ihre Bedeutung.
2.4. Twelve Factor App
Grundsätzlich beziehen sich die Paradigmen der Twelve Factor Methode nicht speziell auf die Anwendung bei Cloud-Native Applikationen. Es gibt aber gute Gründe, sie dafür einzu- setzen, da Twelve Factor [Twe20] bei SaaS seine Anwendung findet. In den nachfolgenden Punkten werden die zwölf Methoden anhand des Bezuges auf native Cloud-Lösungen be- schrieben [BS19, vgl. Seite 4-6].
1. Repository
Der Quellcode der Applikationen soll ein gemeinsames Versionsverwaltungssystem haben.
Dadurch ist es möglich, Programmcode zentral aufzubewahren und ihn in unterschiedliche Cloud-Umgebungen zu deployen. Continuous Integration, Delivery und Deployment kommen
hier zur Anwendung.
2. Abhängigkeiten
In Bezug auf diese Arbeit, gibt es in .NET Core sogenannte „Nuget Packages“, die als Abhän- gigkeiten installiert werden können. Diese sollen aber nicht zentral in der Cloud-Umgebung verwaltet werden, sondern jede Applikation soll seine Abhängigkeiten deklarieren.
3. Konfiguration
Jede Webapplikation hat Konfigurationsdateien für unterschiedliche Betriebsumgebungen.
Diese Konfigurationsdateien sollen sauber vom Quellcode getrennt sein. Das hat den Vorteil, dass der Code aufgrund eines Deployments nicht geändert werden muss. Es muss nur die für die Umgebung entsprechende Konfiguration angegeben werden.
4. Unterstützende Dienste
Dienste die von den einzelnen Microservices während dem laufenden Betrieb konsumiert wer- den, sollen als Ressource wahrgenommen und angebunden werden. Dazu zählen normalerweise Datenspeicher oder Cachedienste. Ziel ist es eine möglichst lose Kopplung der einzelnen Ele- mente zu erzielen.
5. Build, Release, Run
Dieser Punkt gibt an, dass die Build- und Ausführungsumgebungen strikt getrennt werden sollen. Empfohlen wird CI/CD einzusetzen, damit Code-Versionierung, Build-Historie und automatische Deployments ausgeführt werden können. Weiters soll die Laufzeit-Phase einer Applikation im Produktionsbetrieb so wenig wie möglich beeinflusst werden.
6. Prozesse
Um eine möglichst lose Kopplung zu erzeugen, sollen Daten außerhalb von Prozessen gespei- chert oder gecached werden.
7. Port Bindung
Jedes Microservice verwaltet seine eigenen Datenbanzugriffe, diese Daten können wiederrum nur über den API-Aufruf des Services abgefragt werden.
8. Nebenläufigkeit
Entwickelte Webapplikationen sollen mehrere, unterschiedliche Prozesse starten, die parallel und asynchron laufen können, um Skalierbarkeit zu erzeugen.
9. Disposabilität
Prozesse die bei einem Programmaufruf benutzt werden, sollen nach dem Return-Befehl eines HTTP-Requests wieder verworfen werden. Bei asynchronen Aufrufen, sollen diese Ressourcen
erst nach Abarbeitung weggeworfen werden. In den meisten Frameworks werden Disposabili- täten schon von der Systemumgebung gehandhabt, ein manuelles Eingreifen könnte Probleme verursachen.
10. Dev-Prod Vergleichbarkeit
Die in Punkt 5 angesprochenen Umgebungen, sollen so ähnlich wie möglich gehalten werden, um Vergleichbarkeitsszenarien zu schaffen und das Debugging in der Entwicklungsumgebung realisitischer zu gestalten.
11. Logs
Logeinträge sind einer der wichtigsten Faktoren einer Cloud Applikation, denn sie geben Auskunft darüber in welchem Zustand sich ein Service in einem Container befindet. Man sollte nicht versuchen, Logeinträge zu verwalten. Stattdessen sollen die Logeinträge, jedes Ereignisses aller Applikation in die Console geschrieben werden, um eine Nachvollziehbarkeit herzustellen.
12. Admin-Prozesse
Administrative Prozesse wie beispieslweise eine Migration, sollen nur einmalig laufen. Um den administrativen Quellcode abzuschirmen, sollten sie als kurzlebige Prozesse ausgeführt werden.
2.5. Bewertungsparameter
In den vorherigen Subkapiteln wurden die Themen vorgestellt, die in dieser Masterarbeit behandelt werden. Mit den nachstehenden Punkten, „Implementierung“, „Performance“ und
„Skalierbarkeit“, werden die Parameter und ihre Bedeutung beschrieben, die zur Messung der Ergebnisse dieser Masterabeit dienen. Den Anfang dazu macht die Software-Performance.
2.5.1. Software-Performance
Die Leistung einer Software-Applikation ist ein Faktor, der Einfluss auf den Erfolg einer ge- planten Software-Architektur nimmt. Die Performance von Softwarelösungen kann sowohl von der ausführenden Software als auch von der darunterliegenden Hardware beeinflusst wer- den. Unterschieden werden im Bereich der Software Performance zwei Arten von Messungen.
Dazu zählen die statischen und dynamischen Messungen.
Statische Messungen
Bei den statischen Messungen, handelt es sich um Untersuchungen an der verwendeten Infra- struktur. Die Größe von Applikationen und Datenbanken sind für diese Art von Parameter ausschlagegebend, wie die Software-Performance eigneordnet wird. Natürlich sind das keine Messergebnisse zur Laufzeit und es können anhand dieser Auswertungen nur Rückschlüsse gezogen werden, ob Applikationen, Schwächen aufgrund von dieser Messungen aufzeigen.
Dynamische Messungen
Die dynamischen Messungen liefern Auswertungen zur Laufzeit, wie der Name schon an- deutet. Um Ergebnisse zu erzielen, muss die Applikation im laufenden Betrieb getestet und überwacht werden. Anhand dessen kann nachvollzogen werden, wie hoch die CPU Auslastung ist, oder wie viel RAM Speicher zu einem definierten Zeitpunkt verbraucht wird. Außerdem kann auch die Dauer der Zugriffe auf Speichereinheiten überprüft werden.
Grundsätzlich gibt es drei Klassen in die Software Performance eingeordnet werden kann.
Die erste Klasse beschreibt die Validität von durchgeführten Operationen und die daraus re- sultierenden Ergebnisse bzw. gehört auch die Benutzerfreundlichkeit der Applikation in diese Kategorie. Die zweite Klasse behandelt Robustheit und Konsistenz der Operationen einer Applikation. In der dritten Kategorie werden Performance KPIs behandelt, die untersuchen wie schnell Systemaktionen durchgeführt werden können und vorallem wie viele Operationen abgearbeitet werden können [Chm09, vgl. Seite 5-6].
2.5.2. Skalierbarkeit
Die Systemskalierbarkeit ist auch Teil des Leistungspotenzials einer Applikation, sie wird aber gesondert behandelt, da sie einen wichtigen Parameter zur Messung in der vorliegenden Masterarbeit darstellt.
Heutzutage müssen Systeme unter großer Last operieren können, ohne das Zeitverzögerungen aufgeworfen werden. Die Skalierbarkeit ist der Indikator für solch ein Verhalten, sie beschreibt die Anpassungsfähigkeit eines Systems aufgrund der zugeführten Anzahl von Requests zu ei- nem gewissen Zeitpunkt. Abhängig von zugeführten Hardware-Ressourcen und Last, operiert ein System besser oder schlechter. Man sagt dazu auch, dass ein System „skaliert“ [BCT17, vgl. Seite 1]. Sie wird im Wesentlichen in zwei unterschiedliche Kategorien unterteilt, die vertikale und die horizontale Skalierbarkeit. Die Typen werden nachfolgend beschrieben.
Vertikale Skalierbarkeit
Um das Systemverhalten beinflussen zu können, müssen Systeme in gewisser Art und Weise erweitert werden. Bei der vertikalen Art, wird die bestehende Ressourcenverteilung aufge- wertet. Das bedeutet, dass der bestehenden Konfiguration mehrere CPU-Kerne, mehr Ar-
beitsspeicher oder beispielsweise mehr Speicher zugeordnet werden. Das hat den Vorteil, dass schnell mehr Ressourcen geschaffen werden können. Diese Erweiterungen können aber nicht dauerhaft fortgeführt werden, denn irgendwann sind diese Mittel ausgeschöpft und die phy- sischen Systeme können nicht mehr erweitert werden, was bedeutet, dass auch den virtuellen Systemen keine Ressourcen mehr zugeordnet werden können. Allgemein bekannt ist vertikale Skalierung unter „Scale Up“. Um dieses Problem der Limitierung in den Griff zu bekommen, wurde auf die sogenannte „horizontale“ Skalierbarkeit zurückgegriffen.
Horizontale Skalierbarkeit
Die horizontale Skalierbarkeit, geht den entgegengesetzten Weg zur vertikalen Skalierung, wie der Name schon sagt. Anstatt Systeme durch Erweiterung immer mehr auszuschöpfen, bis sie nicht mehr erweitert werden können, wird die vorhandene Infrastruktur durch das Verbinden neuer Hardware- oder Softwarekomponenten erweitert. Das hat den Vorteil, dass Ressourcen beispielsweise durch Loadbalancer auf die Komponenten aufgeteilt werden können, weil sie als eine Einheit im Verbund gesehen werden. Dadurch befinden sich die unterschiedlichen Services nicht ständig unter hoher Belastung, sondern die Last wird aufgeteilt, was die Ant- wortzeiten von Requests deutlich erhöht. Der Nachteil ist, dass so ein Systemeingriff nicht so schnell möglich ist wie bei vertikaler Skalierbarkeit und das erhöhte Kosten für Nutzung von mehr Hardware und Lizenzen entstehen. Die horizontale Skalierbarkeit ist allgemein unter
„Scale Out“ bekannt.
Abbildung 2.8.: Vertikale vs horizontale Skalierbarkeit [Ver15]
In Abbildung 2.8 ist der Unterschied zwischen Skalierungsarten gut erkennbar. Während die Ressource der vertikalen Skalierung an der bestehenden Infrastruktur anwachsen, werden die Systemeinheiten bei der horizontalen Skalierung durch neue Systemressourcen im Verbund erweitert.
2.5.3. Implementierung
Beim Begriff der Implementierung handelt es sich um das Zusammenfügen von Quellcode zu einem Gesamtsystem beziehungsweise die fortführende Zusammenfügung von Codezeilen in einem Serviceverbund, im Kontext des Cloud Computings. Geplant werden solche Vorhaben auf einer abstrakten Ebene, die zu einem späteren Zeitpunkt ein reales Weltbild darstellen.
Sie bezieht sich aber nicht nur auf den Teil, bei dem Software tatsächlich implementiert wird, sondern auch den Integrations- und Software-Testzyklus. [Kak06, vgl. Seite 1-2] Bei der Software-Integration werden unterschiedliche Software-Komponenten zusammengefügt. Das Testen einer Implementierung verifiziert die Richtigkeit und Funktionalität von Software.
Das Ziel dieses Kapitels war es dem*er Leser*innen Grundlagen zum weiteren Verlauf der vorliegenden Arbeit zu vermitteln. Im nachfolgenden Kapitel werden die verwendeten Tech- nologien beschrieben, die einen Konnex zwischen sich und den Basisinformationen schaffen sollen.
In diesem Kapitel werden die Kriterien zur Ergebnismessung festgelegt. Zur Erstellung wer- den die Parameter Implementierung, Performance und Skalierbarkeit herangezogen. Es wer- den verschiedene Untersuchungen durchgeführt, die zur Evaluierung der gemessenen Unter- schiede, zwischen dem Monolithen und den Microservices beitragen sollen. Jeder Parameter besitzt unterschiedliche „KPIs“, die die Eigenschaften der Messung des jeweiligen Kriterium beinhalten. Nachfolgend werden die Kenngrößen detailliert angeführt und beschrieben.
3.1. Implementierung
Zur Untersuchung der Implementierung werden Code-Fragmente der beiden Implementierun- gen in Vergleich gestellt, um die Koppelung der unterschiedlichen Komponenten zu veran- schaulichen.
3.2. Software Performance
Um die Software-Performance messen zu können, wird pro Webservice ein Load-Test und drei Skalierbarkeitstests durchgeführt. Die dafür definierten KPIs werden nachfolgend beschrie- ben:
3.2.1. Load Test
Ein Load-Test setzt die Applikation einer hohen Belastung aus, indem eine sehr große Anzahl an Requests gesendet wird. Es wird damit untersucht bei wie vielen Transaktionen, die Ap- plikation anfängt Performance einzubüßen oder sie sogar abstürzt. Der Load-Test wird mit einer Anzahl von zwanzig Threads und jeweils 250 Requests durchgeführt.
Kenngröße Messeinheit
Transaktionen Anzahl / Transaktionen
Tabelle 3.1.: Bewertungskriterien für den „Load-Test“
3.2.2. Skalierbarkeitstest
Für den Skalierbarkeitstest werden pro Implementierung drei Aufrufe mit unterschiedlicher Thread-Anzahl durchgeführt, um Unterschiede messen zu können. Die Requests werden da- her mit einem, mit fünf und mit zehn Threads und jeweils 250 Requests durchgeführt. Die KPIs die zur Untersuchung der Skalierbarkeit herangezogen werden, werden nachfolgend auf- gelistet:
Kenngröße Messeinheit
Antwortzeit Millisekunden [ms]
Durchsatz Transaktionen/s
Netzwerkauslastung KBytes pro Sekunde [KB/s]
Fehler Anzahl der Fehler
Tabelle 3.2.: Bewertungskriterien für den „Skalierbarkeitstest“
Die in diesem Kapitel definierten Key Performance Indicators dienen zur Auswertung der Ergebnisse der deklarierten Forschungsfrage. Anhand der Parameter wird schlussendlich ein Fazit gezogen, ob der monolithische oder microservice-basierte Architekturstil, auf Basis von .NET Core 3.1 in einer Cloud-Umgebung besser geeignet ist.
Im anschließenden Kapitel werden die zur Implementierung verwendeten Technologien be- schrieben.
Nachdem zuvor die Grundlagen zum weiteren Verständnis der vorliegenden Arbeit geschaf- fen wurden, stellt das Kapitel Vier die verwendeten Technologien vor. Dieser Teil der Arbeit beinhaltet Beschreibungen zu Frameworks, Plattformen, Datenbanken, Tools und Paradig- men. Neben historischen Aspekten, wird auf die Funktionsweise und die Vor- und Nachteile der beschriebenen Elemente eingegangen. Sie werden in den nachfolgenden Subkapiteln aus- führlich erläutert.
4.1. .NET & .NET Core
Seit fast zwanzig Jahren gibt es den Begriff .NET bereits. Der Begriff .NET (Dotnet) ist ein Sammelbegriff der mehrere unterschiedliche Technologieelemente umfasst. Darunter fal- len unter anderem Frameworks, Programmiersprachen oder beispielsweise Anwendungen. Im Wesentlichen ist es als Entwicklungsplattform bekannt, über die ursprünglich plattformüber- greifende Software entwickelt werden sollte. Microsoft hat es in Folge aber im proprietären Umfeld weiterentwickelt und nur Windows als Plattform unterstützt. Das hat den Vorteil, dass es einerseits einen offiziellen Support für die Entwicklungsplattform gibt aber gleich- zeitig den Nachteil, dass Entwickler*innen durch die Single-Plattform Entwicklung sehr be- schränkt sind. Es ist zwar möglich, reine .NET Applikationen in einem Docker Container auszuführen, allerdings muss immer sichergestellt sein, dass die darunterliegende Betriebs- systeminfrastruktur Windows-basierend ist. Seit Version 4.5.2 ist es integrierter Bestand- teil des Betriebssystems Windows. Die Plattformbeschränkung und die steigende Beliebtheit von Cloud-Infrastrukturen, die hautpsächlich auf Unix-Systemen basieren, haben den Begriff
„Cross-Plattform“ immer populärer werden lassen. Unter Cross-Plattform-Applikationen ver- steht man Anwendungen, die die darunterliegende Infrastruktur nicht wahrnehmen und somit auf unterschiedlichen Betriebssystemen ausgeführt werden können. Dadurch wurde .NET Co- re geboren. Diese Version einer Entwicklungsplattform macht es möglich, Web-, Smartphone- oder Desktop-Applikationen für unterschiedliche Betriebssysteme zu entwickeln. Um diese Möglichkeiten zu schaffen, wurde die enge Kopplung zwischen .NET und Windows entfernt und der Fokus wurde auf die Kerneigenschafen einer .NET Applikation gelegt, die dadurch auf unterschiedlichen Betriebssystemversionen ausgeführt werden kann. Es wurde bereits be- kanntgegeben, dass .NET Core und .NET zu „.NET 5.0“ verschmelzen und noch im November 2020 veröffentlicht wird. Im Jahr 2021 soll dann die Version 6.0 folgen [Pri19, vgl. Seite 7-10].
Abbildung 4.1.: Visualisierung der Zielsysteme des .NET und des .NET Core Frameworks [CdlT20, vgl. Seite 17]
In Abbildung 4.1 ist erkennbar, dass das .NET Framework nur das Windows Kernsystem unterstützt und nur am hauseigenen Webserver IIS ausgerollt werden kann. In .NET Core hingegen, werden sowohl Linux als auch der Windows Nano Server als optimierte Cloud Platt- form unterstützt. Die Entwicklung der Microservices und der Bezug zur Cloud-Architektur in der vorliegenden Arbeit, werden mittels .NET Core umgesetzt.
4.2. Blazor
Das Frontend hat keinen direkten Bezug zur Forschungsfrage, da es keinen Einfluss auf die Architekturform nimmt. Um aber eine repräsentative Testanwendungen zu implementieren und Blazor als aktuelle Technologie im Presentation Layer zu nutzen, wurde Microsofts Blazor ausgewählt. Bei Blazor handelt es sich um ein Framework zur Webentwicklung für sogenannte
„Single-Page Applications“. Bei einer SPA handelt es sich um ein Webframework, dass aus mehreren unterschiedlichen Komponenten besteht. Dabei wird die Ansicht der Komponente dynamisch erzeugt, sodass nicht die komplette Seite im Browser neu geladen werden muss [GBD19, vgl. Seite 4]. Microsoft Blazor ist Ende September 2019 erstmals in .NET Core 3.0 erschienen und wurde mit Beginn des Jahres in Version 3.1 mit Fehlerbehebungen offiziell veröffentlicht.
Das Ziel von Blazor ist es, die Programmiersprache C# über den Browser auszuführen. Das hat den Vorteil, dass angestammte Softwareentwickler*innen bei ihrer Programmiersprache bleiben können und keine zusätzlichen Skriptsprachen erlernen müssen. Ein Nachteil kann aber sein, dass die Anwender*innen dieser Frameworks Gefahr laufen, in eine proprietäre Richtung abzudriften. Grundsätzlich wird bei Blazor zwischen zwei unterschiedlichen Kom- ponentenmodellen unterschieden. Die klassische Variante ist es, den Programmcode server- seitig auszuführen. Das bedeutet das die Lastverteilung des Frontends am Server passiert
und somit Ressourcen auf der Host-Maschine verbraucht werden. Die andere Variante ist es, Blazor über WebAssembly auszuführen. Dadurch wird die komplexe Programmlogik auf die Ressourcen des Zielcomputers verteilt, die Businesslogik wird aber am Server belassen. Der Vorteil ist, dass die Ressourcen des aufrufenden Clients verbraucht werden und nicht die des Servers. WebAssembly ist eine Art Bytecode der in modernen Browsern ausgeführt werden kann. In der nachfolgenden Grafik wird die Gegenüberstellung beider Varianten illustriert.
Abbildung 4.2.: Blazor Server vs Blazor WebAssembly [Sch20, vgl. Seite 24]
Wie in Abbildung 4.2 dargestellt ist, werden die Browserkomponenten im Falle des serverside Blazors über den aufgerufenen Server zur Verfügung gestellt. Das heißt, dass die Ressourcen für das DOM mittels SignalR über den Server bereitgestellt werden. Im Gegensatz dazu steht der Aufruf via WebAssembly. Wie in der Grafik gut erkennbar ist, werden die Ressourcen über den Client verteilt und der generische Teil des Programmcodes wird im Browser via C#
und WebAssembly ausgeführt. In der vorliegenden Arbeit wurde das Frontend mittels „Blazor Server“ ausgeführt, um die Implementierung des Monolithen repräsentativer zu gestalten.
4.3. Entity Framework Core
Bei Entity Framework Core handelt es sich um eine Software-Bibliothek, die es Software- entwickler*innen erlaubt über .NET Core Applikationen auf eine Datenbank zuzugreifen.
Der objekt-relationale Mapper des EF Core erlaubt es einerseits mit relationalen Struktu- ren einer Datenbank zu interagieren, sowie andererseits mit den objektorientierten Code- Fragmenten einer .NET Core Applikation. Dadurch ist es möglich in kürzester Zeit Daten- bankschemen zu erzeugen und entsprechend zu mappen [Smi18, vgl. Seite 3]. Konkret gibt es dabei zwei Ansätze, den „Code-First“ und den „Database-First“ Ansatz. Beim Code-First Ansatz wird das Datenbankschema mittels Programmcode objektorientiert erzeugt und über Dotnet-Kommandobefehle in die Datenbank migriert. Der Database-First Ansatz geht davon aus, dass es bereits eine existierende Datenbank gibt. Mittels einem Dotnet-Kommandobefehls kann das Datenbankschema in C# generierten Code extrahiert und anschließend in ein Visual
Studio-Projekt integriert werden.
Die Datenbankzugriffe der in dieser Arbeit entwickelten Applikationen erfolgen über Entity Framework Core. Für das Design wurde der Database-First Ansatz verwendet.
4.4. Heroku
Das Hosting einer Webapplikation ist ein wichtiges Entscheidungskriterium, wenn es darum geht gute Software-Performance und Ausfallsicherheit zu gewährleisten. Bei Heroku handelt es sich um eine Container-Plattform, die es Benutzer*innen ermöglicht Apps zu deployen, zu skalieren und zu verwalten [Her20]. Es handelt sich hierbei um „Plattform as a Service“, das bereits im Kapitel Basisinformationen ausführlich beschrieben wurde. Heroku agiert in diesem Zusammenhang als eine Art Mittelsmann. Die darunterliegende Infrastruktur ist tech- nologisch basierend auf Amazon Web Services EC2. Das bedeutet also, dass Heroku ein Ma- nagement Interface und ein CLI bereitstellt, dass es User*innen stark erleichtert, die AWS Infrastruktur zu nutzen und unabhängige isolierte Container zu erzeugen [Sta17, vgl. Seite 5]. Heroku wird in dieser Arbeit als Cloud-Provider für das Deployment und die Verwaltung der Container benützt.
4.5. GitHub
In diesem Subkapitel wird auf die Codeversionsverwaltung eingegangen. Weiters wird der Unterschied zwischen Git und GitHub erklärt.
Bei einem Codeversionierungssystem handelt es sich um ein System, dass Programmände- rungen über die Zeitspanne seiner Existenz aufzeichnet. Sogenannte Branches sind Verzwei- gungen des Programmcodes, die eine Version mit bestimmter Funktionalität deklarieren. Im Kontext einer Cloud spricht man meist von einer „Codebase“, die den Quellcode beinhal- tet und ihn zur Ausführung des Deployments aus dem angegebenen Branch auscheckt und anschließend deployed. Die Technologie die dazu benützt wird nennt man Git [SC14, vgl.
Seite 17]. Im Gegensatz dazu handelt es sich bei Microsofts GitHub um ein Produkt, dass Git als darunterliegende Technologie verwendet. GitHub hat Funktionalitäten, um Code zu verwalten, zu versionieren, Unit-Tests auszuführen und Deployment-Pipelines einzurichten.
Ein weiterer großer Anbieter eines Repositorys mit Git als Technologiebasis, ist Atlassian mit seinem Produkt Bitbucket. In der vorliegenden Arbeit wird GitHub als zentrales Code- Repository verwendet, dass durch die Konnektivität zu Heroku auch die Deployment-Pipline bedienbar macht.
4.6. PostgreSQL
Das Datenbankschema einer Applikation ist entscheidend dafür, wie die Geschäftslogik der Applikation schlussendlich aufgebaut wird. Bei PostgreSQL, umgangssprachlich „Postgres“
genannt, handelt es sich um ein objekt-relationales Datenbankmanagementsystem. Sie wurde an der Universität Berkeley im Jahr 1986 entwickelt. Sie unterliegt der Open-Source Lizenz und ist deshalb frei erhältlich [Pos20]. Im Gegensatz zu MariaDB und MySQL Datenbanken, kann PostgreSQL für höher skalierbare Anwendungen eingesetzt werden. Deshalb ist sie auch im Bereich der Cloud sehr beliebt. Eine vergleichbare kommerzielle Datenbank ist beispiels- weise der Microsoft Sequel Server (MSSQL). Ein großer Vorteil der PostgreSQL-Datenbank ist, wie schon erwähnt, die freie Verfügbarkeit als Open-Source Produkt und die Verfügbar- keit bei vielen Cloud-Providern durch die Beliebtheit innerhalb der Community. Ein Nachteil ist, dass Postgres im Kontext der Cloud oft auf geteilten SQL-Clustern eingesetzt wird. Das bedeutet, dass meist nur zwischen 20 - 100 gleichzeitige Verbindungen zur Datenbank geöffnet sein können. Das Datenbankschema wurde mittels Entity Framework als objekt-relationaler Mapper in PostgrSQL abgebildet. Es wird im weiteren Verlauf der Arbeit noch ausführlich beschrieben.
4.7. MongoDB
Bei der MongoDB handelt es sich um eine „NoSQL“ Datenbank. Im Bereich der modernen Big Data Lösungen gewinnen NoSQL Datenbanklösungen immer mehr an Beliebtheit, weil sie mit großen Datenmengen umgehen können und sehr performant sind. Eine weitere Eigen- schaft der NoSQL-Datenbanken ist, dass sie unstrukturierte Daten verarbeiten können. Das bedeutet aber auch, das sie kein relationales Datenbankschema haben und somit keine Bezie- hungen zwischen Datensätzen herstellen können. Sie werden nur als Datenspeicher benützt.
Je nach Anwendungsfall kann sie aber sehr hilfreich sein. Wenn eine Menge von Daten, wie beispielsweise Bilder oder Transaktionen geladen oder gespeichert werden sollen, sind NoS- QL Datenbanken optimal, da sie auch sehr gut horizontal skalierbar sind. Um nochmals zu MongoDB zurück zu kommen, handelt es sich hier um einen sogenannten Document Store, der in Social Media Applikationen oder Kriminaldatenbanken zum Einsatz kommt [CD17, vgl. Seite 1]. In dieser Masterabeit wird MongoDB bei der Implementierung der Cloud-Native Anwendung als zusätzlicher Datenspeicher, neben PostgreSQL eingesetzt.
4.8. RESTful
Der Representational State Transfer ist ein Architekturstil für moderne Webservices. Er wur- de im Jahr 2000 von Roy Thomas Fielding in seiner Dissertation vorgestellt [Fie00, vgl. Seite 94]. Fielding beschreibt in seiner Arbeit einen abstrakten Ansatz, ohne Vorgabe oder Empfeh- lung von Protokollen, Diensten oder Prozessen. Dadurch wurde ein Modell präsentiert, dass
skalierbar und vor allem interoperabel ist. Damit eine Schnittstelle als „Restful“ bezeichnet werden kann, muss sie einige Kriterien erfüllen, die nachfolgend erklärt werden.
Client-Server-Architektur
Da REST im Kontext einer SOA eingesetzt wird, wird nach einem Client-Server-Modell verlangt. Das bedeutet, dass die Ressource- bzw. die Datenhaltung vom User-Interface abge- schottet werden soll. Das bietet den Vorteil, dass Frontend-Applikationen leichter auf andere Plattformen portiert werden können. Dadurch, dass die Last der Benutzer*innenaktionen von der Backendserverkomponente getrennt werden, können bessere Skalierungen erzielt werden.
Zustandslosigkeit
Beim Aufruf eines Services müssen vom Client immer alle angeforderten Daten übermittelt werden, um eine Serverinteraktion auszulösen. Das bedeutet, dass jede Transaktion als einzeln und vor allem unabhängig betrachtet wird, um Inkonsistenzen zu vermeiden. Einen gespei- cherten Kontext eines vorherigen Aufrufs gibt es nicht.
Caching
Anders als zum Kontext können aber Caching-Funktionen genutzt werden. Die verwendete Infrastruktur eines Rest-Services kann dazu benutzt werden, um Daten zwischen zu speichern.
Das bietet den Vorteil, dass nochmalige Aufrufe viel schneller ausgeführt werden können, da das Service nur aus dem Cache liest. Der Nachteilt kann aber sein, dass nach einer abgelau- fenen Zeitspanne falsche oder alte Daten geliefert werden.
Einheitliche Schnittstellenbeschreibung
Das Uniform-Interface beschreibt die Einfachheit und die einheitliche Definition einer Schnitt- stelle. Im Gegensatz zu SOAP werden im Kontext von Http, alle Rest-Aufrufe in Methoden unterteilt. Die gängigsten Methoden dabei sind GET, POST, PUT und DELETE [Daz12, vgl. Seite 3].
Layered System
Der Aufbau eines mehrschichtigen Systems dient der Kapselung. So bleibt dem*er Aufrufer*in die darunterliegende Komplexität verborgen. Übrig bleibt die nach außen hin angebotene Schnittstelle.
Code-On-Demand
Bei Code-On-Demand handelt es sich um die Möglichkeit, ausführbaren Code an den Client zu senden.
Eine alternative Methode zur Modellierung von Webservices ist SOAP. Im Gegensatz zu Rest- ful wird bei Simple Object Access Protokollen als Dateneingabe XML benützt. SOAP-Services
