Cloud-native Computing - Versionsgeschichte

Xenein: /* growthexperiments-addlink-summary-summary:3|0|0 */

2024-11-12T22:22:13Z

Linkvorschlag-Funktion: 3 Links hinzugefügt.

← Nächstältere Version		Version vom 13. November 2024, 00:22 Uhr
Zeile 14:		Zeile 14:
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. „Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können“.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. „Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können“.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine [[Komponente (Software)\|Softwarekomponente]] und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme [[Laufzeitumgebung]] sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine ~~„Middleware~~ für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine „[[Middleware]] für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

ThoughtForge: /* Eigenschaften */ Gerade mit typografischen Anführungszeichen ersetzt

2024-03-21T12:56:20Z

Eigenschaften: Gerade mit typografischen Anführungszeichen ersetzt

← Nächstältere Version		Version vom 21. März 2024, 14:56 Uhr
Zeile 15:		Zeile 15:
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für ~~"mehrere~~ Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu ~~bieten"~~.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine ~~"Middleware~~ für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten ~~wird"~~.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine „Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

Visualnarrative: Interwikilink entfernt

2023-12-19T07:36:53Z

Interwikilink entfernt

← Nächstältere Version		Version vom 19. Dezember 2023, 09:36 Uhr
Zeile 1:		Zeile 1:
	'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der [[Cloud Computing]] nutzt, um skalierbare Anwendungen in Cloud-Infrastrukturen, -Plattformen und -Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und ~~[[:en:Infrastructure_as_code\|~~Infrastructure as Code]]), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=Cloud Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>		'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der [[Cloud Computing]] nutzt, um skalierbare Anwendungen in Cloud-Infrastrukturen, -Plattformen und -Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und Infrastructure as Code), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=Cloud Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>

	== Definition ==		== Definition ==

Stegosaurus Rex: /* Einleitung */

2023-11-21T09:17:49Z

Einleitung

← Nächstältere Version		Version vom 21. November 2023, 11:17 Uhr
Zeile 1:		Zeile 1:
	'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der [[Cloud Computing]] nutzt, um skalierbare Anwendungen in Cloud-Infrastrukturen, -Plattformen und -Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und [[:en:Infrastructure_as_code\|Infrastructure as Code]]), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=~~☁️♮🏛Cloud~~ Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>		'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der [[Cloud Computing]] nutzt, um skalierbare Anwendungen in Cloud-Infrastrukturen, -Plattformen und -Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und [[:en:Infrastructure_as_code\|Infrastructure as Code]]), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=Cloud Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>

	== Definition ==		== Definition ==

Stegosaurus Rex: /* Einleitung */

2023-11-21T09:16:10Z

Einleitung

