Cloud-Computing-Konzepte

Cloud Computing ermöglicht Menschen den Zugriff auf Rechenressourcen über ein Netzwerk, wenn sie diese benötigen. Dazu gehören Rechenleistung, Speicher, Datenbanken, Netzwerke und vollständige Anwendungen. Sie stammen aus einem gemeinsamen Pool und lassen sich schnell bereitstellen und zurückgeben, ohne viel mit Mitarbeitern des Anbieters interagieren zu müssen.

Vom Gerätekauf zur Kapazitätsanforderung

Ein Cloud-Anbieter stellt Dienste bereit; ein Kunde nutzt sie. AWS, Microsoft Azure und Google Cloud sind große Public-Cloud-Anbieter. Eine Ressource zu provisionieren bedeutet, sie zur Nutzung bereitzustellen. Sie freizugeben bedeutet, sie zurückzugeben. Eine Workload umfasst die Anwendung oder den Prozess, die zugehörigen Daten und die für den Betrieb benötigten Ressourcen.

Bei einer Public Cloud besitzt und wartet der Anbieter die physischen Geräte. Kunden beziehen die benötigten Dienste und bezahlen nach dem Preismodell des jeweiligen Dienstes. Eine Organisation kann auch ihre eigene Private Cloud betreiben. Ihre Abteilungen beziehen weiterhin Ressourcen aus einem gemeinsamen Pool, und das System misst ihre Nutzung, auch wenn kein externer Anbieter eine Rechnung stellt.

Vergleiche die Betriebsarten für einen Webshop

Bei On-Premises-IT kauft ein Unternehmen einen Server für sein eigenes Gebäude. Mitarbeiter wählen die Hardware, warten auf die Lieferung, installieren ein Betriebssystem, schließen das Netzwerk an und installieren dann den Shop. Das Unternehmen kümmert sich auch um Strom, Kühlung, Reparaturen und den späteren Ersatz. Es muss die Kapazität planen, bevor die Verkaufszahlen zeigen, wie viel benötigt wird.

Bei einer Cloud-VM wählt ein Mitarbeiter in einer Webkonsole Größe und Standort aus. Der Server kann innerhalb weniger Minuten bereit sein. Endet das Experiment nach einem Monat, löscht der Mitarbeiter die VM. Ihre Rechenkosten entfallen, separat aufbewahrter Speicher oder andere Ressourcen können aber weiterhin Geld kosten.

Colocation verändert den Standort eigener Server; sie verändert für sich genommen nicht die Art ihrer Provisionierung. Ebenso kann ein gemieteter Server, der über das Internet erreichbar ist, traditionelles Hosting sein. Netzwerkzugang allein ist nur ein Teil des Cloud-Modells.

Drei getrennte Fragen

Die NIST-Definition unterscheidet wesentliche Merkmale, Dienstmodelle und Bereitstellungsmodelle. Die Merkmale fragen: „Funktioniert der Dienst als Cloud?“ Das Dienstmodell fragt: „Welche Schichten verwaltet der Anbieter?“ Das Bereitstellungsmodell fragt: „Für wen ist die Infrastruktur bestimmt?“ Eine Private Cloud kann IaaS und eine Public Cloud SaaS bereitstellen.

Cloud-Daten haben einen physischen Ort auf Speichergeräten in Rechenzentren. Kunden wählen häufig eine Region, auch wenn sie gewöhnlich keinen einzelnen Datenträger oder Host auswählen. „In der Cloud“ beschreibt die Art der Bereitstellung und nicht Daten ohne Standort.

NIST SP 800-145 beschreibt fünf wesentliche Merkmale von Cloud Computing. Jedes beantwortet eine andere praktische Frage zur Beschaffung und Nutzung von Ressourcen. Ein Dienst benötigt die vollständige Kombination; ein großer Serverpool oder eine Onlinebestellseite allein reicht nicht aus.

Die fünf Merkmale

1. Bedarfsgerechte Selbstbedienung: Kunden erstellen Ressourcen bei Bedarf jederzeit selbst. Eine Entwicklerin kann um 2 Uhr über eine Konsole oder API ein Volume mit 100 GB provisionieren, ohne auf einen Mitarbeiter des Anbieters zu warten. Eine API ist eine Schnittstelle, über die Software Anfragen an ein anderes System stellen kann.
2. Breiter Netzwerkzugang: Standardisierte Netzwerkverfahren machen Dienste auf unterschiedlichen Geräten verfügbar. Mitarbeiter könnten denselben Dienst über einen Laptopbrowser, eine Smartphone-App oder Software nutzen, die eine HTTPS-API aufruft. Der Zugriff kann weiterhin eine Authentifizierung und eine private Netzwerkverbindung erfordern.
3. Ressourcenbündelung: Der Anbieter weist Rechenleistung, Arbeitsspeicher, Speicherplatz und Netzwerkkapazität Kunden zu und verteilt sie neu. Jeder Kunde ist ein Mandant. Logische Trennung schützt die Mandanten, während physische Ressourcen gemeinsam genutzt werden. Kunden können häufig eine Region wählen, ohne den genauen beteiligten Server zu kennen.
4. Schnelle Elastizität: Die Kapazität kann mit der Nachfrage schnell wachsen und schrumpfen. Eine Videoplattform könnte normalerweise 4 Server nutzen, für ein Live-Finale 40 und danach wieder 4. Häufig führt Automatisierung diese Änderungen durch, die Definition erlaubt aber auch schnelle, von einer Person angestoßene Änderungen.
5. Messbarer Dienst: Das System erfasst die Nutzung in geeigneten Einheiten, etwa Rechensekunden, GB Speicher oder aktiven Konten. Anbieter und Kunde können den Verbrauch überwachen, steuern und ausweisen.

Wende die Prüfmerkmale auf zwei Dienste an

Ein Unternehmen mietet einen dedizierten Server, nachdem es ein Vertriebsformular ausgefüllt hat. Die Lieferung dauert drei Tage, und für eine Aufrüstung ist ein neuer Vertrag nötig. Es zahlt jeden Monat 200 US-Dollar. Die Wartezeit schließt bedarfsgerechte Selbstbedienung aus, und dem Aufrüstungsprozess fehlt schnelle Elastizität. Die dedizierten Geräte werden nicht aus einem gemeinsamen Pool bezogen. Diese Beobachtungen weisen auf traditionelles Hosting hin.

Die feste Monatsgebühr beantwortet die Frage nach der Messung nicht. Der Anbieter könnte trotzdem Prozessorzeit oder Netzwerknutzung erfassen. Messung und Abrechnung sind verschieden: Die Messung erfasst den Verbrauch; eine Preisregel macht aus einer Messgröße eine Gebühr.

Betrachte nun einen E-Mail-Dienst. Ein Administrator kann Postfächer sofort hinzufügen oder entfernen, Nutzer verbinden sich mit unterschiedlichen Geräten, gebündelte Infrastruktur bedient viele Organisationen, die Kapazität ändert sich mit der Nachfrage nach Konten und der Dienst weist aktive Nutzer aus. Diese Kombination erfüllt die fünf Merkmale, auch wenn die Rechnung ein monatliches Abonnement ausweist.

Erkenne eine teilweise Übereinstimmung

Eine IT-Abteilung kann viele VMs betreiben, während Mitarbeiter tagelang warten, bis jede Anfrage genehmigt und die VM manuell erstellt wird. Virtualisierung hilft bei der Bündelung, aber diesem Prozess fehlt die Selbstbedienung. Ein zusätzliches Portal ist nur nützlich, wenn Automatisierung, schnelle Provisionierung und Nutzungsmessung es unterstützen.

