Grundlagen und Architektur des Cloud Computing

Grundlagen und Architektur des Cloud Computing

Vor allem die Public Cloud wird zunehmend zu einem wesentlichen Bestandteil jedes modernen Unternehmens. Dies erfordert den Erwerb spezifischer Kenntnisse und betrieblicher Expertise, um Cloud-Infrastrukturen zu betreiben. Allerdings verfügt nicht jedes Unternehmen über das notwendige Wissen, insbesondere solche, die ohne ausreichende Expertise und Bewusstsein für Vorschriften und Sicherheitsbedenken in die Cloud migrieren. Laut Gartner werden bis 2025 mehr als die Hälfte der IT-Ausgaben von Unternehmen für Cloud-Infrastrukturen und -Dienste verwendet, die von großen Cloud-Service-Providern (CSP) bereitgestellt werden [1].

Der Hauptgrund für diesen Anstieg in den letzten Jahren liegt in der Tatsache, dass Cloud-Übergänge neue digitale Geschäftsmöglichkeiten bieten. Fast jedes Geschäftsmodell, das auf Künstlicher Intelligenz, maschinellem Lernen, Mikroservices und anderen modernen Technologien basiert, ist ein Beispiel dafür. Infolgedessen sind Unternehmen häufig gezwungen, die Public Cloud zu nutzen, um wettbewerbsfähig zu bleiben und ihren Marktanteil zu sichern. Dies zwingt die IT-Abteilungen dieser Unternehmen, Arbeitslasten, Dienste und Daten von traditionellen Rechenzentren oder Büros in die Public Cloud zu verlagern.

Das Problem bei diesem schnellen Übergang in die Cloud besteht darin, dass diese IT-Abteilungen, die an traditionelle Anforderungen und Bereitstellungen vor Ort gewöhnt sind, oft nicht gut darin geschult sind, die Cloud-Funktionen richtig zu nutzen. Neben der Verlagerung der Infrastruktur in die Cloud besteht eine weitere große Herausforderung darin, sie so abzusichern, dass Vorschriften eingehalten werden und Unternehmen vor Cyberangriffen geschützt sind.

Cloud Computing Konzepte

Geschichtlicher Background zu Cloud Computing

Die IT-Branche hat zahlreiche bedeutende Veränderungen durchlaufen auf ihrem Weg zum Cloud Computing. Es ist wichtig, zunächst die Geschichte des Cloud Computings zu verstehen, um zu begreifen, wo wir heute stehen. Dies wird verdeutlichen, wie die heutige Cloud entstanden ist und wie sich die cloudfähigen Technologien im Laufe der Zeit verändert haben. Wir sind durch eine Reihe von Cloud-Konzepten an diesen Punkt gelangt. Eines davon ist das Prinzip des Time-Sharing, das bis in die 1950er Jahre zurückreicht, als moderne Computer erfunden wurden. In den 1950er Jahren war das Time-Sharing besonders wichtig, weil Computer riesig, komplex und teuer waren. Es war nicht kosteneffektiv, einen Computer nur für ein Programm zu nutzen. Dank Time-Sharing-Schemata konnten mehrere Programme auf diesen leistungsstarken Computern laufen. Während das ursprüngliche Konzept manuell war und die Operatoren von einem Programm zum anderen wechselten, ist dies heute eines der Kernkonzepte jeder Arbeitslast in modernen Cloud-Infrastrukturen. Der Unterschied besteht nur darin, dass es heute hoch automatisiert ist und es ermöglicht, vorhandene Ressourcen effizient zwischen verschiedenen Rechenressourcen zu teilen. Ein weiteres Kernkonzept moderner Clouds ist die Fähigkeit, mit mehreren Netzwerken verbunden zu sein. Interconnected Networks (z.B. das Internet) entstanden Ende der 1960er und Anfang der 1970er Jahre und ermöglichten eine einfachere Methode zur weltweiten Informationsverteilung. Dies wurde zu einer Schlüsseltechnologie für alles in der IT-Branche. Insbesondere öffentliche Cloud-Ressourcen hängen stark von der Fähigkeit zur Interkonnektivität ab, da Ressourcen, die weit entfernt von den Unternehmen liegen, irgendwie erreichbar sein müssen. Die nächste große Innovation, die ein Kernkonzept jeder Cloud ist, ist die Virtualisierung. Virtualisierung existiert seit IBM in den 1970er Jahren ihr Virtual Machine (VM) Betriebssystem (OS) einführte, das es ermöglichte, dass mehrere virtuelle Systeme die zugrunde liegende physische Infrastruktur teilen. Virtuelle Maschinen wurden zu einem grundlegenden Bestandteil der IT. Ein Bare-Metal-Server war nun in der Lage, viele verschiedene Betriebssysteme zu hosten. Ein weiteres entscheidendes Element für das Cloud Computing, das zusätzlich zu Interkonnektivität und Rechenkapazität fehlt, ist Daten. Ohne Daten können weder Konnektivität noch Rechenleistung ihr volles Potenzial entfalten. Die Datenspeichertechnologien haben sich im Laufe der Jahre stetig weiterentwickelt, während andere Technologien voranschritten. Die Richtung ging dahin, den Speicher von der Arbeitslast zu entkoppeln und separat zu halten. Infolgedessen ist der Speicher zu einer der wichtigsten Komponenten und als Grundlage für Rechenleistung geworden. Technologien wie Datenbanken, RAIDs, Storage Area Networks (SAN) und Network Attached Storage (NAS) wurden entwickelt und sind noch heute in Gebrauch [2].

Cloud Computing Merkmale, Eigenschaften und Definition

Die Kombination dieser aus der Geschichte abgeleiteten Kernkonzepte führte zu verschiedenen Ansätzen im Cloud Computing und bot viele Lösungen für ein gegebenes Problem. Daher nahmen Unternehmen und Firmen unterschiedliche Strategien an. Sie bauten Rechenzentren, mieteten sie oder hatten alles in ihren Büros. Dies war lange bevor der Begriff "Cloud Computing" existierte. Das National Institute of Standards and Technology (NIST) definierte Cloud Computing wie folgt:

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models." [3]