← Nächstältere Version		Version vom 21. November 2023, 11:16 Uhr
Zeile 1:		Zeile 1:
	'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der Cloud Computing nutzt, um skalierbare Anwendungen in Cloud Infrastrukturen, Plattformen und Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und [[:en:Infrastructure_as_code\|Infrastructure as Code]]), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=☁️♮🏛Cloud Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>		'''Cloud-native Computing''' ist ein Ansatz in der [[Softwaretechnik\|Softwareentwicklung]], der [[Cloud Computing]] nutzt, um skalierbare Anwendungen in Cloud-Infrastrukturen, -Plattformen und -Umgebungen zu erstellen und auszuführen. Gemäß der [[Cloud Native Computing Foundation\|Cloud Native Computing Foundation (CNCF)]] prägen diesen Remote-Computing-Ansatz insbesondere Technologien wie [[Containervirtualisierung\|Container]], [[Microservices]] sowie [[Function as a Service\|serverlose Funktionen]] und unveränderliche Infrastrukturen (Immutable Infrastructures und [[:en:Infrastructure_as_code\|Infrastructure as Code]]), die zumeist über [[Deklarative Programmierung\|deklarativen Code]] bereitgestellt werden.<ref>{{Internetquelle \|url=https://github.com/cncf/foundation/blob/8762d762d156af8e50e6d1246e2364e60c7952a8/charter.md \|titel=☁️♮🏛Cloud Native Computing Foundation Policy Repo \|hrsg=Cloud Native Computing Foundation (CNCF) \|datum=2022-01-03 \|abruf=2022-01-03}}</ref>

	== Definition ==		== Definition ==

Hutch: doppelte Namens-, Werks- oder Zitatauszeichnungen korrigiert

2023-10-27T05:05:44Z

doppelte Namens-, Werks- oder Zitatauszeichnungen korrigiert

← Nächstältere Version		Version vom 27. Oktober 2023, 07:05 Uhr
Zeile 11:		Zeile 11:

	* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring]]s liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.		* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring]]s liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.
	* '''Elastizität''' ist ~~''"der~~ Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf ~~übereinstimmen"''~~.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>		* '''Elastizität''' ist „der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen“.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ~~''"Strukturelle~~ Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu ~~können"''~~.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. „Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können“.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ~~''"eine~~ einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)~~"''~~.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
Zeile 21:		Zeile 21:

	== Einzelnachweise ==		== Einzelnachweise ==
	<references/>		<references />

	[[Kategorie:Cloud Computing]]		[[Kategorie:Cloud Computing]]

Invisigoth67: Steuerzeichen entfernt/ersetzt; form

2023-05-21T09:49:22Z

Steuerzeichen entfernt/ersetzt; form

77.7.28.127: /* Eigenschaften */

2023-05-20T09:25:53Z

Eigenschaften

← Nächstältere Version		Version vom 20. Mai 2023, 11:25 Uhr
Zeile 18:		Zeile 18:
	* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

	== Einzelnachweise ==		== Einzelnachweise ==

Godihrdt: Leerzeichen vor Referenz entfernt, Position von EN und Satzzeichen angepasst, Kleinigkeiten

2022-01-18T08:31:55Z

Leerzeichen vor Referenz entfernt, Position von EN und Satzzeichen angepasst, Kleinigkeiten

← Nächstältere Version		Version vom 18. Januar 2022, 10:31 Uhr
Zeile 11:		Zeile 11:

	* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring\|Monitorings]] liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.		* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring\|Monitorings]] liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.
	* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"'' <ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>.		* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"''.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"'' <ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>.		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"''.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“. <ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank\|Datenbanken]]) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank\|Datenbanken]]) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

CloudNativeNerd: Weitere sinnvolle Kategorien ergänzt

2022-01-04T18:29:56Z

Weitere sinnvolle Kategorien ergänzt

← Nächstältere Version		Version vom 4. Januar 2022, 20:29 Uhr
Zeile 24:		Zeile 24:

	[[Kategorie:Cloud Computing]]		[[Kategorie:Cloud Computing]]
			[[Kategorie:Softwarearchitektur]]
			[[Kategorie:Containervirtualisierung]]

← Nächstältere Version		Version vom 13. November 2024, 00:22 Uhr
Zeile 14:		Zeile 14:
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. „Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können“.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. „Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können“.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine [[Komponente (Software)\|Softwarekomponente]] und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme [[Laufzeitumgebung]] sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine ~~„Middleware~~ für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine „[[Middleware]] für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

← Nächstältere Version		Version vom 21. März 2024, 14:56 Uhr
Zeile 15:		Zeile 15:
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht „eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)“.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für ~~"mehrere~~ Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu ~~bieten"~~.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für „mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine ~~"Middleware~~ für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten ~~wird"~~.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine „Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird“.<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

← Nächstältere Version		Version vom 18. Januar 2022, 10:31 Uhr
Zeile 11:		Zeile 11:

	* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring\|Monitorings]] liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.		* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring\|Monitorings]] liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.
	* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"'' <ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>.		* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"''.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"'' <ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>.		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"''.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“. <ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank\|Datenbanken]]) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank\|Datenbanken]]) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

← Nächstältere Version		Version vom 21. Mai 2023, 11:49 Uhr
Zeile 2:		Zeile 2:

	== Definition ==		== Definition ==
	Cloud-native Technologien ermöglichen lose gekoppelte [[Software-System~~\|Software-Systeme~~]] (Cloud-native Applikationen), die [[Resilienz (Ingenieurwissenschaften)\|resilient]], beobachtbar und dank [[Autoscaling\|Auto-Scaling]] und Self-Healing in automatisierten Umgebungen mit minimaler Interaktion durch [[Administrator (Rolle)\|Administratoren]] betreibbar sind.		Cloud-native Technologien ermöglichen lose gekoppelte [[Software-System]]e (Cloud-native Applikationen), die [[Resilienz (Ingenieurwissenschaften)\|resilient]], beobachtbar und dank [[Autoscaling\|Auto-Scaling]] und Self-Healing in automatisierten Umgebungen mit minimaler Interaktion durch [[Administrator (Rolle)\|Administratoren]] betreibbar sind.
	{{Zitat		{{Zitat
	\|Text=Eine '''Cloud-native Anwendung (CNA)''' ist ein verteiltes, beobachtbares, elastisches und auf horizontale Skalierbarkeit optimiertes Service-of-Services System, das seinen Zustand in (einem Minimum an) zustandsbehafteten Komponenten isoliert. Die Anwendung und jede in sich geschlossene Bereitstellungseinheit dieser Anwendung wird nach Cloud-fokussierten Designmustern entworfen und auf elastischen Self-Service-Plattformen betrieben.		\|Text=Eine '''Cloud-native Anwendung (CNA)''' ist ein verteiltes, beobachtbares, elastisches und auf horizontale Skalierbarkeit optimiertes Service-of-Services System, das seinen Zustand in (einem Minimum an) zustandsbehafteten Komponenten isoliert. Die Anwendung und jede in sich geschlossene Bereitstellungseinheit dieser Anwendung wird nach Cloud-fokussierten Designmustern entworfen und auf elastischen Self-Service-Plattformen betrieben.
Zeile 10:		Zeile 10:
	Cloud-native Anwendungen sind daher oft durch eine oder mehrere der folgenden Eigenschaften charakterisiert:		Cloud-native Anwendungen sind daher oft durch eine oder mehrere der folgenden Eigenschaften charakterisiert:

	* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring~~\|Monitorings~~]] liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.		* '''Beobachtbarkeit''' bei Software-Systemen bezieht sich typischerweise auf [[Telemetrie (Software)\|Telemetriedaten]], die meist in drei Aspekte unterteilt werden: [[Ablaufverfolgung\|Tracing]] (verteilte Ablaufverfolgung) ermöglicht Einblick in den Lebenszyklus von Requests in einem verteilten System. Metriken im Rahmen eines [[Monitoring]]s liefern quantitative Informationen zu Prozessen, die im System ausgeführt werden. Mittels [[Logging]] (Protokollierung) lässt sich Einblick in anwendungsspezifische Nachrichten, die von Prozessen ausgegeben werden, gewinnen. Diese Beobachtbarkeit ist insbesondere für die [[DevOps]]-Prinzipien des Feedback essentiell.
	* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"''.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>		* '''Elastizität''' ist ''"der Grad, in dem ein System in der Lage ist, sich an Workload-Änderungen anzupassen, indem es Ressourcen in einer autonomen Art und Weise provisioniert und deprovisioniert, so dass zu jedem Zeitpunkt die verfügbaren Ressourcen so gut wie möglich mit dem aktuellen Bedarf übereinstimmen"''.<ref>{{Literatur \|Autor=Nikolas Roman Herbst, Samuel Kounev, Ralf Reussner \|Titel=Elasticity in Cloud Computing: What It Is, and What It Is Not \|Datum=2013 \|ISBN=978-1-931971-02-7 \|Seiten=23–27 \|Online=https://www.usenix.org/conference/icac13/technical-sessions/presentation/herbst \|Abruf=2022-01-04}}</ref>
	* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.		* '''[[Skalierbarkeit]]''' kann in strukturelle Skalierbarkeit und Lastskalierbarkeit unterschieden werden. ''"Strukturelle Skalierbarkeit ist die Fähigkeit eines Systems, sich in einer gewählten Dimension ohne größere Änderungen an seiner Architektur zu erweitern. Unter Lastskalierbarkeit ist die Fähigkeit eines Systems zu verstehen, auch steigendem Datenverkehr bewältigen zu können"''.
	* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"''.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>		* '''Service-of-Services Systeme''' werden bei Cloud-nativen Anwendungen zumeist im Microservice-Architekturstil verstanden. Dieser Architekturstil versteht ''"eine einzelne Anwendung als eine Suite kleiner [[Serviceorientierte Architektur\|Services]], die jeweils in einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen kommunizieren. Diese Services sind um Geschäftsfunktionen herum aufgebaut und können unabhängig voneinander von vollautomatischen Bereitstellungsmechanismen aktualisiert werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen ([[Polyglottes Programm\|polyglotte Programmierung]]) geschrieben sein können und unterschiedliche Datenspeichertechnologien verwenden (polyglotte Datenhaltung)"''.<ref>{{Internetquelle \|url=https://martinfowler.com/articles/microservices.html \|titel=Microservices \|abruf=2022-01-04}}</ref>
	* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>		* '''In sich geschlossene Bereitstellungseinheiten''' (Deployment Unit) sind ein Teil der Deployment-Topologie der Anwendung zur Realisierung einer bestimmten technischen Einheit. Immer häufiger wird eine Deployment Unit als „ein Standardcontainer verstanden. Das Ziel eines Standardcontainers ist es, eine Softwarekomponente und alle ihre Abhängigkeiten in einem Format zu kapseln, das selbstbeschreibend und portabel ist, so dass jede konforme Laufzeitumgebung sie ohne zusätzliche Abhängigkeiten ausführen kann, unabhängig von der zugrunde liegenden Maschine und dem Inhalt des Containers“.<ref>{{Internetquelle \|url=https://github.com/opencontainers/runtime-spec \|titel=Open Container Initiative Runtime Specification \|hrsg=Open Container Initiative \|datum=2022-01-04 \|abruf=2022-01-04}}</ref>
	* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank~~\|Datenbanken~~]]) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.		* '''Zustandsbehaftete Komponenten''' (meist [[Datenbank]]en) werden für "mehrere Instanzen einer skalierten Anwendungskomponente verwendet, die ihren internen Zustand synchronisieren, um ein einheitliches Verhalten zu bieten".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Da die Skalierung zustandsbehafteter Komponenten meist aufwändiger ist, als die Skalierung zustandsloser Komponenten, versucht man Zustände in möglichst wenigen zustandsbehafteten Komponenten zu isolieren.
	* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.		* Unter einer '''elastischen Plattform''' versteht man eine "Middleware für die Ausführung von benutzerdefinierten Anwendungen, deren Kommunikation und Datenspeicherung über eine Self-Service-Schnittstelle mittels eines Netzwerks angeboten wird".<ref>{{Literatur \|Autor=Cristoph Fehling \|Titel=Cloud computing patterns : fundamentals to design, build, and manage cloud applications \|Ort=Wien \|Datum=2014 \|ISBN=978-3-7091-1568-8}}</ref> Solche gut automatisierbaren Plattformen sind insbesondere für die [[DevOps]]-Prinzipien des Flow essentiell.

	Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.		Häufig werden Cloud-native Anwendungen daher als eine Reihe von Microservices erstellt, die in Containern ausgeführt werden.<ref>{{Literatur \|Autor=Sam Newman \|Titel=Building Microservices, 2nd Edition \|Auflage=2nd edition \|Datum=2021 \|ISBN=1492034029}}</ref> Sie können mittels Container-Plattformen wie bspw. [[Kubernetes]] orchestriert und mit DevOps- und Git-basierten [[Continuous Integration\|Continuous Integration und Deployment]]-Workflows verwaltet und bereitgestellt werden. Der Vorteil der Verwendung von Containern besteht darin, dass die gesamte Software inklusive aller Abhängigkeiten, die zur Ausführung benötigt wird, in Form in sich geschlossener Bereitstellungseinheiten vorgehalten werden kann. Container werden hierzu in virtualisierten Umgebungen ([[Betriebssystemvirtualisierung]]) ausgeführt, die die enthaltene Anwendung von ihrer Umgebung isoliert.

	== Einzelnachweise ==		== Einzelnachweise ==