Eine Private Cloud kann ihre Messung für Abteilungsberichte oder interne Verrechnungen nutzen. Ein messbarer Dienst liegt also auch ohne externe Rechnung vor. Elastizität verlangt außerdem, Kapazität zurückzugeben: Wer Spitzenkapazität dauerhaft vorhält, lässt nach sinkender Nachfrage Ressourcen ungenutzt.

Virtualisierung erstellt Softwareversionen physischer Rechenressourcen. Sie ermöglicht es, auf einem physischen Server mehrere getrennte Softwarecomputer zu betreiben. Cloud-Betreiber kombinieren dies mit Automatisierung, Selbstbedienung und Nutzungsmessung, um Kapazität schnell bereitzustellen.

Hosts, Gäste und Hypervisoren

Eine virtuelle Maschine (VM) verfügt über virtuelle Prozessoren, Arbeitsspeicher, Datenträger und Netzwerkschnittstellen. Sie führt ein eigenes Gastbetriebssystem und eigene Anwendungen aus. Der zugrunde liegende physische Computer ist der Host. Ein Hypervisor erstellt die VMs, weist physische Kapazität zu und hält Arbeitsspeicher und Speicherplatz jeder VM logisch getrennt.

Ein VM-Abbild ist ein gespeicherter Ausgangspunkt für eine virtuelle Maschine. Software kann daraus eine VM erstellen, ohne einen neuen physischen Server zu bestellen. Das Starten, Vergrößern oder Verkleinern und Löschen von VMs unterstützt schnelle Provisionierung und Elastizität. Das Virtualisierungssystem kann die Ressourcennutzung erfassen und unterstützt so die Messung. Manche Plattformen unterstützen auch Livemigration: Eine laufende VM wird zwischen Hosts verschoben, sodass die Hardwarewartung kaum oder keine Unterbrechung verursacht.

Rechne eine Konsolidierung durch

Angenommen, 12 gleich leistungsfähige physische Server haben jeweils eine durchschnittliche Prozessorauslastung von 10 %. Ihre gemeinsame durchschnittliche Last beträgt:

Das entspricht der Rechenleistung von 1,2 Servern. Werden die Workloads als VMs auf zwei gleich leistungsfähige Hosts verschoben, ergibt sich pro Host ein Durchschnitt von:

Zehn physische Maschinen können entfernt werden, wodurch Strom-, Kühlungs- und Wartungsaufwand sinken. Zuvor muss das Team auch den Prozessorbedarf bei Spitzenlast sowie den Bedarf an Arbeitsspeicher, Datenträgern und Netzwerk prüfen. Die Durchschnittsrechnung allein belegt nicht, dass zwei Hosts jede Auslastungsspitze oder den Ausfall eines Hosts bewältigen.

Ressourcen teilen, ohne Daten zu teilen

Mehrmandantenbetrieb bedeutet, dass mehrere Kunden eine Infrastruktur gemeinsam nutzen. Isolation verhindert, dass ein Mandant auf den VM-Arbeitsspeicher oder die Datenträger eines anderen zugreift. Gemeinsame physische Kapazitätsgrenzen können die Leistung dennoch beeinflussen: Ein ungewöhnlich stark ausgelasteter Mandant kann mit anderen um Kapazität konkurrieren. Das wird als Noisy-Neighbor-Effekt bezeichnet. Ressourcensteuerung begrenzt diesen Effekt. Dedizierte Hosts stellen Kunden, deren Anforderungen es verlangen, einen ganzen physischen Server bereit.

Speichervirtualisierung stellt gebündelte Datenträger als virtuelle Volumes bereit. Netzwerkvirtualisierung bietet getrennte softwaredefinierte Netzwerke über gemeinsam genutzte physische Verbindungen.

Container bündeln Anwendungen, Bibliotheken und Einstellungen und teilen sich dabei einen Betriebssystemkern. Eine VM besitzt ein vollständiges Gastbetriebssystem, ein Container nicht. Container starten meist schneller und benötigen weniger Ressourcen, während VMs eine stärkere Abgrenzung auf Betriebssystemebene bieten und unterschiedliche Gastsysteme ausführen können. Container laufen häufig innerhalb von VMs.

Eine Cloud kann auch Bare-Metal-Server per Selbstbedienung anbieten. Virtualisierung ist eine wichtige Grundlage; ob das Gesamtangebot Cloud Computing ist, bestimmen die fünf Dienstmerkmale.

Ein Dienstmodell beschreibt, was der Anbieter bereitstellt und was der Kunde verwaltet. Stell dir die Technologie als Schichten vor: physische Gebäude und Geräte, Virtualisierung, Betriebssystem, Middleware und Laufzeitumgebung, Anwendung und Daten. Eine Laufzeitumgebung ist die Softwareumgebung, die Anwendungscode ausführt, etwa Python oder Java.

Vergleiche die drei Standardmodelle

Bei On-Premises-IT verwaltet die Organisation den gesamten Stack. Von IaaS über PaaS zu SaaS übernimmt der Anbieter mehr Arbeit. Der Kunde gewinnt Komfort und gibt einen Teil der Freiheit auf, das zugrunde liegende System zu verändern.

Ein Blog, drei Betriebsarten

Ein IaaS-Kunde startet eine Linux-VM, installiert Webserver, Datenbank und Blogsoftware und wartet diese Schichten. Der Anbieter repariert weiterhin den physischen Host und wartet den Hypervisor. Patches für das Gastbetriebssystem sind Sache des Kunden.

Ein PaaS-Kunde stellt eine Bloganwendung auf einer unterstützten Plattform bereit. Der Anbieter liefert Updates für Betriebssystem und Laufzeitumgebung. Der Kunde wartet die Anwendung und muss den Updateprozess der Plattform befolgen. Bei AWS Elastic Beanstalk lassen sich verwaltete Patch- und kleinere Versionsupdates aktivieren; Kunden halten ihre Umgebungen auf unterstützten Versionen und beheben fehlgeschlagene Updates. Schalten sie verwaltete Updates ab, müssen sie diese selbst einspielen.

Ein SaaS-Kunde abonniert eine fertige Bloganwendung und beginnt zu schreiben. Der Anbieter betreibt die Anwendung, aber der Kunde steuert weiterhin, wer veröffentlichen darf und welche Inhalte geteilt werden.

Erkenne gängige Beispiele

Verwaltete Datenbanken wie Amazon RDS, Azure SQL Database und Google Cloud SQL werden im Allgemeinen als PaaS eingeordnet: Der Kunde nutzt eine Datenbank, ohne die zugrunde liegende Serverplattform zu warten.

Ordne den Dienst ein, nicht das Unternehmen, das ihn verkauft. Ein Anbieter kann alle drei Modelle anbieten, und manche Produkte verteilen die Verantwortung auf eine Weise, die zwischen den klassischen Kategorien liegt. Lies die Aufgabenverteilung des konkreten Angebots nach, wenn der Name allein nicht eindeutig ist.

Speziellere Bezeichnungen folgen derselben Idee. DBaaS bedeutet Database as a Service; FaaS bedeutet Function as a Service; XaaS ist ein weiter Begriff für beliebige Leistungen als Dienst. Unabhängig von der Bezeichnung muss weiterhin jemand für Kundendaten und Zugriffsentscheidungen verantwortlich sein.

Serverless bedeutet, dass der Kunde Code oder einen Dienst nutzt, ohne die zugehörigen Server auszuwählen, zu dimensionieren oder zu warten. Server erledigen die Arbeit weiterhin. Der Anbieter verwaltet Infrastruktur und Skalierung; die Abrechnung beruht auf dienstspezifischen Messgrößen.