Laut ihrer Definition gibt es beim Cloud Computing vier verschiedene Cloud-Bereitstellungstypen, drei verschiedene Cloud-Service-Modelle und fünf grundlegende Merkmale.

Der Kern des Cloud Computing wird durch die fünf wesentlichen Merkmale gebildet. Diese fünf Elemente umreißen die wesentlichen Merkmale einer Cloud. Im Kern bauen sie auf zwei Hauptkomponenten: physische Infrastruktur und eine Art Orchestrierungssystem. Die Infrastruktur einer Cloud-Umgebung besteht immer aus drei grundlegenden Komponenten: Speicher, Netzwerk und Rechenleistung. Diese drei Komponenten sind allein nicht ausreichend; die Nutzer müssen sie so konfigurieren können, dass sie ihren spezifischen Anforderungen entsprechen. Dies geschieht über Orchestrierungssoftware, die aus mehreren Teilen besteht, wobei eines davon immer eine Verwaltungsoberfläche für Kunden ist, die ihnen ermöglicht, ihre Cloud-Ressourcen zu steuern und zu überwachen.

Die fünf Kerneigenschaften sind folgende: [4]

On-demand Self-service

On-demand Self-Service bezieht sich auf einen Cloud-Dienst, der die Bereitstellung von Cloud-Ressourcen ermöglicht – wann und wo sie benötigt werden. Dies ist ein Verfahren, bei dem der Cloud-Kunde Cloud-Dienste ohne die Hilfe des Cloud-Anbieters bereitstellen, verwalten oder betreiben kann. Klassische Beispiele für diesen Self-Service sind die Webinterfaces bzw. anderen Schnittstellen von Cloud Service Providern oder auch von eigens gehosteten Cloud Umgebungen:

• Lokale Openstack Managment Plattform
• Lokale VMWare Management Plattform
• Container Management Plattformen mit Webinterface
• AWS Management Console: https://aws.amazon.com/console/
• GCP Management Console: https://console.cloud.google.com/
• Österreichisches Beispiel Anexia Console: https://www.anexia-engine.com/

Broad Network Access

Cloud-Ressourcen (Anwendungen, Rechenleistung, Verwaltungsoberflächen usw.) sollten über eine Netzwerkverbindung weitgehend zugänglich sein. Server, Personal Computer, Smartphones und nahezu jedes andere Gerät mit Internetzugang sollten in der Lage sein, sich mit den gegebenen Diensten zu verbinden. Die technische Grundlage dazu stellt das OSI-Referenzmodell. Mit diesem Standard ist es möglich, dass eigentlich viele unterschiedliche Endgeräte und Server miteinander kommunizieren können. (Nähere Erklärung)

Im Public Cloud Bereich bzw. bei größeren CSPs werden hier oft die Begriffe „Regions“ (Regionen) und „Availability Zones“ (Verfügbarkeitszonen) verwendet. In diesem Zusammenhang bedeutet es folgendes: Jede Cloud Region ist isoliert von einer anderen und kann z.B. EU-WEST heißen. In dieser Region gibt es dann noch mehrere Verfügbarkeitszonen. Diese Zonen sind geografisch voneinander getrennt, aber noch immer in derselben Region. In einer availability Zone sind dann meistens mehr als ein physisches Datacenter vorhanden. (Aufbau bei AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions)

Resource Pooling

Alle Cloud-Kunden teilen sich die Ressourcen des Cloud-Service-Providers (CSP), zu denen mehrere Server, Netzwerkkomponenten und Speichergeräte gehören. Dies ermöglicht eine angemessene und gleichmäßige Verteilung der Ressourcenauslastung.

Visuelle Darstellung von Ressource Pooling

Diese Grafik sollte es veranschaulichen, dass Cloud Provider primär Storage, Compute und Networking Services bereitstellen und auf diese geteilten Ressourcen eben Menschenmassen und Unternehmen zugreifen um so Applikationen und Services zu konsumieren.

Rapid Elasticity

Die Infrastruktur der Kunden kann in einer Cloud-Umgebung elastisch bereitgestellt und freigegeben werden. Dieser Skalierungsprozess kann sogar vollständig automatisiert werden, sodass die Infrastruktur nur mit ihrem absoluten Minimum an Ressourcen arbeitet. Vertikale und horizontale Skalierbarkeit kann somit einfach in einer Cloud-Umgebung implementiert werden.

Vertikale Skalierbarkeit:

Visuelle Darstellung von vertikaler Skalierbarkeit

In einer Cloud Computing Plattform sollte es auf einfache Art und Weise möglich sein eine einfache VM mit mehr Compute/Storage/Networking Ressourcen auszustatten.

Horizontale Skalierbarkeit:

Visuelle Darstellung von horizontaler Skalierbarkeit

In einer Cloud Computing Plattform sollte es auch möglich sein dieselbe VM zu klonen und mehrfach zu betreiben. Wichtig hierfür ist, dass im Hintergrund auf geteilte Daten bzw. Applikationen zugegriffen wird und die Auslastung mittels Load Balancer auf die einzelnen Instanzen aufgeteilt wird.

Measured Service

Cloud-Systeme optimieren und kontrollieren ihre Ressourcennutzung, um den Anforderungen der Anwendung und des Kunden gerecht zu werden. Darüber hinaus wird jede Cloud-Ressource ständig überwacht und ein automatisches Alarmsystem implementiert. Dies bietet den Kunden Transparenz und die Möglichkeit, Daten über Ressourcenauslastung, Kostenentwicklung, Netzwerkverkehr usw. für jeden Dienst zu generieren.

