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.

Weitere ähnliche Inhalte

PDF
Cloud Ready? Migration von Anwendungen in die Cloud
PDF
Cloud-native Apps 2.0
PDF
Data Center Automation for the Cloud
PDF
Cloud Native und Java EE: Freund oder Feind?
PPTX
02 Computing Concepts der COMLINE Cloud Service Platform - CSP
PDF
Deutsche Börse Cloud Exchange - Präsentation
PPTX
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
PPTX
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
Cloud Ready? Migration von Anwendungen in die Cloud
Cloud-native Apps 2.0
Data Center Automation for the Cloud
Cloud Native und Java EE: Freund oder Feind?
02 Computing Concepts der COMLINE Cloud Service Platform - CSP
Deutsche Börse Cloud Exchange - Präsentation
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...

Ähnlich wie Cloud-native Applikationen (20)

PDF
Cloud Infrastructure with Crossplane
PDF
Private Cloud mit Open Source
PDF
Jug nbg containerplattform dcos
PDF
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
PPTX
The cloud 2011
PPTX
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
PDF
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
PDF
Steinzeit war gestern! Wege der cloud-nativen Evolution
PPTX
TRANSCONNECT® cloud (SQL Projekt AG)
PDF
Zeitreihen in Apache Cassandra
PPTX
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
PDF
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
PPTX
Cloud Computing Übersicht
PPTX
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
PDF
Cloud Computing für die Verarbeitung von Metadaten
KEY
papaya AWS Präsentation CeBIT 2010
PPTX
Service Orchestrierung mit Apache Mesos
PDF
JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7
PDF
Integration von OnSite- und Cloud-Systemen mit TransConnect® cloud
PDF
Mit TransConnect® einfach die Produktion vernetzen: mit wenigen Schritten zur...
Cloud Infrastructure with Crossplane
Private Cloud mit Open Source
Jug nbg containerplattform dcos
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
The cloud 2011
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der cloud-nativen Evolution
TRANSCONNECT® cloud (SQL Projekt AG)
Zeitreihen in Apache Cassandra
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
Cloud Computing Übersicht
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Cloud Computing für die Verarbeitung von Metadaten
papaya AWS Präsentation CeBIT 2010
Service Orchestrierung mit Apache Mesos
JavaAktuell - Skalierbare Cluster-Topologien mit dem JBoss AS 7
Integration von OnSite- und Cloud-Systemen mit TransConnect® cloud
Mit TransConnect® einfach die Produktion vernetzen: mit wenigen Schritten zur...
Anzeige

Mehr von QAware GmbH (20)

PDF
QAware_Mario-Leander_Reimer_Architecting and Building a K8s-based AI Platform...
PDF
Frontends mit Hilfe von KI entwickeln.pdf
PDF
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
PDF
50 Shades of K8s Autoscaling #JavaLand24.pdf
PDF
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
PPTX
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
PDF
Down the Ivory Tower towards Agile Architecture
PDF
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
PDF
Make Developers Fly: Principles for Platform Engineering
PDF
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
PDF
Was kommt nach den SPAs
PDF
Cloud Migration mit KI: der Turbo
PDF
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
PDF
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
PDF
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
PDF
Kubernetes with Cilium in AWS - Experience Report!
PDF
50 Shades of K8s Autoscaling
PDF
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
PDF
Service Mesh Pain & Gain. Experiences from a client project.
PDF
50 Shades of K8s Autoscaling
QAware_Mario-Leander_Reimer_Architecting and Building a K8s-based AI Platform...
Frontends mit Hilfe von KI entwickeln.pdf
Mit ChatGPT Dinosaurier besiegen - Möglichkeiten und Grenzen von LLM für die ...
50 Shades of K8s Autoscaling #JavaLand24.pdf
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Fully-managed Cloud-native Databases: The path to indefinite scale @ CNN Mainz
Down the Ivory Tower towards Agile Architecture
"Mixed" Scrum-Teams – Die richtige Mischung macht's!
Make Developers Fly: Principles for Platform Engineering
Der Tod der Testpyramide? – Frontend-Testing mit Playwright
Was kommt nach den SPAs
Cloud Migration mit KI: der Turbo
Migration von stark regulierten Anwendungen in die Cloud: Dem Teufel die See...
Aus blau wird grün! Ansätze und Technologien für nachhaltige Kubernetes-Cluster
Endlich gute API Tests. Boldly Testing APIs Where No One Has Tested Before.
Kubernetes with Cilium in AWS - Experience Report!
50 Shades of K8s Autoscaling
Kontinuierliche Sicherheitstests für APIs mit Testkube und OWASP ZAP
Service Mesh Pain & Gain. Experiences from a client project.
50 Shades of K8s Autoscaling
Anzeige

Cloud-native Applikationen

  • 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.