Verfolge ein Ereignis durch eine Funktion

Bei Function as a Service (FaaS) lädt der Kunde eine kleine Codeeinheit hoch. Ein Ereignis löst eine Ausführung aus: eine Webanfrage, eine hochgeladene Datei, eine Nachricht in einer Warteschlange oder ein Zeitplan. Bei einem Fotodienst läuft das so ab:

1. Ein Kunde lädt ein Foto in den Speicher hoch.
2. Das Upload-Ereignis startet eine Funktion.
3. Die Funktion erstellt und speichert ein Vorschaubild.
4. Die Ausführung endet.

AWS Lambda, Azure Functions und Google Cloud Run functions sind Beispiele. Funktionen skalieren bei Inaktivität häufig auf null und rechnen nach Anfragen und Ausführungszeit ab. Serverless Computing umfasst auch Dienste wie Amazon S3, Amazon DynamoDB und Google BigQuery. Gespeicherte Daten können weiterhin Kosten verursachen, während kein Code läuft. Funktionstarife mit ständig bereiter Kapazität können auch in ruhigen Phasen Kosten verursachen.

Berechne die Rechnung für eine Funktion

Betrachte beispielhafte Preise von 0,20 US-Dollar pro Million Anfragen und 0,000017 US-Dollar pro GB-Sekunde. Jede von 3 Millionen Anfragen nutzt 0,5 GB Arbeitsspeicher für 200 Millisekunden oder 0,2 Sekunden.

Berechne zuerst die gesamte Laufzeit und dann die Nutzung aus Speicher und Zeit:

Die Rechenleistung kostet 5,10 US-Dollar und die Anfragen kosten 0,60 US-Dollar, zusammen 5,70 US-Dollar. In diesem Preisbeispiel fallen keine Mindestgebühr und keine Rechenkosten bei Inaktivität an. Eine VM für 0,05 US-Dollar pro Stunde kostet für 730 Stunden 36,50 US-Dollar.

Jede Anfrage kostet im Beispiel 0,0000019 US-Dollar. Dividiert man 36,50 US-Dollar durch diesen Betrag, erhält man etwa 19,2 Millionen Anfragen. Oberhalb dieses Volumens hat die VM einen niedrigeren ausgewiesenen Rechenpreis, sofern sie die Arbeit bewältigen kann. Für einen vollständigen Vergleich sind auch Speicher, Netzwerknutzung und Verwaltung relevant.

Verstehe die Betriebsgrenzen

Ein Kaltstart ist die Verzögerung, während der Dienst eine Ausführungsumgebung vorbereitet. Eine Funktion sollte zustandslos sein: Spätere Ausführungen dürfen nicht von Arbeitsspeicher oder lokalen Dateien früherer Ausführungen abhängen. Lege dauerhafte Daten in einer Datenbank oder einem Speicherdienst ab.

Jedes Angebot hat Ausführungsgrenzen. Standardaufrufe von AWS Lambda haben eine Höchstdauer von 15 Minuten. Einige Aufrufmodi von Lambda Managed Instances erlauben längere Laufzeiten; der jeweilige Dienstmodus bestimmt die Grenze. Lang laufende Aufgaben müssen zu den Regeln des gewählten Dienstes passen.

Serverless Computing eignet sich häufig für ungleichmäßigen Datenverkehr, Ereignisverarbeitung, kurze geplante Aufgaben und Automatisierung. Bei dauerhaft hoher Nutzung können andere Rechenlösungen günstiger sein. Auch der Bedarf an eigenen Betriebssystemeinstellungen kann eine Funktionsplattform ausschließen. Anbieterspezifische Auslöser und APIs können einen späteren Wechsel erschweren.

Serverless Computing wird häufig zu PaaS gezählt. Die verwaltete Infrastruktur verringert die Arbeit an Servern, während der Kunde weiterhin Code, Berechtigungen, Konfiguration und Daten sichert.

Beginne die Entscheidung für ein Dienstmodell bei den Anforderungen der Workload. Eine vertraute Technologie kann ungeeignet sein, wenn sie Wartungsaufwand verursacht, den das Team nicht bewältigen kann. Auch ein stark verwaltetes Produkt kann ungeeignet sein, wenn es die für die Anwendung nötige Kontrolle nimmt.

Frag, was kontrolliert werden muss

Gehe diese Fragen der Reihe nach durch:

1. Erfüllt eine fertige Anwendung den betrieblichen Bedarf? Ziehe SaaS in Betracht.
2. Stellt das Team eine eigene Anwendung in einer unterstützten Sprache bereit, ohne Kontrolle über das Betriebssystem zu benötigen? Ziehe PaaS in Betracht.
3. Sind die Aufgaben kurz, ereignisgesteuert und fallen sie in ungleichmäßiger Menge an? Ziehe Serverless-Funktionen in Betracht.
4. Muss das Team das Gastbetriebssystem kontrollieren, spezielle Software installieren oder einen Server unverändert verschieben? Ziehe IaaS in Betracht.

PaaS und Serverless Computing überschneiden sich. Wähle den konkreten Dienst, dessen Ausführungsmodell, Grenzen und unterstützte Werkzeuge zur Anwendung passen.

Ordne Anforderungen Modellen zu

Für die ältere Anwendung bietet IaaS Kontrolle über eine VM, aber keine uneingeschränkte Kontrolle über die physische Hardware des Anbieters. Kompatibilität und Support müssen weiterhin geprüft werden. Stelle bei SaaS sicher, dass die verfügbaren Funktionen und Einstellungen die Anforderungen erfüllen, bevor du dich für den Komfort entscheidest.

Beziehe Betriebsaufwand in die Kosten ein

Angenommen, eine VM kostet 40 US-Dollar pro Monat und benötigt vier Stunden Verwaltung zu 50 US-Dollar pro Stunde. Die Verwaltung kostet 200 US-Dollar, zusammen sind es also 240 US-Dollar. Ein geeigneter PaaS-Tarif kostet in diesem Beispiel 90 US-Dollar bei nahezu keinem Verwaltungsaufwand. Seine höhere Dienstgebühr geht mit niedrigeren Gesamtkosten einher.

Zum Vergleich des Aufwands gehören Patches, Überwachung, Datensicherungen, Anwendungsupdates und die Fähigkeiten, die für die Reaktion auf einen Ausfall nötig sind. Werden mehr Schichten an den Anbieter übertragen, verringert das einige dieser Aufgaben, beseitigt aber nicht die Anwendungs- oder Zugriffsverwaltung.

Kombiniere Modelle bei unterschiedlichen Aufgaben

Ein Unternehmen kann SaaS für das Kundenbeziehungsmanagement, PaaS für seine Website, Funktionen zur Verarbeitung neuer Bestellungen und eine VM für eine ältere Komponente nutzen. Jeder Dienst hat seine eigene Verwaltungsgrenze.

Auch Portabilität gehört zur Entscheidung. VMs und Container lassen sich relativ leicht verschieben, wenn ihre Abhängigkeiten portabel sind. Verwaltete Plattformen und Funktionsauslöser können Code an einen Anbieter binden. Anbieterbindung bezeichnet den zusätzlichen Aufwand und die zusätzlichen Kosten, die diese Abhängigkeit verursacht.

Eine Entscheidung kann sich mit der Zeit ändern. Das Rehosting einer Anwendung auf einer VM kann ein sinnvoller erster Schritt sein, auf den später eine Plattformmigration folgt. Der Grund für die Wahl von IaaS sollte eine aktuelle Anforderung wie Kontrolle über das Betriebssystem sein, nicht allein die Vertrautheit damit.