Eine Cloud-Plattform sollte es, da es sich um eine Software handelt, ermöglichen, auf jegliche Daten und Metriken der Auslastung/Benutzung zuzugreifen. Zum Beispiel: Traffic, verursachte Kosten, etc. Anhand dieser Daten sollte es dann auch noch die Möglichkeit geben, für sich selbst gewisse KPIs (Key Performance Indicators) bzw. Limits zu definieren und, wenn diese erreicht oder überschritten werden, ein entsprechendes Alarmsystem über ein Benachrichtigungssystem zu implementieren.

Cloud Referenzarchitektur

NIST Cloud Computing Reference Architecture

Die NIST Cloud Computing Reference Architecture bietet eine standardisierte Perspektive auf die verschiedenen Komponenten und Akteure in einem Cloud-Computing-Umfeld. Die Architektur identifiziert und beschreibt die Hauptrollen, Verantwortlichkeiten und Interaktionen der verschiedenen Akteure innerhalb des Cloud Computing-Ökosystems.

NIST CC Referenz Architektur

Hier sind die Rollen des NIST-Referenzmodells:

1. Cloud Consumer (Cloud-Kunde/Cloud Service Consumer - CSC):

   1. Individuen oder Organisationen, die Cloud-Dienste nutzen.

2. Cloud Provider (Cloud-Anbieter/Cloud Service Provider - CSP):

   1. Unternehmen, die Cloud-Dienste anbieten und verwalten.

   2. Verantwortlich für die Bereitstellung von Infrastruktur, Plattformen und Software als Dienstleistung (IaaS, PaaS, SaaS).

3. Cloud Broker (Cloud-Broker):

   1. Vermittler, die Cloud-Dienste von verschiedenen Anbietern zusammenfassen und an die Kunden weiterverkaufen.

   2. Optimieren die Nutzung von Cloud-Diensten für den Kunden.

4. Cloud Auditor (Cloud-Auditor):

   1. Unabhängige Stellen, die die Dienste und Sicherheit der Cloud-Anbieter überprüfen.

   2. Stellen sicher, dass die Cloud-Dienste den gesetzlichen und geschäftlichen Anforderungen entsprechen.

5. Cloud Carrier (Cloud-Carrier):

   1. Anbieter von Netzwerk- und Transportdiensten, die die Verbindung zwischen Cloud-Anbietern und Cloud-Kunden ermöglichen.

Diese Rollen beschreiben Abhängigkeiten und Akteure beim Einsatz von Cloud Computing Technologien. Demnach sind dies auch direkt die Abhängigkeiten entlang einer auf Cloud Computing basierten Wertschöpfungskette und müssen dementsprechend adressiert bzw. gepflegt werden.

In der NIST Definition sind dann des Weiteren noch die zwei Hauptkomponenten ausgeführt. Zum einen die Service Models (Dienstleistungsmodelle) und die Deployment Models (Bereitstellungsmodelle) die das Cloud Computing auszeichnen.

Cloud Computing Service Models

Cloud Service Models sind ein wesentlicher Bestandteil des Cloud-Computings, ebenso wie die fünf grundlegenden Merkmale. Laut der NIST-Definition von Cloud-Computing gibt es drei Cloud Service Models. Typischerweise werden diese Modelle als "* as a Service" bezeichnet, wobei das "*" für die Art der Bereitstellungsmethode steht [6], [7].

Folgende Dienstleistungsmodelle wurden offiziell definiert:

Software-as-a-Service (SaaS)

Das SaaS-Dienstmodell wird im Allgemeinen verwendet, um Software für Endbenutzer bereitzustellen. Diese können in zwei Zielgruppen unterteilt werden: entweder Business-to-Business-Software oder Business-to-Consumer-Software. SaaS-Anwendungen werden typischerweise über Web-, Desktop- oder mobile Anwendungen angeboten und sind weit verbreitet verfügbar. SaaS-Lösungen können auch nur als Application Programming Interfaces (APIs) angeboten werden, die von Kunden genutzt werden können, um ihre Dienste und Anwendungen zu erweitern. In einem SaaS-Umfeld wird alles vom Dienstanbieter verwaltet, die einzige Verantwortung des Kunden besteht in der Verwaltung von Authentifizierungsinformationen und benutzergenerierten Daten (z. B. Metadaten oder Anwendungsdaten). Die meisten modernen SaaS-Lösungen sind auch in der Lage, externe Identitätsanbieter wie Google, Microsoft, Meta usw. zu integrieren, um den Kunden integrierte Anmeldeoptionen zu bieten, die auch als Single Sign-On (SSO) bezeichnet werden. Dies ist ein Sicherheitsvorteil für SaaS-Anbieter, da sie keine Benutzerdaten speichern müssen. Typische SaaS-Lösungen sind Microsoft 365, Netflix, Spotify usw., die weltweit entweder von Unternehmen oder normalen Kunden genutzt werden. Im Allgemeinen bieten viele Softwareunternehmen ihre Dienste als SaaS-Lösungen für ihre Kunden an.

Platform-as-a-Service (PaaS)

Eine PaaS-Lösung ist eine Umgebung, in der Kunden in der Lage sind, einen bestimmten „Dienst“ wie einen On-Demand-Webserver oder eine vollständig verwaltete Datenbank bereitzustellen, ohne das zugrunde liegende Betriebssystem betreiben und unterstützen zu müssen. Daher sind die Anbieter, die PaaS-Lösungen anbieten, für das zugrunde liegende System verantwortlich, und die Benutzer konsumieren nur einen Dienst, den sie nach Belieben anpassen können. Dieses Konzept ist besonders beliebt für Systeme, die viele Patches und Wartung erfordern. Das am weitesten verbreitete Geschäftsmodell besteht darin, dass Anbieter eine Art von Managed Service anbieten, der sich auf Support und Service Level Agreements (SLAs) bezieht. Ein Beispiel ist eine Database-as-a-Service, bei der die Datenbank die Plattform ist, die vom Kunden konfiguriert und genutzt werden kann, während der Dienstanbieter alles rund um die Betriebszeit, das Patchen, das Clustering, die Sicherheit usw. verwaltet.

