Public Cloud: Shared Responsibility statt Full-Service-Provider

Das Thema Verantwortung in der Public Cloud ist eine Geschichte voller Missverständnisse. Beratungsmandate und Gespräche mit einer Vielzahl von unterschiedlichen Public Cloud interessierten Unternehmen offenbaren, dass viele IT-Entscheider  Public Cloud Anbieter wie im Outsourcing als Full-Service-Provider betrachten. Das erschwert Verhandlungen auf Augenhöhe und steht der zügigen Adaption von Public Cloud Services entgegen. Dabei gilt in der Public Cloud anders als beim klassischen Outsourcing das Prinzip der Shared Responsibility.

von René Büst, Crisp Research

Der Einfachheit halber wurde Cloud Computing in den vergangenen 10 Jahren immer wieder gerne mit dem Begriff  „Outsourcing 2.0“ gleichgesetzt. Was zu einem besseren Verständnis auf der Anwenderseite führen sollte, hat den Anbietern der „Ur-Cloud“, den Public Cloud Anbietern, jedoch einen Bärendienst erwiesen. Mit dem Verständnis des klassischen Outsourcings im Hinterkopf – ein externer Dienstleister übernimmt den z.T. vollständigen IT-Betrieb – betrachten IT-Entscheider  Public Cloud Anbieter als Full-Service-Provider. Der IT-Abteilung bleibt maximal die Koordination und Steuerung dieser externen Dienstleister.

Selbstverantwortung – Fehlanzeige: Das große Missverständnis

Was für Software-as-a-Service (SaaS) Anbieter als Hersteller von „Low Hanging Fruits“ ohne weiteres zutrifft, verhält sich auf Platform-as-a-Service (PaaS) und insbesondere auf Infrastructure-as-a-Service (IaaS) Ebene vollkommen anders. SaaS-Anbieter stellen fertig entwickelte und direkt einsetzbare Applikationen zur Verfügung. Die Komplexität, beispielsweise bei Lösungen von Salesforce und SAP, besteht in der Konfiguration, der individuellen Anpassung und ggf. der Integration mit anderen SaaS-Anbietern. Der SaaS-Anbieter ist somit für die Bereitstellung und den vollständigen Betrieb der Software und der dafür notwendigen Infrastruktur / Plattform verantwortlich. Der Kunde ist Konsument der Applikation. PaaS-Anbieter stellen Umgebungen für die Entwicklung und den Betrieb von Applikationen bereit. Anhand von APIs (Schnittstellen) erhält der Kunde Zugriff auf die Plattform und kann damit seine eigene Applikation entwickeln, betreiben und den eigenen Kunden bereitstellen. Der Anbieter ist somit für die Bereitstellung und den Betrieb der Infrastruktur und der Plattform zuständig. Der Kunde hat zu 100 Prozent Verantwortung für seine Applikation, hat aber keinen Einfluss auf die Plattform oder die Infrastruktur. IaaS-Anbieter übernehmen lediglich Verantwortung auf Infrastrukturebene. Alles was auf den höheren Ebenen passiert, liegt zu 100 Prozent im Verantwortungsbereich des Kunden.

Es ist somit eine falsche Annahme, die Public Cloud Anbieter wie Amazon Web Services, Microsoft Azure oder VMware (vCloud Air) als Full-Service-Provider zu betrachten und Ihnen die Verantwortung für den gesamten Stack – von der Infrastruktur bis hoch auf Applikationsebene – übertragen zu wollen. Stattdessen ist Selbstverantwortung gefragt!

Shared-Responsibility: So funktioniert IaaS-Management in der Public Cloud

Ein entscheidendes Detail der Public Cloud – was diese Deployment-Variante eindeutig vom Outsourcing abhebt – ist das Self-Service-Modell. Die Anbieter zeigen sich, je nach ihrer DNA, nur für bestimmte Bereiche verantwortlich. Für den Rest ist der Kunde zunächst selbst zuständig.