Ein Bereitstellungsmodell beschreibt die Nutzer, für die eine Cloud-Infrastruktur bereitgestellt wird. Ein Dienstmodell beschreibt die bereitgestellten Schichten. Das sind getrennte Entscheidungen: Eine Organisation kann virtuelle Maschinen über IaaS sowohl in einer Public als auch in einer Private Cloud beziehen.

Public Cloud

Die Infrastruktur einer Public Cloud steht der Allgemeinheit zur Nutzung offen. Sie gehört einem Anbieter und wird von ihm in seinen Rechenzentren betrieben. AWS, Microsoft Azure und Google Cloud sind Beispiele; weitere Anbieter sind Oracle Cloud, IBM Cloud und Alibaba Cloud.

Kunden teilen sich die Infrastruktur und greifen gewöhnlich über das Internet auf Dienste zu, obwohl auch privater Netzwerkzugang möglich ist. Sie vermeiden den Kauf physischer Geräte, können schnell große Mengen an Kapazität beziehen und zwischen Standorten auf der ganzen Welt wählen. Sie sind aber auch von den Dienstentscheidungen des Anbieters und der Netzwerkverbindung abhängig und haben weniger Kontrolle über die physische Hardware.

„Public“ beschreibt, wer Kunde werden kann. Es bedeutet nicht, dass jeder die Daten jedes Kunden sehen kann. Isolation und Zugriffskontrollen trennen Ressourcen. Einen Speichercontainer öffentlich lesbar zu machen ist eine Konfigurationsentscheidung und kein unvermeidbares Merkmal der Public Cloud.

Private Cloud

Eine Private Cloud ist einer Organisation vorbehalten, die viele Abteilungen umfassen kann. Die Organisation, ein Dritter oder beide können sie betreiben. Sie kann sich im Gebäude der Organisation befinden oder anderswo gehostet werden.

Eine Private Cloud bietet genauere Kontrolle über Geräte, Standort und Sicherheitskonfiguration. Diese Kontrolle kann bei bestimmten vertraglichen oder regulatorischen Anforderungen helfen. Der Betreiber muss Kapazität finanzieren und Personal für den Betrieb beschäftigen. Die Erweiterung ist durch die verfügbare Hardware begrenzt, sodass der Betreiber geringere Skaleneffekte als ein großer öffentlicher Anbieter erzielt.

Ein lokaler Serverraum zählt nur dann als Private Cloud, wenn er Cloud-Merkmale bietet, darunter Selbstbedienung, Bündelung, schnelle Elastizität und gemessene Nutzung. Die bloße Installation von VMs lässt wichtige Teile dieses Dienstmodells vermissen. OpenStack ist ein Beispiel für Software zum Aufbau von Private Clouds.

Community Cloud

Eine Community Cloud dient einer bestimmten Gruppe von Organisationen mit gemeinsamen Anliegen. Sie können einen Auftrag, eine Sicherheitsrichtlinie oder Compliance-Anforderungen teilen. Mitgliedsorganisationen, ein Dritter oder eine Kombination daraus können sie vor Ort oder außerhalb betreiben. Mehrere Krankenhäuser könnten sich eine Infrastruktur teilen, die auf ihre gemeinsamen Anforderungen an Gesundheitsdaten ausgelegt ist.

Ein ausschließlich für Behörden bestimmtes Angebot kann einer Gemeinschaft dienen, aber die tatsächliche Nutzungsberechtigung und die Betriebsform bestimmen seine Einordnung. Der Standort allein lässt nicht auf das Bereitstellungsmodell schließen. Eine Hosted Private Cloud bleibt privat, obwohl sie sich im Gebäude eines Anbieters befindet.

Organisationen behalten häufig einige Workloads lokal und führen andere in Public Clouds aus. Die Namen Hybrid Cloud und Multicloud beschreiben unterschiedliche Merkmale dieser Anordnung. Ein Unternehmen kann beides gleichzeitig haben.

Verbinde Umgebungen in einem hybriden Modell

Das NIST definiert eine Hybrid Cloud als getrennte Cloud-Infrastrukturen, die durch Technologie verbunden sind, die die Übertragung von Daten oder Anwendungen zwischen ihnen ermöglicht. Die Bestandteile bleiben getrennt. In alltäglichen Gesprächen über die Cloud, einschließlich grundlegender Anbieterprüfungen, bedeutet Hybrid meist eine Public Cloud, die mit einer Private Cloud oder mit On-Premises-Systemen verbunden ist.

Eine sichere Verbindung kann ein verschlüsseltes VPN über das Internet oder eine dedizierte private Verbindung sein. Gemeinsame Identitäts- und Verwaltungswerkzeuge können Mitarbeitern helfen, die Umgebungen zusammen zu betreiben. Azure Arc, AWS Outposts und Google Distributed Cloud unterstützen unterschiedliche Formen des standortübergreifenden Betriebs; sie sind Beispiele und keine austauschbaren Produkte.

Bei einer Hybrid Cloud können sensible Akten, ältere Software oder Anlagensteuerungssysteme lokal bleiben, während die Public Cloud eine Website hostet oder zusätzliche Nachfrage bearbeitet. Sie unterstützt auch eine schrittweise Migration und ortsferne Lösungen für Datensicherung oder Wiederherstellung. Diese Vorteile bringen zusätzlichen Aufwand für Netzwerk, Sicherheit und Verwaltung mit sich.

Rechne Cloud Bursting durch

Die Private Cloud eines Einzelhändlers verarbeitet 2.000 Bestellungen pro Minute. Während einer Verkaufsaktion steigt die Nachfrage auf 5.000. Die Public Cloud übernimmt den Überschuss:

Ihr Anteil an der Spitzenlast beträgt:

Das ist Cloud Bursting: Zusätzliche Kapazität wird bei Spitzenlasten genutzt und anschließend freigegeben. Die Anwendung und die Datenverbindungen müssen die Aufteilung dieser Arbeit unterstützen. Das bloße Abonnieren eines zweiten Dienstes bewirkt noch kein Cloud Bursting.

Nutze mehrere öffentliche Anbieter

Multicloud bedeutet, Dienste von zwei oder mehr Public-Cloud-Anbietern zu nutzen. Ein Unternehmen könnte die Analysedienste eines Anbieters und das Webhosting eines anderen wählen. Die Dienste können getrennt genutzt werden; Multicloud verlangt nicht, dieselbe Workload zwischen ihnen zu verschieben.

Mögliche Gründe sind die Wahl des passendsten Dienstes für jede Aufgabe, die Erfüllung von Standortanforderungen, eine geringere Abhängigkeit von einem Anbieter oder die Zusammenführung von Systemen nach einer Fusion. Dem stehen der Bedarf an mehreren Kompetenzbereichen und Sicherheitswerkzeugen sowie Rechnungen für Datenübertragungen gegenüber.

Für ein Start-up ohne Rechenzentrum kann eine Public Cloud die anfänglichen Geräteausgaben minimieren. Eine Organisation mit der Anforderung an eine ausschließlich selbst genutzte Infrastruktur kann eine Private Cloud wählen. Eine Fabrik, die sehr kurze lokale Antwortzeiten benötigt, kann die Maschinensteuerung vor Ort behalten und für Analysen eine Public Cloud nutzen. Die Anforderungen jeder Workload bestimmen die Standortentscheidung; mehr Umgebungen erhöhen den Aufwand, sie zu verbinden und zu steuern.