Infrastructure-as-a-Service (IaaS)

Eine IaaS-Umgebung ist ein Dienstmodell, das viele Arten von IT-Infrastrukturen anbietet. Daher liegt auch die größte Verantwortung beim Kunden. IaaS kann mit einer klassischen Virtualisierungsumgebung verglichen werden, in der Kunden in der Lage sind, VMs auf einem Hypervisor bereitzustellen und mit ihrem gewünschten Betriebssystem ihre Infrastruktur aufzubauen. Insbesondere in einer öffentlichen Cloud-Umgebung können Benutzer viele verschiedene Arten von Infrastrukturen bereitstellen, nicht nur die traditionelle VM. Grundsätzlich kann alles, was in einem traditionellen Rechenzentrum vorhanden ist, virtuell bereitgestellt werden: Virtuelle Netzwerke, Virtual Private Network (VPN)-Gateways, Netzwerksicherheitsgruppen und viele weitere Infrastrukturelemente können bereitgestellt werden. Dies bedeutet auch, dass typische Netzwerk-Infrastrukturen wie Router, Switches, Loadbalancer und Firewalls bereitgestellt werden können. Diese ganze Flexibilität bringt jedoch auch viel Aufwand mit sich. Jedes Infrastrukturelement muss betrieben, gewartet, gesichert und bei Bedarf gepatcht werden. Dies kann zu einer erheblichen Arbeitsbelastung führen, und In-Place-Upgrades werden für Cloud-Infrastrukturen oft nicht unterstützt, da die Infrastruktur auf einer Art Basis-Image beruht, das nicht leicht geändert werden kann. Anstatt die Infrastruktur inline zu aktualisieren, besteht auch die Möglichkeit, das Basis-Image der Infrastruktur zu ändern. Dies ist nur möglich, wenn die Infrastrukturkonfiguration nicht manuell erfolgt, sondern an einem anderen Ort gespeichert wird. Beispielsweise wird anstatt einer Aktualisierung einer VM eine neue VM mit dem neuesten Basis-Image und anderen anwendbaren Änderungen bereitgestellt und die alte später entfernt. Dieser Ansatz mag zunächst wie eine Verschwendung von Ressourcen erscheinen, doch mit einem aktuellen Werkzeug namens Infrastructure as Code (IaC), bei dem es sich um einen Bauplan der gesamten Infrastrukturkonfiguration handelt, kann der Upgrade-Prozess einer VM in weniger als einer Minute abgeschlossen werden.

IaaS ist die Grundlage für diese drei Diensttypen, die aufeinander aufbauen. Das bedeutet, dass ein PaaS-Dienstmodell auf einem IaaS-Modell aufgebaut werden kann und ein SaaS entweder auf einem IaaS- oder einem PaaS-Modell aufgebaut werden kann.

IaaS-PaaS-Saas Aktöre, Komponenten und Kundenkontrolle veranschaulicht

Diese Abbildung zeigt, wie die verschiedenen Cloud Service Models aufeinander aufbauen. Drei Aspekte jedes Dienstmodells werden dargestellt: die Akteure, die Komponenten, die ein Kunde nutzen kann, und das Maß an Kontrolle, das der Kunde hat. Das IaaS-Dienstmodell wird von Akteuren wie Netzwerkarchitekten und DevOps-Ingenieuren verwaltet. Sie sind verantwortlich für die bereitgestellte Infrastruktur wie VPN-Gateways, Netzwerke, Speichersysteme und virtuelle Maschinen. Auf der IaaS-Ebene pflegen Softwareentwickler und auch DevOps-Ingenieure normalerweise die PaaS-Schicht. Die Akteure dieser Schicht sind also dafür verantwortlich, die Datenbanken, Webserver und Webanwendungen zu betreiben und zu patchen, die auf den Servern laufen. Ein PaaS-Kunde nutzt folglich nur einen Dienst (z. B. eine von den Akteuren gepflegte Datenbank). SaaS ist in der Regel das Softwareprodukt oder der Dienst, der auf einer PaaS-Schicht läuft. Das bedeutet beispielsweise eine API oder Webanwendung, die über einen von den PaaS-Akteuren verwalteten Webserver zugänglich ist.

Es kann gesagt werden, dass es kein Softwareangebot (SaaS) ohne eine zugrunde liegende Plattform (PaaS) geben kann, auf der die Software läuft. Darüber hinaus kann eine Plattform nur auf Infrastruktur (IaaS-Komponenten) betrieben werden, die in einer öffentlichen Cloud bereitgestellt werden kann. CSPs (Cloud-Service-Provider) bieten in der Regel zwei der drei wichtigsten Dienstmodelle standardmäßig an. Diese sind IaaS (VMs usw.) und PaaS (verwaltete Dienste wie Datenbanken usw.). SaaS-Lösungen werden typischerweise nicht von CSPs bereitgestellt, sondern eher von Drittanbietern, die auf einen CSP hinter ihrem Dienst angewiesen sind.

Erweiterte Service Modelle

Laut der NIST-Definition von 2011 sind dies die wichtigsten Dienstmodelle. Heute ist diese Definition nicht mehr vollständig zutreffend, da aus diesen drei Modellen viele weitere *aaS-Dienstmodelle entstanden sind. Beispiele hierfür wären Artificial Intelligence-as-a-Service (AIaaS – zum Beispiel ChatGPT von OpenAI), Desktop-as-a-Service (DaaS – zum Beispiel eine Azure Virtual Desktop-Umgebung), Monitoring-as-a-Service (MaaS – zum Beispiel Software von Elastic NV) und viele mehr. All diese Dienstmodelle basieren in gewisser Weise auf den drei grundlegenden Dienstmodellen – die Basismodelle werden nur um einige Erweiterungen ergänzt und neue *aaS-Modelle werden veröffentlicht [4].

