Das Wachstum der Rechenleistung und die Entwicklung der Virtualisierungstechnologien von x86 auf der einen Seite sowie die Verbreitung von IT-Outsourcing auf der anderen Seite haben zur Konzeption des Utility Computing (IT als Dienstleistung) gefĂŒhrt. Warum nicht fĂŒr IT genauso bezahlen wie fĂŒr Wasser oder Strom â genau dann und genau soviel, wie es benötigt wird, und nicht mehr.
In diesem Moment entstand das Konzept des Cloud Computing â die Nutzung von IT-Diensten aus der "Cloud", d.h. aus einem externen Ressourcenpool, ohne sich darum zu kĂŒmmern, wie und woher diese Ressourcen stammen. So wie wir uns nicht um die Infrastruktur der Wasserwerke kĂŒmmern. Zu diesem Zeitpunkt wurde auch die andere Seite des Konzepts ausgearbeitet â nĂ€mlich das VerstĂ€ndnis von IT-Diensten und deren Verwaltung im Rahmen von ITIL / ITSM.
Es wurden eine Reihe von Definitionen fĂŒr Clouds (Cloud Computing) entwickelt, aber diese sollten nicht als die letzte Wahrheit betrachtet werden â es handelt sich lediglich um eine Möglichkeit, die Bereitstellung von Utility Computing zu formalisieren.
- «Cloud Computing ist eine Technologie zur verteilten Datenverarbeitung, bei der Computerressourcen und -leistungen dem Benutzer als Internetdienst bereitgestellt werden» - Wikipedia
- «Cloud Computing ist ein Modell fĂŒr den bequemen Netzwerkzugang zu einem gemeinsamen Pool anpassbarer Rechenressourcen (z. B. Netzwerke, Server, Speicher, Anwendungen und Dienstleistungen), die nach Bedarf schnell bereitgestellt werden können, mit minimalem Verwaltungsaufwand oder minimaler Eingreifzeit des Dienstanbieters» - NIST
- «Cloud Computing ist ein Paradigma, das Netzwerkzugang zu einem skalierbaren und flexiblen Pool verteilter physischer oder virtueller Ressourcen ermöglicht, die im Selbstbedienungsmodus bereitgestellt und nach Bedarf verwaltet werden» - ISO/IEC 17788:2014. Informationstechnik â Cloud Computing â Ăbersicht und Wortschatz.
Laut NIST gibt es drei Haupttypen von Clouds:
- IaaS â Infrastructure as a Service â Infrastruktur als Dienst
- PaaS â Platform as a Service â Plattform als Dienst
- SaaS â Software as a Service â Software als Dienst

Um die Unterschiede einfacher zu verstehen, betrachten wir das Modell Pizza-as-a-Service:

NIST definiert die folgenden notwendigen Merkmale von IT-Diensten, die als Cloud-Dienste gelten:
- Universeller Netzwerkzugang (broad network access) â der Dienst sollte ĂŒber eine universelle Netzwerkschnittstelle verfĂŒgen, die es ermöglicht, den Dienst praktisch fĂŒr jeden mit minimalen Anforderungen zu nutzen. Ein Beispiel: Um das Stromnetz von 220V zu nutzen, reicht es, sich an jede Steckdose mit einem standardisierten universellen Interface (Stecker) anzuschlieĂen, das unabhĂ€ngig davon gleich bleibt, ob man einen Wasserkocher, einen Staubsauger oder ein Laptop anschlieĂt.
- Messbarkeit des Dienstes (measured service) â eine SchlĂŒsselfunktion von Cloud-Diensten ist die Messbarkeit des Services. ZurĂŒck zur Analogie mit ElektrizitĂ€t: Sie bezahlen genau so viel, wie Sie verbraucht haben, bis hin zur GranularitĂ€t einer einzelnen Nutzung, zum Beispiel um einen Wasserkocher zu erhitzen, wenn Sie nur einmal im Monat zu Hause waren und eine Tasse Tee getrunken haben.
- SelbstĂ€ndige Konfiguration der Services auf Abruf (on demand self service) â der Cloud-Anbieter ermöglicht es dem Kunden, die Dienste eigenstĂ€ndig zu konfigurieren, ohne dass eine Interaktion mit den Mitarbeitern des Anbieters notwendig ist. Um einen Wasserkocher zu benutzen, muss man nicht im Voraus den Energieversorger kontaktieren, um ihn zu informieren und eine Genehmigung zu erhalten. Sobald das Haus angeschlossen ist (Vertrag abgeschlossen), können alle Verbraucher eigenstĂ€ndig ĂŒber die bereitgestellte Leistung verfĂŒgen.
- Sofortige ElastizitĂ€t (rapid elasticity) â der Cloud-Anbieter stellt Ressourcen bereit, die eine sofortige Erhöhung / Verringerung der Leistung ermöglichen (innerhalb bestimmter angemessener Grenzen). Sobald der Wasserkocher eingeschaltet ist, stellt der Anbieter sofort 3 kW Leistung ins Netz bereit, und sobald er ausgeschaltet wird, reduziert er die Abgabe auf null.
- Die ZusammenfĂŒhrung von Ressourcen in einem Pool (Resource Pooling) - Die internen Mechanismen des Dienstanbieters ermöglichen es, separate ErzeugungskapazitĂ€ten in einen gemeinsamen Pool von Ressourcen zu integrieren, die dann als Dienstleistung unterschiedlichen Verbrauchern zur VerfĂŒgung gestellt werden. Uns interessiert am wenigsten, von welchem Kraftwerk die Leistung stammt, die wir nutzen. Alle anderen Verbraucher beziehen diese Leistung ebenfalls gemeinsam mit uns.
Es ist wichtig zu verstehen, dass die oben beschriebenen Eigenschaften der Cloud nicht willkĂŒrlich sind, sondern sich logisch aus dem Konzept des Utility Computing ableiten. Ein öffentlicher Dienst sollte ĂŒber diese Eigenschaften im Rahmen des Konzepts verfĂŒgen. Wenn eine bestimmte Eigenschaft nicht erfĂŒllt ist, wird der Dienst nicht schlechter oder "toxisch"; er hört einfach auf, eine Cloud-Dienstleistung zu sein. Aber wer hat gesagt, dass alle Dienste diese Anforderungen erfĂŒllen mĂŒssen?
Warum spreche ich das gesondert an? In den letzten 10 Jahren seit der Definition durch das NIST gab es viele Diskussionen ĂŒber das, was "echte Cloud" gemÀà dieser Definition ist. In den USA wird im rechtlichen Kontext manchmal der Ausdruck "entspricht dem Buchstaben des Gesetzes, aber nicht seinem Geist" verwendet â und im Falle von Cloud-Computing ist es vor allem der Geist, wobei die Ressourcen mit nur zwei Mausklicks gemietet werden können.
Es ist wichtig zu beachten, dass die oben genannten fĂŒnf Merkmale fĂŒr öffentliche Clouds gelten, aber beim Wechsel zu privaten Clouds werden die meisten davon optional.
- Universeller Netzwerkzugang (broad network access) â innerhalb einer privaten Cloud hat die Organisation die volle Kontrolle ĂŒber sowohl die Erzeugungsmittel als auch die Endverbraucher. Daher kann dieses Merkmal als automatisch erfĂŒllt angesehen werden.
- Die Messbarkeit des Dienstes (measured service) ist ein zentrales Merkmal des Konzepts des Utility Computing, bei dem nach Verbrauch abgerechnet wird. Aber wie bezahlt eine Organisation sich selbst? In diesem Fall gibt es eine Trennung zwischen Generierung und Verbrauch innerhalb des Unternehmens. IT wird zum Anbieter, wĂ€hrend die GeschĂ€ftsbereiche die Verbraucher der Dienstleistungen sind. Die Abrechnung erfolgt zwischen den Abteilungen. Es sind zwei Betriebsmodi möglich: Chargeback (bei tatsĂ€chlichen Abrechnungen und Finanztransfers) und Showback (in Form von Berichten ĂŒber den Ressourcenverbrauch in Rubel, jedoch ohne finanzielle Bewegungen).
- SelbststĂ€ndige Konfiguration von Diensten auf Anfrage (on demand self service) â innerhalb einer Organisation kann es einen gemeinsamen IT-Dienst geben, und in diesem Fall verliert dieses Merkmal an Bedeutung. Wenn jedoch eigene IT-FachkrĂ€fte oder Anwendungsadministratoren in den GeschĂ€ftsbereichen vorhanden sind, muss ein Selbstbedienungsportal eingerichtet werden. Fazit â das Merkmal ist optional und hĂ€ngt von der Struktur des Unternehmens ab.
- Die sofortige ElastizitĂ€t â innerhalb einer Organisation verliert an Bedeutung aufgrund der festgelegten Hardware-Ausstattung fĂŒr private Cloud-Lösungen. Sie kann nur eingeschrĂ€nkt fĂŒr interne Abrechnungen verwendet werden. Fazit â fĂŒr private Clouds nicht anwendbar.
- Ressourcenzusammenlegung â heutzutage gibt es eigentlich keine Organisationen mehr, die keine Servervirtualisierung nutzen. Diese Eigenschaft kann somit als automatisch erfĂŒllt betrachtet werden.
Frage: Was genau ist also Ihre private Cloud? Was muss ein Unternehmen kaufen und implementieren, um sie aufzubauen?
Antwort: Eine private Cloud ist der Ăbergang zu einem neuen Verwaltungsmodell fĂŒr die Interaktion zwischen IT und GeschĂ€ft, das zu 80 % aus administrativen MaĂnahmen und lediglich zu 20 % aus Technologien besteht.
Die Bezahlung lediglich fĂŒr genutzte Ressourcen und der einfache Zugang, ohne mehrere Hundert Millionen in Kapitalaufwendungen investieren zu mĂŒssen, haben eine neue technologische Landschaft und das Entstehen milliardenschwerer Unternehmen ermöglicht. So entstanden moderne Giganten wie Dropbox und Instagram als Startups auf AWS ohne eigene Infrastruktur.
Es ist wichtig hervorzuheben, dass die Verwaltungstools fĂŒr Cloud-Dienste zunehmend indirekter werden. Eine der Hauptaufgaben des IT-Direktors besteht nun darin, Anbieter auszuwĂ€hlen und die QualitĂ€t zu ĂŒberwachen. Lassen Sie uns die Herausforderungen dieser beiden neuen Verantwortlichkeiten nĂ€her betrachten.
Als Alternative zu herkömmlicher, schwerer Infrastruktur mit eigenen Rechenzentren und Hardware erscheinen Cloud-Lösungen irrefĂŒhrend einfach. Der Eintritt in die Cloud gestaltet sich unkompliziert, doch die Frage des Ausstiegs wird oft ignoriert. Wie in jeder anderen Branche verfolgen Cloud-Anbieter das Ziel, ihre GeschĂ€fte zu schĂŒtzen und die Konkurrenz zu erschweren. Der einzige ernsthafte Wettbewerbsvorteil tritt nur bei der Erstwahl des Cloud-Dienstanbieters zutage; danach wird der Anbieter alles daran setzen, dass der Kunde nicht wechselt. Dabei werden nicht alle Anstrengungen darauf gerichtet sein, die QualitĂ€t der Dienstleistungen oder deren Auswahl zu verbessern. Vielmehr handelt es sich um die Bereitstellung einzigartiger Services und den Einsatz von proprietĂ€rer Software, die den Wechsel zu einem anderen Anbieter erschwert. Daher ist es beim Auswahlprozess eines Dienstleisters unerlĂ€sslich, zugleich einen Wechselplan zu erstellen (im Grunde einen vollstĂ€ndigen DRP â Disaster Recovery Plan) und die Architektur der Daten- und Backup-Speicherung zu durchdenken.
Ein weiterer wichtiger Aspekt der neuen Aufgaben eines IT-Direktors ist die QualitĂ€tskontrolle der Dienstleistungen durch den Anbieter. Fast alle Cloud-Anbieter halten sich an SLAs, die auf ihren eigenen internen Metriken basieren, was jedoch nur einen indirekten Bezug zu den GeschĂ€ftsprozessen des Kunden hat. Daher wird die EinfĂŒhrung eines eigenen Ăberwachungs- und Kontrollsystems zu einem der SchlĂŒsselprojekte, wenn bedeutende IT-Systeme zu einem Cloud-Anbieter migriert werden. Im Zusammenhang mit SLAs muss betont werden, dass die ĂŒberwiegende Mehrheit der Cloud-Anbieter die Haftung fĂŒr die NichterfĂŒllung von SLAs auf die monatliche GebĂŒhr oder einen Anteil davon beschrĂ€nkt. Zum Beispiel gewĂ€hren AWS und Azure bei Ăberschreitung der VerfĂŒgbarkeitsgrenze von 95 % (36 Stunden pro Monat) einen 100%igen Rabatt auf die MonatsgebĂŒhr, wĂ€hrend Yandex.Cloud einen Rabatt von 30 % gewĂ€hrt.