Cloud-Kapazität lässt sich an veränderte Arbeit anpassen. Skalierbarkeit beschreibt diese Anpassungsfähigkeit. Elastizität ergänzt schnelles Erweitern und Verringern, sodass die Kapazität der Nachfrage eng folgt. Beides kann den Bedarf senken, Geräte für die höchstmögliche Last zu kaufen.

Skaliere eine Maschine oder ändere die Anzahl der Maschinen

Eine VM von 2 auf 8 vCPUs umzustellen ist vertikale Skalierung. Der Wechsel von 2 Webservern auf 6 ist horizontale Skalierung. Ein Load Balancer verteilt eingehende Anfragen auf die Kopien. Zusätzliche Kopien können auch Redundanz schaffen, sofern sie so bereitgestellt werden, dass sie die betreffenden Ausfälle überstehen.

Eine Richtlinie für automatische Skalierung könnte eine VM hinzufügen, nachdem die Prozessorauslastung fünf Minuten lang über 70 % geblieben ist, und eine entfernen, wenn sie unter 30 % bleibt. Ein Minimum von zwei und ein Maximum von zehn halten die Richtlinie innerhalb eines geplanten Bereichs. Eine einzelne Cloud-VM passt sich nicht allein deshalb selbst an, weil sie in einer Cloud läuft. Manche verwalteten Dienste übernehmen die Skalierung für den Kunden.

Berechne die durch Elastizität eingesparte Kapazität

Eine Ticketseite benötigt normalerweise 4 Server und für 10 Stunden in einem Monat mit 730 Stunden insgesamt 20. Laufen 20 den ganzen Monat, ergibt das:

Bei elastischer Kapazität bleiben zunächst die normalen vier Server den ganzen Monat in Betrieb:

Für die Spitze kommen nur die 16 zusätzlichen Server hinzu:

Insgesamt sind das 3.080 Serverstunden, etwa 21 % von 14.600. Würde man während der Spitze 20 zusätzliche Server zählen, wären die vier Server der Grundlast doppelt gezählt. Nur vier dauerhaft vorzuhalten würde ungenutzte Kapazität vermeiden, aber den Spitzenbedarf nicht decken.

Provisioniere schnell und erreiche Nutzer weltweit

Agilität bezeichnet die Geschwindigkeit, mit der Ressourcen beschafft, eine Idee getestet und ein Ergebnis geliefert werden. Ein Team kann 50 VMs für eine zweistündige Analyse mieten, dabei 100 VM-Stunden nutzen und sie anschließend freigeben. Es muss nicht darauf warten, dass 50 Maschinen gekauft und installiert werden. Schnelle Experimente senken die Kosten, wenn eine gescheiterte Idee verworfen wird.

Globale Reichweite bedeutet, Standorte von Anbietern auf der ganzen Welt zu nutzen, ohne Rechenzentren im Ausland zu bauen. Eine Anwendung näher bei den Nutzern zu platzieren kann die Latenz, also die Verzögerung bei der Kommunikation, verringern. Dafür muss weiterhin ein geeigneter Standort gewählt und müssen die Datenanforderungen der Workload erfüllt werden.

Da der Anbieter die Hardwarearbeit übernimmt, haben Mitarbeiter außerdem mehr Zeit für Produkte und Dienste.

Verfügbarkeit ist der Anteil eines Zeitraums, in dem ein Dienst in Betrieb und nutzbar ist. Hochverfügbarkeit nutzt redundante Komponenten, um die Ausfallzeit bei einem Ausfall gering zu halten. Zuverlässigkeit betrifft außerdem den korrekten Weiterbetrieb und die Erholung von Ausfällen.

Wandle einen Prozentsatz in Ausfallzeit um

Verwende den Anteil des Zeitraums, in dem der Dienst nicht verfügbar ist:

Ein Monat mit 30 Tagen hat 43.200 Minuten. Bei 99,95 % beträgt der nicht verfügbare Anteil 0,0005, die Ausfallzeit also 21,6 Minuten.

Ein Service Level Agreement (SLA) legt die formelle Zusage eines Anbieters und die Abhilfe fest. Die Abhilfe besteht häufig aus Dienstgutschriften mit Anspruchsvoraussetzungen und Ausschlüssen, nicht aus einem Ersatz aller Geschäftsverluste. Das SLA eines Dienstes kann davon abhängen, dass mehrere Instanzen oder Standorte genutzt werden. Kostenlose Angebote oder Vorabversionen haben möglicherweise keines.

Unterscheide Abhängigkeiten von redundanten Kopien

Benötigt eine Anwendung sowohl ihre Webschicht als auch ihre Datenbank, kann jede der beiden die Anwendung unterbrechen. In einem vereinfachten Modell mit unabhängigen Ausfällen und vergleichbaren Messungen multiplizierst du ihre Verfügbarkeiten als Dezimalzahlen:

Das sind etwa 99,94 % und damit weniger als bei jeder der Komponenten. SLA-Zusagen allein belegen nicht die tatsächliche Betriebszeit der Anwendung; auch gemeinsame Abhängigkeiten und Messregeln sind relevant.

Bei zwei unabhängigen Kopien, von denen eine ausreicht, müssen beide ausfallen, um den Dienst zu stoppen. Ist jede zu 99 % der Zeit verfügbar, hat jede einen Ausfallanteil von 1 %:

Unabhängigkeit ist entscheidend. Kopien, die beide von derselben ausgefallenen Stromversorgung abhängen, bieten diesen Schutz nicht.

Nutze den passenden Schutz und das passende Maß

Anbieter stellen getrennte Rechenzentren, sogenannte Verfügbarkeitszonen, mehrere Regionen und verwaltete Replikation bereit. Kopien in getrennten Zonen können vor dem Ausfall eines Rechenzentrums schützen; eine zweite Region kann vor einem größeren regionalen Vorfall schützen. Die Planung und Bezahlung geeigneter Kopien bleibt eine Entscheidung des Kunden.

Fehlertoleranz zielt darauf ab, nach dem Ausfall einer Komponente ohne Unterbrechung weiterzulaufen. Hochverfügbarkeit kann eine kurze Unterbrechung zulassen. Notfallwiederherstellung stellt Dienst und Daten nach einem größeren Vorfall wieder her. Datensicherungen schützen Daten, sorgen aber nicht dafür, dass ein ausgefallener Server während der Wiederherstellung Anfragen beantwortet.

Vorhersagbarkeit umfasst gleichbleibende Leistung und nachvollziehbare Kosten. Skalierung und Lastverteilung helfen, die Leistung zu steuern; Nutzungsberichte, Prognosen, Budgets und Warnungen helfen bei der Steuerung der Ausgaben. Höhere Verfügbarkeit benötigt meist zusätzliche Ressourcen; das Ziel sollte daher die Kosten einer Ausfallzeit für das Unternehmen berücksichtigen.

Cloud-Anbieter stellen Sicherheitsteams, physische Kontrollen und Überwachung in einem Umfang bereit, den viele Organisationen selbst nicht aufbauen können. Sie bieten auch Werkzeuge, mit denen Kunden einheitliche Regeln anwenden können. Der Vorteil entsteht, wenn diese Werkzeuge genutzt und die Aufgaben klar zugewiesen werden.

Nutze Sicherheitsmaßnahmen und Compliance-Nachweise des Anbieters