Neben den zahlreichen neuen Dienstmodellen stechen zwei hervor, da sie von Cloud-Ingenieuren umfassend genutzt werden: [8]

• Container-as-a-Service (CaaS) Das CaaS-Dienstmodell ermöglicht es den Kunden, Container bereitzustellen, die auf containerd oder einer anderen Container-Laufzeit in der öffentlichen Cloud ausgeführt werden. Dieses Dienstmodell wird häufig mit einem Container-Orchestrierungssystem wie Kubernetes oder Openshift und einer Container-Registry kombiniert, die oft von einem CSP bereitgestellt wird. Eine Container-Orchestrierung ermöglicht die Automatisierung der Bereitstellung und Verwaltung von Containern, während eine Container-Registry die Images speichert, die als Container bereitgestellt werden.

• Function-as-a-Service (FaaS) Das FaaS-Dienstmodell ist ebenfalls ein wesentlicher Bestandteil des Angebots jedes CSPs. Es ermöglicht den Kunden, Quellcode – sogenannte Funktionen – in der Cloud auszuführen. Das bedeutet, dass Kunden Code ausführen können, der beispielsweise eine E-Mail sendet, ohne ein Betriebssystem betreiben zu müssen, das den Code ausführt. Der Kunde zahlt also nur für die Rechenleistung, die zur Ausführung der Funktion benötigt wird.

Zusätzlich zu den drei wichtigsten Dienstmodellen sind diese beiden ebenfalls wesentlich und werden häufig von Unternehmen genutzt.

Cloud Computing Deployment Models

Cloud Computing Deployment Models definieren, wie Cloud-Infrastrukturen aufgebaut und genutzt werden. Diese Modelle bestimmen, wer Zugriff auf die Cloud-Ressourcen hat, wie diese verwaltet werden, und welche Vor- und Nachteile mit ihrer Nutzung verbunden sind. Es gibt mehrere etablierte Deployment-Modelle, die jeweils für unterschiedliche Anwendungsfälle geeignet sind. NIST in ihrem Standard spricht von 4 Bereitstellungsmodellen.

Diese Deployment-Modelle bieten Unternehmen unterschiedliche Möglichkeiten, Cloud-Technologien zu nutzen, je nach ihren spezifischen Anforderungen und Zielen. Jede Option bringt ihre eigenen Vor- und Nachteile mit sich, und die Wahl des richtigen Modells hängt von den individuellen Bedürfnissen des Unternehmens ab.

Im Folgenden werden die wichtigsten Deployment-Modelle vorgestellt: Private Cloud, Public Cloud, Hybrid Cloud, Community Cloud und Multi Cloud (Nicht im NIST Cloud Computing Standard enthalten, da sich diese Art erst über die Jahre „gebildet“ hat).

Private Cloud

Eine Private Cloud ist eine Cloud-Computing-Umgebung, die ausschließlich von einem einzigen Unternehmen genutzt wird. Die Ressourcen der Private Cloud werden entweder intern von der IT-Abteilung des Unternehmens oder durch einen externen Dienstleister betrieben, wobei die Infrastruktur vollständig auf die Bedürfnisse des Unternehmens zugeschnitten ist. Eine Private Cloud bietet ein hohes Maß an Sicherheit und Kontrolle, da das Unternehmen direkten Zugriff auf die Hardware und Software hat, die für die Bereitstellung der Cloud-Dienste verwendet werden.

Vorteile:

• Hohe Sicherheit und Kontrolle: Da die Infrastruktur isoliert ist, bietet die Private Cloud eine höhere Datensicherheit und ermöglicht die Einhaltung spezifischer Compliance-Anforderungen.
• Anpassbarkeit: Die Infrastruktur kann speziell an die Anforderungen des Unternehmens angepasst werden, was eine flexible und maßgeschneiderte Lösung ermöglicht.

Nachteile:

• Hohe Kosten: Die Implementierung und Wartung einer Private Cloud erfordert erhebliche Investitionen in Hardware, Software und Fachpersonal.
• Wartungsaufwand: Das Unternehmen ist für die gesamte Verwaltung und Wartung der Infrastruktur verantwortlich, was zusätzlichen Aufwand bedeutet.

Beispiel

Private Cloud illustriert

Public Cloud

Eine Public Cloud ist ein Cloud-Computing-Modell, bei dem Cloud-Dienste über das Internet von einem Cloud-Service-Provider (CSP) bereitgestellt werden. Diese Dienste stehen der Öffentlichkeit zur Verfügung, und die Ressourcen werden gemeinsam von mehreren Nutzern verwendet. Die Public Cloud ist in der Regel kostengünstiger, da die Kosten für Hardware und Wartung auf mehrere Nutzer verteilt werden.

Vorteile:

• Kosteneffizienz: Die Nutzung der Public Cloud ist meist günstiger, da keine eigenen Investitionen in Hardware erforderlich sind und die Kosten für Wartung und Betrieb vom CSP übernommen werden.
• Skalierbarkeit: Ressourcen können je nach Bedarf schnell und einfach skaliert werden, um den Anforderungen des Unternehmens gerecht zu werden.

Nachteile:

• Sicherheitsbedenken: Da die Ressourcen gemeinsam genutzt werden, können Sicherheitsrisiken höher sein, insbesondere wenn sensible Daten in der Cloud gespeichert werden.
• Abhängigkeit vom Anbieter: Unternehmen sind stark auf den CSP angewiesen, was zu einem Vendor-Lock-in führen kann.

Beispiel

Illustration einer Public Cloud

Hybrid Cloud

Die Hybrid Cloud kombiniert Elemente der Private und Public Cloud, indem sie Daten und Anwendungen über beide Umgebungen hinweg integriert. Unternehmen können sensible Daten in der Private Cloud speichern, während weniger kritische Anwendungen in der Public Cloud gehostet werden. Diese Kombination bietet eine Balance zwischen Sicherheit, Flexibilität und Kosteneffizienz.

