Fachposter, 2017: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Fachhochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM). Bestellbar unter https://www.sigs-datacom.de/order/poster/Cloud-Native-Applikationen-Poster-2017.php (Dokument bitte herunterladen für bessere Lesbarkeit)

1. Cloud-native Applikationen
Der Cloud-native Stack
Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Fachhochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck
unter Mitwirkung von: Dr. Adersberger, QAware
Beispiel für Kostenassoziativität: Der
Betrieb einer vituellen Maschine für
100 Std. oder 100 virtueller Maschi-
nen für 1 Std. kostet (fast) dasselbe.
Weiterführende Links:
www.qaware.de/news/cloud-ready
www.sigs-datacom.de/wissen
IaaS Provider6
(Public, Private, Hybrid) stellen Computing, Networking und Storage Ressourcen
für elastische Plattformen bereit, sowohl als Ressourcen für Container Plattformen als auch für
Stateful Services.
Infrastructure
Layer (IaaS)
Cloud-native Datenbanken4
: Zur
Zustandsisolierung werden häufig
Cloud-native Datenbanken ge­­­nutzt.
Diese sind teilweise sogar transak­
tional, relational und verstehen SQL.
Cloud-native Da­tenbanken positio­
nierensichimCAP-Theorem:CP(con-
sensus) oder AP (eventual consis-
tency). Cloud-native Datenbanken
sind stark zweckgebunden (z.B.
kleiner Zustandsraum über viele
Anwendungen, großer Zustands-
raum + SQL + CP; großer Zustands-
raum + NoSQL).
ClusteredStorageSysteme5
stellen
persistenten Objekt-, Datei- oder
Block­­speicher für Stateful Services
sowie für Container und Dienste
bereit.
„Eine Cloud-native Applikation ist ein verteiltes, elastisches und
horizontal skalierbares Softwaresystem, welches aus Service-
orien­­tierten Komponenten (Diensten) besteht, die Zustände in ei-
nem Minimum an zustandsbehafteten Komponenten isolieren. Die
Applikation und ihre Komponenten werden gemäß Cloud-spezifi-
scher Entwurfsmuster entworfen und auf einer elastischen Platt-
form betrieben.“
Definition
Referenzmodell
Definitionund
Erläuterungen
CNAEngineering
Trends
CNA unterscheiden sich damit von „klassischen“ Multi-Tier Appli­ka­­tionen vor allem hin-
sichtlich des Grades ihrer Verteilung und ihrer Elastizität.
CNA sind elastisch, d.h. sie können ihren Ressourcenbedarf dem zu verarbeitenden
Workload (idealerweise vollautomatisch) anpassen, um so das Pay-as-you-go Prinzip
und die Kostenassoziativität des Cloud Computing als Kostenvorteil zu nutzen.
CNA sind insbesondere für Anwendungen interessant, deren Workload schwer prog­­
nostizierbar ist, deren Nutzung Peak-Loads unterliegt oder für die exponentielles
Wachstum angestrebt wird.
Prinzipien von CNA:
L
I
D
E
A
Isolated State
Um horizontale Skalierbarkeit zu opti­
mie­­ren, versucht man zustandsbehaftete
Komponenten und deren Skalierungskom-
plexität zu isolieren.
Distributed
CNAsindverteilteSysteme(web-scale),die
aus unabhängig voneinan­der austausch­
baren Diensten komponiert werden.
Elastic
CNAsindelastisch,d.h.siefordernRessour­
cen (Compute, Storage, Network) abhängig
von einer Last an (wenig Last → wenig Res-
sourcen, hohe Last → mehr Ressourcen).
Die Skalierung erfolgt dabei meist horizon-
tal (mehr Ressourcen) und nicht vertikal
(stärkere Ressourcen).
Automated
CNA sollten meist auf automatisierten
Plattformen betrieben werden die wenig
bis keinen Operatoreingriff erfordern.
Loosely coupled
Die Dienste rufen sich untereinander idea­
ler­weise nicht direkt auf, sondern inter­
agieren indirekt über entkoppelnde Mes-
saging-Lösungen.
In Anlehnung an: Fehling, C., Leymann, F., Retter, R., Schupeck,
W., Arbitter, P., „Cloud Computing Patterns -Fundamentals to Design,
Build, and Manage Cloud Applications“, Springer, 2014
Design for Failure
(„Everthing fails all the time“):
Mittels Resilienz schützen sich Cloud-native
Applikationen z.B. per Circuit Breaker vor einer
fehlerhaften und langsamen Umgebung. Ein-
zelne Serviceausfälle sollten nie die gesamte
Cloud-native Applikation beeinträchtigen.
Center of Excellence
Elastische Plattformen
Eine verteilte Middleware zur
Ausfüh­­­rung standardisierter Con-
tainer. Diese Plattformen dienen der
Ressourcen-effizienteren Nutzung und
Integration von IaaS Infrastrukturen un-
terschiedlicher Cloud Provider.
Zustandsisolierung
Zustandslose Komponenten sind einfacher horizontal zu skalieren.
Zustandsbehaftete Komponenten können nicht vermieden werden. Um
Gesamtsysteme einfach skalieren zu können, versucht man Zustände in we-
nigen zustandsbehafteten Komponenten zu isolieren, um Skalierungskom-
plexität auf diese zu beschränken. Dies erfolgt häufig mittels sogenannter
Cloud-native Datenbanken (die von sich aus horizontal skalierbar sind).
DevOps
Ein auf Deployment Automati­sie­­rung basie-
render Ansatz Soft­ware­entwicklung mit dem
IT-Be­­trieb agiler zu verschränken. Für eine besse-
re Diagnostizierbarkeit werden Logs, Traces und
Metriken so zusammengeführt und bereitgestellt,
dass sie möglichst zentral analysierbar sind.
Container
Um Deployments zu standardisie­
ren, werden Komponenten häufig in
Form unabhängiger Container bereitge­
stellt. Diese Container umfassen den
Code, Laufzeitumgebung, System Biblio-
theken und erforderliche Konfiguration.
Lose Kopplung
Service Komposition kann mittels Events
oder Datenkopplung erfolgen. Bei Eventba­­
sierter Kopplung werden häufig Messaging oder
Streaming-Systeme eingesetzt. Erfolgt die Kopp-
lung datengestützt werden meist Cloud-native
Datenbankeneingesetzt(s.a.Zustandsisolierung)
1
Framework Dienste: Apache Spark, Fission, Spring by Pivotal | 2
Messaging und Streaming Dienste: Active MQ, Rabbit MQ, Kafka | 3
Elastische Container Plattformen: Docker, Data-
center, Kubernetes, Mesos | 4
Cloud-native Datenbanken: Beispiele für kleiner Zustandsraum + CP: Zookeeper, ETCD • großer Zustandsraum + SQL + CP: Cockroach DB • großer Zu-
standsraum + NoSQL (+ AP): Cassandra, MongoDB, CouchDB, neo4j | 5
Clustered Storage Systeme: Ceph, GlustersFS | 6
IaaS Provider: Amazon Web Servies, Google Compute Engine,
Microsoft Azure, OpenStack …
­Microservices
Microservices sind kleine, unab-
hängig voneinander austauschbare
und horizontal skalier­bare Dienste für eine
klar umrissene fachliche Aufgabe. Micro-
services bieten häufig eine REST Schnitt-
stelle, die API-getrieben entwickelt wird.
Eine CNA wird von Endnutzern als „die Applikation“ empfun-
den. Sie setzt sich im Hintergrund aus für den Nutzer nicht
mehr direkt sicht­baren Diensten zusammen.
App Layer
(SaaS)
Applikationsspezifischer
Dienst A
Applikationsspezifischer
Dienst B
Applikationsspezifischer
Dienst C
stützen sich auf funktionale Dienste ab.Cloud-native Applikation
Service Layer
(XaaS)
Cluster Layer
(PaaS)
CNA werden häufig auf elastischen Self-Service-Plattformen betrieben und
basieren auf Software-Defined-Infrastruktur Prinzipien.
Architekturen von CNA sind meist Service-orientiert und folgen zunehmend
der pragmatischen Microservice-Interpretation dieses Ansatzes.
CNA Entwicklungsmethodiken beruhen oft auf Cloud-spezifischen Software-
entwicklungsmustern und DevOps Ansätzen.
(N. Kratzke, P.-C. Quint, Understanding Cloud-native Applications after 10 Years of Cloud Computing, Journal of Software and Systems, 2017)
Portierbare (Multi-)Cloud Runtime Enviroment für Container
Access management
Authentication
Auto scaling, Load balancing
Health checking, Rolling updating
Image registry
Registry/service discovery
Ressource monitoring
Weitere Dienste (Logs, Traces, Metric Consolidation
and Analysis, Batchjobs, Service Meshes)
Framework Dienste1
ermöglichen eine schnellere
Entwicklung App-spezifischer Dienste.
Messaging und Streaming Dienste2
ermöglichen
lose (Echtzeit-)Kopplung von Diensten.
werden auf elastischen Plattformen betrieben.Funktionale Dienste
Elastische Container Plattformen3 integrieren IaaS Ressourcen zu einem logischen Cluster.
Cloud-native Applikationen (CNA): Softwaresysteme, die explizit für die Cloud entwickelt werden
Stateful Services
Dienste interagieren hierzu mit anderen Diensten. Diens-
te werden mittels standardisierter Deployment Units (z.B.
Container) ausgebracht. Stateful Services3
dienen dem Iso-
lieren von Zuständen.
Container Plattformen stellen elastische
Cloud Runtime Enviroments für Dienste und
deren Container bereit mit erforderlichen
Features wie:
Tools
(Beispiele)
Cloud Application Maturity Level
In Anlehnung an: OPEN DATA CENTER ALLIANCE Best Practices: Architecting Cloud-
Aware Applications (Rev. 1.0) und Mario-Leander Reimer (QAWare)
Level Maturity
3 | Adaptive Cloud Native
Applikation skaliert elastisch
(lastabhängig)
Migration auf andere Infra-
strukturen ohne Service
Downtime
2 | Abstracted Cloud Resilient
Dienste sind stateless
Applikation ist designed for failure
Applikation ist Infrastruktur
agnostisch (runs anywhere)
1 | Loosely
Coupled
Cloud Friendly
Applikation ist aus lose gekoppel-
ten Diensten komponiert
Dienste sind per Namen
adressierbar
Applikation berücksichtigt
12-Factor App Prinzipien
Applikation trennt Compute und
Storage Dienste
Applikation basiert auf Compute-,
Storage- und Netzwerkdiensten
0 | Virtualized Cloud Ready
Applikation läuft auf virtualisierter
Infrastruktur
Applikation kann automatisiert
ausgeprägt werden
IT-Probleme lösen. Digitale Zukunft gestalten.