Anbieter schützen Gebäude, Geräte und physische Netzwerke. Sie warten ihre Infrastruktur und liefern Plattformupdates für verwaltete Dienste. Kunden können Identitätskontrollen, Verschlüsselung, Firewalls, Sicherheitsüberwachung und Schutz vor Distributed-Denial-of-Service-Angriffen nutzen, bei denen viele Systeme einen Dienst mit Datenverkehr überfluten.

Anbieter lassen sich außerdem anhand von Standards und Rahmenwerken wie ISO/IEC 27001 und SOC 2 prüfen. Diese Berichte liefern Belege für die Kontrollen des Anbieters. Zugriffsregeln, Datenverarbeitung und Dienstkonfiguration des Kunden müssen weiterhin die Anforderungen der Organisation erfüllen. Die Prüfung des Anbieters ist ein Teil dieser Nachweise und keine Genehmigung jeder dort laufenden Anwendung.

Halte die Cloud-Nutzung innerhalb der Organisationsregeln

Governance umfasst Richtlinien, Prozesse und Kontrollen, die die Cloud-Nutzung an Geschäftsregeln, rechtliche Pflichten und Budgets anpassen. Sie umfasst weit mehr als die Senkung von Rechnungen.

Eine Organisation kann zum Beispiel die Erstellung von VMs auf eine genehmigte Auswahl von Regionen beschränken. Eine Richtlinie lehnt eine Anfrage außerhalb dieser Auswahl ab, bevor die Ressource existiert. Tags können das für eine VM verantwortliche Team ausweisen, während Protokolle zeigen, wer sie geändert hat. Jedes Werkzeug beantwortet eine andere Verwaltungsfrage.

Verwalte Ressourcen einheitlich

Microsoft unterscheidet Verwaltung der Cloud, also die Fähigkeiten zum Betrieb von Ressourcen, von Verwaltung in der Cloud, also den Methoden, mit denen Menschen sie steuern. Zur ersten gehören automatische Skalierung, Zustandsprüfungen, Ersatz ausgefallener Ressourcen und Warnungen. Zur zweiten gehören ein Portal, eine Befehlszeilenschnittstelle (CLI), APIs, Software Development Kits (SDKs) und Infrastructure as Code.

Infrastructure as Code (IaC) beschreibt Ressourcen in Dateien, die Bereitstellungswerkzeuge lesen können. Eine Vorlage für zwei Web-VMs, einen Load Balancer und eine Datenbank kann in wenigen Minuten eine passende Testumgebung erstellen. Dieselbe Ressourcenbeschreibung lässt sich erneut nutzen, ohne sich eine Folge manueller Klicks merken zu müssen. Regionsspezifische Einstellungen und andere erforderliche Werte müssen weiterhin stimmen.

Automatisierung kann auch Abschaltungen planen, Updates einspielen oder Datensicherungen erstellen. Weniger wiederholte manuelle Schritte verringern die Möglichkeiten für uneinheitliche Einstellungen und können die Betriebskosten senken. Nach einem Test beendet das Löschen seiner Ressourcen deren ressourcenspezifische Gebühren; aufbewahrte Datensicherungen, Datenträger oder andere Dienste bleiben kostenpflichtig. Diese verbleibenden Ressourcen im Blick zu behalten gehört zur Verwaltung der Umgebung.

Cloud Computing verschiebt viele Ausgaben vom Kauf von Anlagen zur Bezahlung von Diensten bei ihrer Nutzung. Die Messgrößen zu verstehen ist der erste Schritt, um eine Rechnung zu lesen und die Cloud mit eigenen Geräten zu vergleichen.

Vergleiche Ausgabenarten

Mit Investitionsausgaben (CapEx) werden Anlagen gekauft, die über mehrere Jahre genutzt werden, etwa Server und Speichergeräte. Die Buchhaltung verteilt ihre Kosten durch Abschreibung. Betriebsausgaben (OpEx) decken laufende Kosten wie Strom, Abonnements und Cloud-Dienste, wenn die Ausgaben anfallen.

Die Kapazitätskosten vor Ort sind weitgehend fix: Gekaufte Geräte, Platz und Personal kosten auch bei wenig ausgelasteten Maschinen Geld. Verbrauchsabhängige Cloud-Gebühren verändern sich mit der Nutzung. Eine Nutzungszusage oder ein Abonnement pro Nutzer kann dennoch einen festen Teil einer Cloud-Rechnung ausmachen.

Nutzungsabhängige Bezahlung ermöglicht Kunden, Ressourcen ohne langfristige Nutzungszusage zu beziehen. Die Freigabe einer Ressource beendet ihre eigenen Nutzungsgebühren. Eine zugewiesene VM lediglich nicht mehr zu nutzen gibt sie nicht frei, und beim Löschen einer VM können separat abgerechnete Datenträger oder Datensicherungen bestehen bleiben.

Lies eine Rechnung Position für Position

Rechne mit einem Monat von 730 Stunden und beispielhaften Preisen. Zwei VMs laufen den ganzen Monat für 0,10 US-Dollar pro Stunde. Eine dritte läuft 120 Stunden. Der Speicher beträgt durchschnittlich 500 GB zu 0,02 US-Dollar pro GB-Monat, und 200 GB werden für 0,09 US-Dollar pro GB ins Internet übertragen.

• Rechenleistung für die Grundlast: zweimal 730 Stunden ergeben 1.460 VM-Stunden und kosten 146 US-Dollar.
• Zusätzliche Rechenleistung: 120 Stunden kosten 12 US-Dollar.
• Speicher: 500 GB-Monate kosten 10 US-Dollar.
• Ausgehender Datenverkehr: 200 GB kosten 18 US-Dollar.

Addiere die einzelnen Gebühren:

Die Monatssumme beträgt 186 US-Dollar. Ausgehender Datenverkehr verlässt die Cloud; eingehender Datenverkehr gelangt in sie hinein. Bei vielen Angeboten ist eingehender Datenverkehr kostenlos, während ausgehender Verkehr ins Internet oder Übertragungen zwischen Regionen berechnet werden. Ein Mediendienst, der große Dateien an Nutzer sendet, muss diese ausgehenden Datenmengen in seine Schätzung einbeziehen.

Vergleiche die Gesamtbetriebskosten

Die Gesamtbetriebskosten (TCO) vergleichen alle relevanten Kosten über denselben Zeitraum. Beziehe bei eigener IT Geräte und deren Ersatz, Softwarelizenzen, Platz, Strom, Kühlung, physische Sicherheit, Netzwerk und Personalzeit ein. Berücksichtige bei der Cloud Rechenleistung, Speicher, Übertragungen, Lizenzen, Verwaltung und alle für den Vergleich relevanten Migrationskosten.

Große Anbieter erzielen Skaleneffekte, indem sie Geräte in großen Mengen kaufen und betreiben und diese Kosten auf Kunden verteilen. Ihre niedrigeren Stückkosten können attraktive Preise ermöglichen. Die Einsparung bei einer einzelnen Workload hängt weiterhin von Auslastung, passender Dimensionierung und dem genutzten Tarif ab. Dauerhaft laufende überdimensionierte Ressourcen können mehr kosten als ein gut ausgelasteter eigener Server.

Auch nutzungsabhängige Ausgaben müssen überwacht werden. Vergessene Ressourcen und unerwartete Skalierung können eine variable Rechnung erhöhen. Überwachung, Prognosen, Budgets und Warnungen helfen dem Team zu reagieren, während die Ressourcen noch laufen.

Bei Cloud-Preisen stehen Flexibilität einerseits und Nutzungszusagen oder das Risiko einer Unterbrechung andererseits gegenüber. Beginne mit der erwarteten Nutzung der Workload und wähle passende Bedingungen.