Vorteile:

• Flexibilität: Unternehmen können Workloads zwischen Public und Private Clouds verlagern, je nach Sicherheitsanforderungen und Kostenüberlegungen.
• Optimierte Ressourcen-Nutzung: Kritische Anwendungen können in einer sicheren Private Cloud laufen, während Public Clouds für weniger kritische Aufgaben genutzt werden.

Nachteile:

• Komplexität: Die Verwaltung einer Hybrid Cloud erfordert eine umfassende Strategie, um die Interoperabilität zwischen den verschiedenen Umgebungen zu gewährleisten.
• Kosten: Die Implementierung einer Hybrid Cloud kann teurer sein als die ausschließliche Nutzung einer Public oder Private Cloud.

Beispiel

Hybrid Cloud Beispiel 1

Hybrid Cloud Beispiel 2

Community Cloud

Eine Community Cloud ist eine spezielle Art von Cloud-Infrastruktur, die von mehreren Organisationen gemeinsam genutzt wird, die ähnliche Anforderungen haben, beispielsweise hinsichtlich Sicherheit, Compliance oder spezifischen Geschäftsanforderungen. Die Infrastruktur kann intern verwaltet oder von einem Drittanbieter betrieben werden, wobei die Kosten und Ressourcen zwischen den beteiligten Organisationen aufgeteilt werden.

Vorteile:

• Geteilte Kosten: Die beteiligten Organisationen teilen sich die Kosten für die Infrastruktur, was die Kosten für jeden Einzelnen reduziert.
• Gemeinsame Compliance: Die Cloud kann speziell an die gemeinsamen Compliance- und Sicherheitsanforderungen der beteiligten Organisationen angepasst werden.

Nachteile:

• Beschränkte Anpassungsmöglichkeiten: Da die Cloud von mehreren Organisationen genutzt wird, sind die Anpassungsmöglichkeiten eingeschränkt.
• Komplexe Verwaltung: Die Verwaltung der Cloud erfordert eine enge Zusammenarbeit zwischen den beteiligten Organisationen, was zu administrativen Herausforderungen führen kann.

Beispiel

Community Cloud illustriert

Multi Cloud

Das Multi-Cloud-Modell bezieht sich auf die Nutzung mehrerer Cloud-Dienste von verschiedenen Anbietern. Unternehmen nutzen mehrere Cloud-Plattformen, um von den jeweiligen Stärken und Funktionen der verschiedenen Anbieter zu profitieren und Abhängigkeiten von einem einzelnen CSP zu vermeiden.

Vorteile:

• Vermeidung von Vendor-Lock-in: Durch die Nutzung mehrerer Anbieter vermeiden Unternehmen die Abhängigkeit von einem einzigen CSP.
• Optimale Nutzung: Unternehmen können die besten Dienste verschiedener Anbieter kombinieren, um ihre spezifischen Anforderungen optimal zu erfüllen.

Nachteile:

• Komplexität: Die Verwaltung einer Multi-Cloud-Umgebung kann komplex und anspruchsvoll sein, insbesondere hinsichtlich der Integration und Datensicherheit.
• Kosten: Obwohl eine Multi-Cloud-Strategie Flexibilität bietet, können die Gesamtkosten durch die Nutzung mehrerer Anbieter steigen.

Beispiel

Multi Cloud Illustriert

Shared Responsibility Model

Das Shared Responsibility Model ist ein essenzielles Konzept im Cloud Computing, das die Aufteilung der Verantwortlichkeiten zwischen Cloud Service Providern (CSPs) und Cloud Service Kunden (CSCs) beschreibt. Dieses Modell dient als Grundlage dafür, wie Infrastruktur- und Sicherheitsaufgaben in einer Cloud-Umgebung gemeinsam verwaltet werden, und verdeutlicht, welche Aufgaben vom CSP übernommen werden und welche in der Verantwortung des Kunden liegen. Es fungiert als eine Art Verantwortungsmatrix, die je nach gewähltem Cloud-Anbieter, den genutzten Produkten, den Service-Modellen und den Bereitstellungsmodellen variiert.

Das Shared Responsibility Model bildet das Fundament dafür, wie ein CSP agiert und seine Dienste bereitstellt, unabhängig davon, ob es sich um eine private, öffentliche, hybride oder Multi-Cloud-Umgebung handelt. Je nach verwendetem Cloud-Service-Modell – sei es Infrastructure as a Service (IaaS), Platform as a Service (PaaS) oder Software as a Service (SaaS) – müssen sich die Kunden darüber im Klaren sein, welche Verantwortlichkeiten in den Händen des CSP liegen und welche Aufgaben sie selbst übernehmen müssen. So bestimmt das Modell nicht nur die Effizienz und Sicherheit der Cloud-Nutzung, sondern auch die Art und Weise, wie Unternehmen ihre internen IT-Ressourcen und -Prozesse organisieren und verwalten.

Das Shared Responsibility Model variiert je nach gewähltem CSP. Im Allgemeinen umfassen sie drei Service-Modelle sowie einen Vergleich mit einem standardmäßigen Rechenzentrum. Dies wird erreicht, indem jede Komponente, die zur Bereitstellung einer Anwendung oder eines Dienstes erforderlich ist (z. B. ein physischer Server), untersucht und anschließend die Pflichten des CSP und des CSC basierend auf dem jeweiligen Service-Modell aufgezeigt werden.

Eine erweiterete Version des Shared Responsibility Models (inkl. CaaS und FaaS) sieht wie folgt aus:

Erweitertes Shared Responsibility Model anhand von Cloud computing security: Foundations and challenges [9]