Und natĂŒrlich darf man nicht vergessen, dass es Clouds nicht nur in der Dimension von Giganten wie Amazon und Yandex gibt. Es gibt auch kleinere Clouds â in der GröĂe einer Katze oder sogar einer Maus. Das Beispiel CloudMouse hat gezeigt, dass eine Cloud manchmal einfach aufhört. Sie erhalten weder eine EntschĂ€digung noch einen Rabatt â Sie bekommen nichts auĂer dem kompletten Datenverlust.
Aufgrund der oben genannten Probleme bei der Implementierung von hochgradig kritischen IT-Systemen in Cloud-Infrastrukturen beobachten wir in den letzten Jahren das PhÀnomen der "Cloud-Repatriierung".

Bis 2020 hatte der Hype um Cloud-Computing seinen Höhepunkt erreicht, und das Konzept bewegt sich auf dem absteigenden Ast der EnttĂ€uschungen (laut Gartner Hype Cycle). Laut Untersuchungen und bis zu 80 % der UnternehmensauftrĂ€ge kehren zurĂŒck und planen, Arbeitslasten aus Clouds in eigene Rechenzentren zurĂŒckzufĂŒhren, aus folgenden GrĂŒnden:
- Steigerung der VerfĂŒgbarkeit / Leistung;
- Kosten senken;
- Um den Anforderungen an die Informationssicherheit gerecht zu werden.
Was sollte man also tun und wie sieht die RealitÀt tatsÀchlich aus?
Es besteht kein Zweifel, dass die Cloud gekommen ist, um zu bleiben. Ihre Rolle wird von Jahr zu Jahr zunehmen. Doch wir leben nicht in einer fernen Zukunft, sondern im Jahr 2020 unter ganz bestimmten Bedingungen. Was sollten Unternehmen tun, die klassische Auftraggeber sind und kein Start-up?
- Cloud-Lösungen sind in erster Linie fĂŒr Dienste gedacht, die unvorhersehbare oder stark saisonale Lasten haben.
- In den meisten FĂ€llen ist es kostengĂŒnstiger, Dienste mit vorhersehbaren und stabilen Lasten in einem eigenen Rechenzentrum zu betreiben.
- Der Einstieg in Cloud-Lösungen sollte mit Testumgebungen und niedrig-prioritÀren Diensten beginnen.
- Die Ăberlegung, Informationssysteme in der Cloud zu platzieren, beginnt mit der Entwicklung einer Methode fĂŒr den Ăbertritt von einer Cloud in eine andere (oder zurĂŒck in das eigene Rechenzentrum).
- Die Platzierung eines Informationssystems in der Cloud beginnt mit der Erstellung eines Backup-Plans fĂŒr die Infrastruktur, die Sie kontrollieren.
Quelle: habr.com