Ordne die wichtigsten Preisoptionen zu

AWS bietet Reserved Instances und Savings Plans an, Azure Reservations und Savings Plans und Google Cloud Committed Use Discounts. Die genauen Bedingungen unterscheiden sich, doch die zentrale Frage lautet, ob die vorhersagbare Nutzung die Nutzungszusage deckt.

Beispiele für Spot-Kapazität sind AWS Spot Instances, Azure Spot Virtual Machines und Google Cloud Spot VMs. Sie eignen sich für Aufträge, die angehalten und fortgesetzt werden können, etwa Stapelanalysen oder Rendering. Die Vorwarnzeit kann sehr kurz sein: AWS bemüht sich bei Unterbrechungen durch Stoppen oder Beenden um eine Vorwarnung von zwei Minuten; der Ruhezustand kann sofort beginnen. Bei Azure Spot können Benachrichtigungen bis zu 30 Sekunden vor der Entziehung eintreffen. Ein ständig benötigter Bezahldienst oder eine Datenbank braucht mehr Schutz als eine unterbrechbare Instanz.

Berechne den Break-even-Punkt

Eine VM kostet beispielhaft bedarfsgesteuert 0,10 US-Dollar pro Stunde. Eine einjährige Nutzungszusage kostet für alle 8.760 Stunden jeweils 0,06 US-Dollar:

Dividiere diese Jahreskosten durch den bedarfsgesteuerten Stundenpreis:

Das sind 60 % des Jahres. Oberhalb von 5.256 Stunden ist die Nutzungszusage bei diesen Preisen günstiger. Bei Dauerbetrieb kostet die bedarfsgesteuerte Nutzung 876 US-Dollar, die Ersparnis beträgt also 350,40 US-Dollar. Bei 2.080 Büroarbeitsstunden kostet die bedarfsgesteuerte Nutzung 208 US-Dollar und damit weniger als die vollständige Nutzungszusage. Würde der rabattierte Preis nur auf die genutzten Stunden angewendet, bliebe die vertragliche Zahlung unberücksichtigt.

Verringere den Bedarf vor der Rabattierung

Rightsizing passt Ressourcen an den gemessenen Bedarf an. Eine VM mit 8 vCPUs und durchschnittlich 10 % Prozessorauslastung sollte überprüft werden. Prüfe repräsentative Spitzenlasten sowie den Bedarf an Arbeitsspeicher, Speicherplatz und Netzwerk, bevor du sie auf 2 vCPUs verkleinerst. Bewältigt die kleinere Größe diese Anforderungen und ist der Preis proportional, sinken die Rechenkosten auf etwa ein Viertel. Eine zuvor gekaufte Nutzungszusage könnte eine überdimensionierte Ressource festschreiben.

Auch die Zeitplanung ist wichtig. Eine Testumgebung, die an fünf Wochentagen jeweils 10 Stunden läuft, nutzt 50 der 168 Stunden einer Woche. Wird sie außerhalb dieser Zeiten freigegeben, sinkt die Rechenzeit um etwa 70 %.

Beziehe Software und weitere Preisbedingungen ein

Preise inklusive Lizenzen enthalten die Softwarelizenz. Bei Bring Your Own License (BYOL) werden vorhandene Lizenzen genutzt, wenn ihre Bedingungen die Cloud-Nutzung erlauben; der Azure-Hybridvorteil ist ein Beispiel. Nutzungsberechtigung, Nachverfolgung und eine mögliche Pflicht zu dedizierter Hardware gelten weiterhin.

Andere Angebote nutzen Abonnements pro Nutzer, Mengenpreisstaffeln, Testguthaben oder Preise für dedizierte Hosts. Eine praktische Kombination kann Nutzungszusagen für die gleichbleibende Grundlast, nutzungsabhängige Bezahlung für unsichere Nachfrage und Spot-Kapazität für wiederaufnehmbare Stapelverarbeitung verwenden.

Das Modell der geteilten Verantwortung teilt Sicherheits-, Compliance- und Betriebsaufgaben zwischen Anbieter und Kunde auf. AWS bezeichnet den Anteil des Anbieters als Sicherheit „der“ Cloud und den Anteil des Kunden als Sicherheit „in“ der Cloud. Die Grenze verändert sich mit dem Dienst, aber für Kundendaten und Zugriffsentscheidungen bleibt immer jemand verantwortlich.

Beginne bei den physischen Schichten

Der Anbieter schützt und betreibt Rechenzentrumsgebäude, physische Zugangskontrollen, Stromversorgung, Kühlung, physische Netzwerke, Hosts und Virtualisierung. Kunden verlassen sich auf diese Kontrollen und die Prüfungsnachweise. Bei gewöhnlicher IaaS-Nutzung versorgen sie den Hypervisor des Anbieters nicht mit Patches.

Kunden entscheiden, wie ihre Daten klassifiziert, geschützt, aufbewahrt und geteilt werden. Sie verwalten Konten, Identitäten, Zugriffsrechte und die von ihnen kontrollierten Diensteinstellungen. Außerdem schützen sie die Geräte, mit denen auf Dienste zugegriffen wird. Ein SaaS-Anbieter kann Funktionen zur Geräteverwaltung bereitstellen, während die Organisation für die Verwaltung der Geräte ihrer Nutzer verantwortlich bleibt.

Bestimme die veränderliche Grenze

Für die Plattformwartung gelten dienstspezifische Verfahren. Manche PaaS-Angebote verlangen, verwaltete Updates zu aktivieren, auf eine unterstützte Version zu wechseln oder fehlgeschlagene Updates zu beheben. Der Kunde muss diese Verfahren befolgen, auch wenn er keinen allgemeinen Server selbst betreibt.

Ordne drei Vorfälle zu

Ein Unternehmen nutzt eine IaaS-Website, eine verwaltete PaaS-Datenbank und SaaS-E-Mail. Eine Schwachstelle im Gastbetriebssystem wird bekannt. Das Unternehmen versorgt seine Website-VM mit einem Patch; der Anbieter wartet die Betriebssysteme unter der verwalteten Datenbank und der E-Mail-Anwendung gemäß den jeweiligen Updatevereinbarungen.

Anschließend wird das Passwort eines Mitarbeiters gestohlen. Das Unternehmen muss den Zugang zurücksetzen, Berechtigungen überprüfen und den Kontoschutz für alle betroffenen Dienste verstärken. Der Wechsel zu SaaS hat seine Identitätsentscheidungen nicht an den Anbieter übertragen.

Schließlich werden Kundendateien öffentlich lesbar, weil das Unternehmen eine offene Freigabe aktiviert hat. Es muss diese Einstellung korrigieren und sich um die Offenlegung kümmern. Die physische Sicherheit des Rechenzentrums kann nicht verhindern, dass ein berechtigter Administrator eine unsichere Freigaberegel wählt.

Teile Maßnahmen auf, nicht nur Bezeichnungen

Bei manchen Maßnahmen übernimmt jede Seite einen Teil. Anbieter versorgen die Infrastruktur mit Patches; Kunden versorgen die Software mit Patches, die sie kontrollieren. Jede Partei konfiguriert ihre eigenen Schichten und schult ihre eigenen Mitarbeiter. Physische Kontrollen werden vom Anbieter geerbt, während Anwendungseinstellungen beim Kunden bleiben.

Compliance folgt derselben Aufteilung. Eine Zertifizierung des Anbieters deckt dessen geprüfte Kontrollen ab. Der Kunde braucht Nachweise, dass seine Konfiguration, sein Umgang mit Daten und seine Prozesse die Anforderungen seiner Workload erfüllen. Die Verantwortungsdokumentation und der Vertrag des jeweiligen Dienstes erläutern die genaue Grenze.