Das Shared Responsibility Model besteht aus neun Schichten, von denen jede einen anderen Aspekt repräsentiert, der benötigt wird, um einen Dienst für Endbenutzer in der Cloud bereitzustellen. Diese Schichten bauen aufeinander auf und würden ohne die darunterliegenden Schichten nicht funktionieren. Daher hat jedes Servicemodell unterschiedliche Anforderungen an den CSP. Dieses Modell verdeutlicht auch, dass die Bereitstellung einer IaaS-Lösung für Endverbraucher auf vielen zugrunde liegenden Komponenten und Fachwissen beruht, die benötigt werden, um die ersten vier Schichten bereitzustellen. Die Schichten und ihre Funktionen von unten nach oben sind die folgenden:

Physisches Rechenzentrum

Das physische Rechenzentrum ist der Standort Ihrer Rechen-, Speicher- und Netzwerkkomponenten. Beim Bau eines Rechenzentrums müssen viele Aspekte berücksichtigt werden (z. B. physisches Design, Umweltgestaltung usw.), die alle in der ISO/IEC 22237 aufgeführt sind. Dieser Standard berücksichtigt alle Rechenzentren, auch solche, die vollständig privat sind. Betrachtet man das physische Rechenzentrum eines öffentlichen Cloud-Service-Providers, ist es unmöglich, nur ein einziges Rechenzentrum zu betrachten. Öffentliche Cloud-Anbieter verfügen über Rechenzentren auf der ganzen Welt in sogenannten Regionen, die in Verfügbarkeitszonen unterteilt sind. Eine Region könnte beispielsweise als „Europa-Nord (Irland/Dublin)“ definiert sein. Diese Regionen bestehen in der Regel aus mindestens zwei Verfügbarkeitszonen. Eine Verfügbarkeitszone selbst ist ein realer physischer Rechenzentrumsstandort. Daher ist ein CSP mit fünf Regionen, die jeweils drei Verfügbarkeitszonen haben, für insgesamt 15 physische Rechenzentren verantwortlich und für deren Verfügbarkeit und Funktionsfähigkeit zuständig.

Netzwerk und Speicher

Netzwerk- und Speicherkomponenten sind zwei der drei Kernkomponenten des Cloud-Computing (Netzwerk, Speicher und Rechenleistung). Betrachtet man die Netzwerkkonfiguration eines Rechenzentrums, so müssen der Betrieb von Datacenter-Switches, Loadbalancern, Firewalls und Core-Routern für mehrere öffentliche Internetverbindungen berücksichtigt werden. Diese Netzwerkkomponenten müssen jederzeit in einer hochverfügbaren und fehlertoleranten Umgebung betrieben werden.

Ein Rechenzentrum enthält oft viele Speicherkomponenten, die für verschiedene Zwecke verwendet werden. Diese Speicherkomponenten werden in drei Typen unterteilt:

• Direct Attached Storage (DAS) Dieser Speichertyp wird nicht für große Datenmengen verwendet. Er wird üblicherweise nur für das Betriebssystem der physischen Server und anderer Geräte wie Firewalls und Loadbalancer verwendet. Dieses direkt angeschlossene Speichersystem ist in der Regel als RAID 1 für Server konfiguriert, die als Typ-1-Hypervisor, Firewalls und Loadbalancer fungieren. Eine gespiegelte Festplatte ist in diesem Szenario sinnvoll, da diese Betriebssysteme nicht viel Speicher benötigen und fehlertolerant sein müssen.
• Network Attached Storage (NAS) Ein netzwerkgebundenes Speichersystem ist in einem Rechenzentrum häufiger anzutreffen. Es fasst viel Speicherplatz auf mehreren Speicherknoten zusammen, die über mehrere Netzwerkprotokolle zugänglich sind. NAS-Systeme und deren Speicher nutzen auch RAID-Mechanismen, um ein fehlertolerantes System bereitzustellen. Um auf ein NAS zuzugreifen, muss es auf einem Netzwerk-Laufwerk oder einem Netzwerk-Standort des Betriebssystems eingebunden werden. NAS-Systeme haben jedoch Einschränkungen, da sie auf dem zugrunde liegenden Netzwerk basieren und das Netzwerk möglicherweise nicht in der Lage ist, große Datenmengen zu übertragen.
• Storage Area Network (SAN) Ein Storage Area Network ist ein separates Netzwerk, das von normalen TCP/IP-Netzwerken getrennt ist. Es verwendet spezielle Hardware (Switches und Speicherknoten), die für hohe Datenraten im Netzwerk optimiert sind. Es fasst im Wesentlichen viele Speicherknoten in einem separaten Netzwerk zusammen und stellt den Speicher über eine Schnittstelle für andere Dienste bereit. Aus der Sicht eines Servers, der Speicher von einem SAN nutzt, sieht es so aus, als hätte der Server Zugriff auf eine physische Festplatte, die tatsächlich vom SAN bereitgestellt wird.

Diese Netzwerk- und Speicherkomponenten müssen vom Rechenzentrumsbetreiber ordnungsgemäß gewartet und gesichert werden, damit die Komponenten im Katastrophenfall wiederhergestellt werden können.

Physischer Server

Physische Server liegen über den Netzwerk- und Speicherkomponenten und bilden den Rechenteil eines Rechenzentrums. Diese Server sind normalerweise für den 24/7-Betrieb ausgelegt und in verschiedenen Formfaktoren erhältlich. Der gängigste Formfaktor ist der Rackmount-Server. Diese verfügen über spezielle Mainboards, die den Einbau mehrerer CPUs und RAM-Sticks ermöglichen.

Virtualisierung