In der Public Cloud geht es also um die Aufteilung von Verantwortlichkeiten – auch als Shared-Responsibility- bezeichnet. Der Anbieter und Kunde teilen sich die Aufgabenbereiche untereinander auf. Die Eigenverantwortung des Kunden spielt dabei eine zentrale Rolle. Im Rahmen der IaaS-Nutzung ist der Anbieter für den Betrieb und die Sicherheit der physikalischen Umgebung zuständig, hierbei kümmert er sich um:

• den Aufbau der Rechenzentrumsinfrastruktur,
• die Bereitstellung von Rechenleistung, Speicherplatz, Netzwerk und einige Managed Services (wie Datenbanken) und ggf. andere Microservices,
• die Bereitstellung der Virtualisierungsschicht, über die der Kunde zu jeder Zeit virtuelle Ressourcen anfordern kann,
• das Bereitstellen von Services und Tools, mit denen der Kunde seine Aufgabenbereiche erledigen kann.

Der Kunde ist für den Betrieb und die Sicherheit der logischen Umgebung verantwortlich. Hierzu gehören:

• der Aufbau der virtuellen Infrastruktur,
• die Installation der Betriebssysteme,
• die Konfiguration des Netzwerks und der Firewall-Einstellungen,
• der Betrieb der eigenen Applikationen und selbstentwickelter (Micro)-Services.

Ein sehr ernst zu nehmender Bestandteil ist die Sicherheit. Der Kunde ist zu 100 Prozent für die Absicherung der eigenen Umgebung verantwortlich. Hierzu gehören:

• die Sicherheit der Betriebssysteme, der Applikationen und der eigenen Services,
• die Verschlüsselung der Daten, Datenverbindung als auch die Sicherstellung der Integrität der Systeme anhand von Authentifizierungsmechanismen sowie Identitäts- und Zugriffskontrollen auf System- und Applikationsebene.

Der Kunde ist somit für den Betrieb und die Sicherheit der eigenen Infrastrukturumgebung und den darauf betriebenen Systemen, Applikationen und Services sowie den gespeicherten Daten verantwortlich. Anbieter wie Amazon Web Services oder Microsoft Azure stellen dem Kunden jedoch umfangreiche Tools und Services zur Verfügung, mit denen sich z.B. die Verschlüsselung der Daten als auch die Identitäts- und Zugriffskontrollen sicherstellen lassen. Darüber hinaus existieren zum Teil weitere Enablement-Services (Microservices) mit denen der Kunde schneller und einfacher eigene Applikationen entwickeln kann.

Der Kunde ist in seinem Verantwortungsbereich somit auf sich alleine gestellt und muss dementsprechend Selbstverantwortung übernehmen. Stetig wachsende Partnernetzwerke können den Kunden dabei helfen, die virtuellen Infrastrukturen sicher aufzubauen und die Applikationen und Workloads auf den Clouds zu betreiben.

@CIO: Public Cloud bedeutet alte Zöpfe abzuschneiden

Einhergehend mit dem Verständnis für die Shared-Responsibility, erfordert die Nutzung von Public Cloud-Infrastrukturen ein Umdenken beim Design der Infrastrukturumgebung selbst und damit auch bei der Architektur der darauf entwickelten Applikationen und Services.

Der Self-Service lässt den Weg auf eine Public Cloud-Infrastruktur zunächst simpel erscheinen. Der Teufel steckt allerdings auch hier wieder einmal im Detail und verbirgt sich in der Komplexität die im ersten Moment nicht offensichtlich ist. CIOs sollten sich daher anfangs auf die folgenden Themen konzentrieren:

Das jeweilige Anbieter-Portfolio und die Eigenschaften seiner Plattform / -Infrastruktur verstehen lernen. Es hört sich einfach an. Tatsächlich entwickeln sich Public Cloud-Infrastrukturumgebungen aber mit einer rasanten Geschwindigkeit weiter. Hierfür ist es erforderlich, den Funktionsumfang und die Verfügbarkeit aller Services auf der Infrastruktur-Plattform zu kennen und seine Mitarbeiter fortlaufend zu schulen, um das volle Potential ausschöpfen zu können.
Einen „Grüne Wiese“ Ansatz inkl. Microservice-Architektur verfolgen. Public Cloud-Infrastrukturen folgen anderen Architektur- und Design-Konzepten, die sich vollkommen von denen unterscheiden, die noch vor kurzem gelehrt und implementiert wurden. Anstatt träge monolithische Applikationsklötze zu entwickeln, werden für Cloud-Infrastrukturen sogenannte Microservice-Architekturen eingesetzt, um autarke, voneinander losgelöste und einzeln skalierbare Applikationen zu entwickeln, die miteinander integriert eine vollständige Applikation ergeben. Dies sorgt für eine bessere Skalierbarkeit und Agilität und führt zu einer höheren Verfügbarkeit der gesamten Applikation.
„Design for Failure“ berücksichtigen. „Everything fails, all the time“ (Werner Vogels, CTO Amazon.com). Das Design einer Cloud-Applikation muss den Regeln und Eigenschaften des Cloud Computings folgen und die Hochverfügbarkeit berücksichtigen. Hierbei muss grundsätzlich darauf geachtet werden, einen Single Point of Failure zu vermeiden und zu berücksichtigen, dass zu jedem Zeitpunkt etwas schiefgehen kann. Das Ziel muss daher darin bestehen, dass eine Anwendung zu jederzeit funktioniert, auch dann, wenn die darunterliegende physikalische Infrastruktur des Anbieters in einen Fehlerzustand gerät. Die notwendigen Mittel und Services stehen dafür zur Verfügung.
Operational Excellence für die virtuellen Umgebung von Best Practices lernen. Führende Cloud-Nutzer, wie Netflix, zeigen auf beeindruckende Weise wie mit Selbstverantwortung bzw. Shared-Responsibility in der Public Cloud umzugehen ist. Netflix hat hierfür die „Simian Army“ entwickelt. Hierbei handelt es sich um ein riesiges Set an Tools und Services, mit denen u.a. der hochverfügbare Betrieb der virtuellen Netflix-Infrastruktur auf der Cloud der Amazon Web Services sichergestellt wird. Zalando geht mit seinem eigenen Framework STUPS.io einen ähnlichen Weg.
Managed Public Cloud Anbieter berücksichtigen. Die Komplexität der Public Cloud sollte nicht unterschätzt werden. Das gilt für den Aufbau der notwendigen virtuellen Infrastruktur, über die Entwicklung der Applikation bis hin zum Betrieb und der ganzheitlichen Implementierung der Sicherheitsmechanismen. Immer mehr Systemintegratoren wie die Direkt Gruppe, TecRacer oder Beck et al. Services spezialisieren sich auf den Betrieb von Public Clouds für ihre Kunden. Hinzu kommt, dass sich immer mehr Webhoster und MSPs wie Rackspace (dessen Fanatical Support nun auch Microsoft Azure unterstützt) zu Managed Public Cloud Providern transformieren. Und viele weitere werden folgen!
Die steigende Anzahl von Cloud-Migrationsprojekten bei großen mittelständischen Unternehmen und Großkonzernen zeigt, dass Cloud-Infrastrukturplattformen immer mehr zur neuen Normalität avancieren und dafür sorgen, dass alte Architektur-, Design- und Sicherheitskonzepte abgelöst werden. Nachdem Public Clouds über Jahre hinweg mit Nichtbeachtung gestraft wurden, erfreut sich auch diese Deploymentvariante einer steigenden Beliebtheit auf der digitalen Infrastrukturagenda von IT-Entscheidern. Diese  Cloud-Form wird sich jedoch nur bei denjenigen Unternehmen erfolgreich eingesetzt werden können,  bei denen sich das Mindset des CIOs verändert und das „Shared-Responsibility“-Konzept als gegeben angenommen wird.