Inhaltsverzeichnis

Die Frage, ob ein konkretes Angebot die Cloud-Eigenschaften tatsächlich bereitstellt, ist keine akademische. NIST hat ihr eine eigene Publikation gewidmet. 

SP 500-322 aus dem Februar 2018 beschreibt den Anlass unmissverständlich: Manche Anbieter bezeichnen ihre Angebote als Cloud Services, auch wenn diese die wesentlichen Eigenschaften der NIST-Definition nicht unterstützen. Ohne Klarstellung, so NIST, riskieren Organisationen die Einführung von „Services“, die keine Cloud-Eigenschaften bieten. 

Dazu liefert das Dokument eine Bewertungsmethodik. Für jede der fünf wesentlichen Eigenschaften definiert NIST ein Primärkriterium, dazu eine objektive Option A und eine von den Anforderungen des Kunden abhängige Option B. Ergänzt wird jede Eigenschaft um die Angabe, welche Partei ihre Erfüllung überhaupt bestätigen kann. 

Beim On-demand Self-Service lautet das Primärkriterium, dass die Bereitstellung ohne menschliche Interaktion mit dem Anbieter erfolgen kann. Option A bedeutet vollständig automatisierte Bereitstellung einschließlich der internen Cloud-Infrastruktur. Bei Option B nutzt der Kunde eine automatisierte Schnittstelle zur Anforderung und Nachverfolgung, während der Anbieter intern manuell provisioniert. Für den Kunden ist dieser Unterschied nicht erkennbar, weil er ausschließlich die Bereitstellungsschnittstelle sieht und nicht das System dahinter. Bestätigen kann die Unterscheidung deshalb nur der Anbieter. 

Ähnlich verhält es sich beim Resource Pooling, das von der internen Architektur des Cloud Service abhängt und von außen nicht überprüfbar ist. Beim Measured Service liegt es genau umgekehrt: Ob die Messtiefe für die eigenen Anforderungen ausreicht, kann allein der Kunde beurteilen. 

[BILD 1] Prüfmatrix zu den fünf wesentlichen Eigenschaften nach NIST SP 500-322. Fünf Zeilen für On-demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity und Measured Service; Spalten für Primärkriterium sowie Bestätigungszuständigkeit. Farbliche Kennzeichnung, welche Eigenschaft nur der Anbieter, welche nur der Kunde und welche beide bestätigen können. Akzentfarbe für die vom Kunden nicht prüfbaren Zeilen. 

Für Architekturentscheidungen folgt daraus eine praktische Konsequenz. Ein Teil der Eigenschaften, die eine Cloud definieren, lässt sich nicht durch Beobachtung des Angebots feststellen, sondern nur durch Offenlegung seitens des Anbieters. Wer prüfen möchte, ob eine Plattform Cloud-Eigenschaften bereitstellt oder lediglich so vermarktet wird, muss diese Punkte in der Anbieterauswahl oder vertraglich adressieren. 

Ein weiterer Befund der Publikation betrifft die Abgrenzung dieses Artikels unmittelbar. NIST erläutert, was „essential“ in diesem Zusammenhang bedeutet: Der Anbieter muss in der Lage sein, jede der fünf Eigenschaften bereitzustellen. Der Kunde kann sich dafür entscheiden, eine Eigenschaft im konkreten Fall nicht zu implementieren oder nicht zu nutzen. Das trennt die beiden Betrachtungsachsen sauber. Eine per Lift-and-Shift verlagerte Umgebung entzieht der Plattform, auf der sie läuft, nicht deren Cloud-Qualifikation. Der Kunde nimmt die vorhandene Elastizität lediglich nicht in Anspruch. 

Zur Vorsicht mahnt NIST außerdem bei der verbreiteten Terminologie mit dem Suffix „as a Service“. Begriffe, die durch Anhängen dieses Suffix an eine beliebige Funktion entstehen, verwischen nach Einschätzung von NIST die architektonisch begründete Unterscheidung zwischen SaaS, PaaS und IaaS. Das Dokument führt dazu eine ausdrücklich ungefilterte Sammlung solcher Marketingbegriffe auf, in der sich unter anderem Storage as a Service, Backup as a Service und Disaster Recovery as a Service finden. Zu ihrer Definition nimmt NIST keine Position ein. Für die Bewertung eines Storage-Angebots bedeutet das: Der Name des Angebots trägt keine Aussage über seine Architektur.