Virtualisierung ist eine wichtige Funktion in Rechenzentren. Sie ermöglicht eine bessere Auslastung der physischen Server, sodass diese nicht nur mit einer CPU-Auslastung von 10 % und nahezu ungenutztem RAM betrieben werden. Um Virtualisierung zu ermöglichen, wird ein Hypervisor benötigt. In Unternehmensumgebungen wird in der Regel ein Typ-1-Hypervisor verwendet. Ein Typ-1-Hypervisor ist eine Softwareebene, die auf einem physischen Server und dessen zugrunde liegender Hardware bereitgestellt wird. Es wird auch als Bare-Metal-Hypervisor bezeichnet, da keine zusätzliche Software zwischen der Hardware und dem Hypervisor ausgeführt wird. Der Hypervisor ermöglicht es den VMs, Netzwerken und anderen virtualisierten Komponenten, die darauf ausgeführt werden, mit der zugrunde liegenden Hardware zu kommunizieren. Er ist auch dafür verantwortlich, den virtualisierten Komponenten die Möglichkeit zu bieten, mit den Speicher- und Netzwerkkomponenten des Rechenzentrums zu kommunizieren.

Betriebssystem

Die gängigsten Betriebssysteme in einem Rechenzentrum sind Linux-basierte Systeme und Windows-Systeme. Ein virtualisiertes Betriebssystem wird auch als Gastbetriebssystem bezeichnet. Linux wird für die meisten Server verwendet, die in der Regel Webserver, Datenbanken oder andere Anwendungen hosten. Windows-Server werden für Unternehmensanwendungen wie Active Directory oder Exchange-Dienste verwendet. Administratoren neigen auch dazu, einen Hypervisor auf einem normalen Linux-Server zu installieren, um noch mehr aus einer einzelnen VM herauszuholen. Dies wird als geschachtelte Virtualisierung bezeichnet und ermöglicht eine weitere Segmentierung auf einem einzelnen Gastbetriebssystem.

Middleware

Die Middleware wird nicht für jede Anwendung benötigt, aber für einige ist sie unerlässlich. Es ist eine Orchestration-Schicht, die zwischen den Anwendungen und dem zugrunde liegenden Betriebssystem liegt. Ein häufiger Anwendungsfall ist beispielsweise eine PaaS-Hochverfügbarkeits-Datenbanklösung, die dem CSC einen einzelnen Datenbankendpunkt zur Verfügung stellt, während im Hintergrund viele Instanzen ausgeführt werden. Die Koordination der Interaktionen zwischen verschiedenen Datenbankinstanzen liegt in der Verantwortung der Middleware. Bei der Verwendung von Containern wird ebenfalls eine Middleware genutzt. Dies gilt sowohl für die direkte Bereitstellung einzelner Container in der Cloud (über den Container-Service eines CSP) als auch für die Bereitstellung mehrerer Container über ein Orchestration-Tool wie Kubernetes (die meisten CSPs bieten ihren Kunden einen verwalteten Kubernetes-Service an).

Runtime

Die Runtime ist in der Regel ein Softwarepaket (Anwendung + Bibliotheken + Umgebung), das im Hintergrund läuft, um die zugrunde liegenden Funktionen für die Anwendungen der Endbenutzer bereitzustellen. Typische Software, die als Runtime-Umgebung betrachtet werden kann, ist ein Webserver. Ein Webserver muss jedoch immer auf dem neuesten Stand sein und über die richtigen Funktionen für die Anwendung des Endbenutzers verfügen. Beispiele hierfür wären ein NGINX- oder ein Apache-Webserver, die in der Lage sind, TLS-Terminierung durchzuführen, um einen sicheren Datenaustausch zwischen Clients und Servern zu ermöglichen. Das Einrichten der Runtime auf eine ordnungsgemäße und skalierbare Weise erfordert viel Fachwissen, das Entwickler, die nur eine Webanwendung erstellen, in der Regel auslagern – entweder an den CSP oder an ein IT-Betriebsteam. CSPs bieten Runtime-Lösungen als PaaS-Angebote an und haben eine breite Palette von Managed Services, einschließlich Webservern und Datenbanken.

Datenbank

Daten werden in der Regel in verschiedenen Arten von Datenbanken gespeichert, entweder in SQL- oder NoSQL-Datenbanken. Der Kontext für die Geschäftslogik der Anwendungen, die in einer Cloud-Umgebung ausgeführt werden, wird durch die in den Datenbanken gespeicherten Daten bereitgestellt. Daten werden jedoch nicht immer in strukturierter Form wie in Datenbanken gespeichert. Einige Anwendungen müssen andere Arten von Daten speichern oder darauf zugreifen. CSPs bieten Objektspeicher an, die Daten in unstrukturierter Form als Objekte speichern. Daten aus Objektspeichern können über eine API abgerufen und ähnlich wie ein Objekt aus einer objektorientierten Programmiersprache behandelt werden. Eine Kombination aus vielen verschiedenen Datenquellen in einer Cloud (Datenbanken und Objektspeicher) wird als Data Lake bezeichnet. Ein Data Lake hat die Eigenschaft, verschiedene Datenquellen zu konsolidieren. Dies bildet die Grundlage für Anwendungen im Bereich des maschinellen Lernens und der Geschäftsanalyse.

Anwendung

Das Programm, auf das Endbenutzer zugreifen können, wird als Anwendung bezeichnet. Gängige Anwendungen umfassen Webanwendungen, Streaming-Endpunkte, API-Endpunkte und mehr. Um auf einen Cloud-Dienst zuzugreifen, benötigt der Endbenutzer lediglich eine Anwendung für sein Endgerät (Smartphone, Notebook usw.) oder einen Internetbrowser. Anwendungen sind auf alle zugrunde liegenden Komponenten des Shared Responsibility Models angewiesen.

Allgemeines zum Shared Responsibility Model

Wie in der Grafik von Vacca hervorgehoben, verschieben sich die Verantwortlichkeiten des CSC je nach gewähltem Servicemodell. Daher sollte das Servicemodell immer in Übereinstimmung mit dem Fachwissen und den Fähigkeiten des CSC ausgewählt werden. Es macht wenig Sinn, ein IaaS-Modell zu wählen, wenn kein Wissen über den Betrieb, die Unterstützung, das Patchen, das Monitoring und die Sicherung des gewählten Betriebssystems sowie der darüber liegenden Middleware, Laufzeit, Datenbank und Anwendung vorhanden ist.