Die Cloud-Einführung ist eine Entscheidung für jede einzelne Workload. Elastizität, schnelle Bereitstellung und verwaltete Dienste können wertvoll sein, aber jeder Vorteil muss zu den Anforderungen der Organisation passen. Benenne jedes Risiko genau genug, um eine Gegenmaßnahme wählen zu können.

Erkenne Abhängigkeiten und Grenzen der Kontrolle

Anbieterbindung entsteht, wenn proprietäre APIs, Dienste oder Datenformate einen Anbieterwechsel langsam oder teuer machen. Der Export großer Datenmengen kann außerdem Gebühren für ausgehenden Datenverkehr verursachen. Offene Formate, portable Werkzeuge, Container und getestete Datenexporte können den Wechselaufwand verringern. Jede dieser Möglichkeiten verursacht Kosten oder begrenzt die verfügbaren Funktionen. Portabilität ist daher eine Entscheidung, die abgewogen werden muss.

Der Anbieter kontrolliert seine Geräte, die Gestaltung seiner Einrichtungen und den Lebenszyklus seiner Dienste. Kunden stützen sich für Nachweise über die Infrastruktur auf Verträge, Dokumentation und unabhängige Prüfungen. Sie brauchen auch eine Reaktion, wenn ein Dienst verändert oder eingestellt wird.

Prüfe Verbindungen, Standort und Antwortzeit

Cloud-Zugriff hängt vom Netzwerk ab. Der Ausfall einer Büroverbindung kann Mitarbeiter daran hindern, eine funktionierende Cloud-Anwendung zu nutzen. Eine entfernte Region erhöht die Kommunikationsverzögerung. Eine Fabriksteuerung, die Antworten innerhalb von Millisekunden benötigt, kann lokal bleiben, während Cloud-Dienste die entstehenden Daten analysieren.

Datenresidenz bezeichnet den Ort, an dem Daten gespeichert und verarbeitet werden. Datensouveränität betrifft die dafür geltenden Gesetze und die rechtliche Zuständigkeit. Die Wahl einer Region regelt den Standort, aber auch Verträge, Zugriffsvereinbarungen und rechtliche Anforderungen sind wichtig. Eine Organisation kann eine genehmigte Region, ein geeignetes souveränes Angebot oder lokale Verarbeitung benötigen. Es wird keine bestimmte Rechtsregel für alle Länder vorausgesetzt.

Ordne jedem Risiko eine praktische Gegenmaßnahme zu

Eine Budgetwarnung meldet einen Schwellenwert; sie schaltet Ressourcen nicht selbst ab. Skalierungsgrenzen helfen, die Kapazität zu begrenzen, während ein Wiederherstellungsplan Unterbrechungen behandelt. Diese Maßnahmen lösen unterschiedliche Probleme.

Triff eine begründete Einführungsentscheidung

Eine Kanzlei mit 40 Mitarbeitern erwägt SaaS für das Dokumentenmanagement. Sie erwartet Fernzugriff, weniger Serverarbeit und das Sicherheitswissen des Anbieters als Vorteile. Die Kanzlei prüft, ob der Speicherort ihre Anforderungen erfüllt, Dokumente in Standardformaten exportiert werden können und alle Nutzer Mehrfaktorauthentifizierung verwenden können.

Diese Prüfungen verbinden jedes Anliegen mit Nachweisen: Region und Vertrag für die Datenresidenz, ein Exporttest für die Portabilität und Kontokontrollen für den Zugriff. Die Kanzlei kann den Wechsel beschließen, wenn der Dienst diese Anforderungen erfüllt. Eine andere Workload, etwa eine lokale Maschinensteuerung, kann aus guten Gründen vor Ort bleiben.

Der Cloud-Betrieb braucht auch Menschen, die Sicherheit, Kosten und Automatisierung verstehen. Durch schnelle Selbstbedienung lassen sich neue Ressourcen leicht erstellen. Deshalb muss die Governance Verantwortliche, Zweck und erlaubte Einstellungen klar festlegen.

Bei einer Cloud-Migration werden Anwendungen, Daten oder Infrastruktur aus vorhandenen Systemen in eine Cloud verschoben. Beginne mit einer Bestandsaufnahme von Anwendungen, Abhängigkeiten, Nutzung, Kosten und Geschäftswert. Wähle dann für jede Workload eine Strategie. Dieser Portfolioansatz vermeidet es, jedes System auf dieselbe Weise zu migrieren.

Vergleiche die sieben Strategien

Die 7 Rs von AWS bieten ein nützliches Vokabular:

Auch Google verwendet Begriffe für Replatforming und umfassendere Veränderungen. Die tatsächlich durchgeführte Maßnahme ist aussagekräftiger, als nur die Wortwahl eines Anbieters auswendig zu lernen.

Unterscheide leicht verwechselbare Umzüge

Rehosting lässt den Code und die Kernarchitektur der Anwendung unverändert. Es kann den unmittelbaren Umzugsaufwand verringern, erhält aber viele Wartungsaufgaben. Beim Verlagern werden eine ganze kompatible Virtualisierungsumgebung und ihre Betriebsweise verschoben, nicht nur eine Anwendung auf eine neu gewählte VM-Plattform.

Replatforming verändert einen begrenzten Teil der Umgebung. Eine verwaltete Version derselben Datenbank-Engine kann die Serververwaltung entfallen lassen und gleichzeitig die Kernarchitektur der Anwendung erhalten. Neubeschaffung ersetzt das Produkt selbst. Der Ersatz einer eigenen Kundenverwaltungssoftware durch SaaS-CRM ist eine Neubeschaffung, auch wenn beide Produkte denselben Geschäftszweck erfüllen.

Refactoring verändert die Architektur, um Vorteile wie unabhängig skalierbare Komponenten zu gewinnen. Das kann langfristig erheblichen Wert schaffen, doch der anfängliche Aufwand lohnt sich bei einem stabilen System mit geringem Wert möglicherweise nicht. Das Beibehalten einer Anwendung kann eine bewusste Entscheidung bis zum Vertragsende, bis zu Kompatibilitätsarbeiten oder bis zu einer späteren Überprüfung sein.

Übertrage die Daten und plane die Umschaltung

Eine Datenbankmigration mit geringer Ausfallzeit kann damit beginnen, Daten in eine neue Datenbank zu kopieren und spätere Änderungen zu replizieren, während das Original weiter genutzt wird. Das Team prüft, ob das Ziel aufgeholt hat, bevor die Produktivumschaltung erfolgt, also die vereinbarte Umschaltung von Nutzern oder Datenverkehr auf das neue System.

Replikation verringert die Menge der Änderungen, die bei der Produktivumschaltung noch zu übertragen sind. Sie macht es nicht überflüssig, die Richtigkeit zu prüfen, die endgültige Umschaltung abzustimmen und Probleme einzuplanen. Bei sehr großen Datensätzen können physische Übertragungsgeräte die anfänglichen Massendaten übertragen, wenn eine Netzwerkübertragung unpraktisch ist.

Prüfe Abhängigkeiten, bevor du die Reihenfolge der Umzüge festlegst. Eine Anwendung, die weiterhin eine lokale Datenbank benötigt, kann eine Verbindung oder eine abgestimmte Migration erfordern. Rehosting kann ein erster Schritt sein, auf den Optimierung folgt; ein sinnvolles Portfolio kann Stilllegung, Beibehaltung, Ersatz und Neugestaltung kombinieren.