Martin Loschwitz: Die Verwaltung von privaten und Public Clouds sind ja grundsätzlich zwei völlig unterschiedliche Dinge. In der Public Cloud abstrahiert der Anbieter die gesamte Physik – der Admin muss sich um diese also gar nicht erst kümmern. Stattdessen verwaltet er "nur" seinen virtuellen Workload. Bei privaten Clouds ist das anders, denn hier muss der IT-Verantwortliche die gesamte Infrastruktur ebenfalls betreiben: Skalierbares Netz, skalierbarer Speicher, redundante Anbindung in Sachen Internet und Strom, Automation der Systeme, Wartung und Updates, Ausfälle bei der Hardware – das Ausmaß der Arbeit ist nicht zu vergleichen. Der richtige Betrieb der Physik ist bei privaten Clouds sicherlich die größte Herausforderung. Bei Public Clouds ist aus Admin-Sicht das größte Thema der Vendor-Lock-in einzelner Anbieter. Wenn ein Workload erfolgreich bei AWS läuft, lässt er sich vermutlich nicht problemlos zu Azure umziehen. Und hybride Workloads funktionieren oft gar nicht.

Für kleine und mittelständische Unternehmen dürfte die Public Cloud die einzige nachhaltige Variante sein, um die Cloud effizient zu nutzen. Ich persönlich kenne unzählige kleine Unternehmen, die am Betrieb privater Cloudumgebungen gescheitert sind. Hier mangelt es oft schon an der sinnvollen Bedarfserhebung im Vorfeld: Welche Dienstleistung ist notwendig? Geht es nur um Virtualisierung on demand, dann ist ein einfacher Virtualisierer wie oVirt vielleicht die bessere Option. Denn dies lässt sich mit deutlich weniger Personal bauen und betreiben. Kritiker mögen hier jetzt einwenden, dass der Reiz einer privaten Cloud durch Automation doch gerade darin liegt, viele Ressourcen mit wenigen Leuten betreiben zu können. Das stimmt, aber es ist ein Rumpfteam in bestimmter Größe nötig, um das initiale Setup zu schaffen. Und die "Economy of Scale" wird nur erreicht, wenn das Setup schnell wächst – was in privaten Clouds oft gar nicht der Fall ist. Hier ist also eine sorgfältige Abwägung im Vorfeld wichtig.

SLAs vor der Buchung einer Public Cloud zu lesen und zu verstehen ist von essenzieller Bedeutung, weil gerade die SLAs bei den großen Anbietern anders funktionieren als die in klassischen Virtualisierungsumgebungen. Wer die Cloud nur als Fortsetzung von KVM mit anderen Mitteln sieht und den Workload konventioneller VMs in eine Public Cloud migriert, wird kaum glücklich werden. Das Hauptaugenmerk muss stattdessen auf den Fragen liegen, welche Redundanzen ein jeweiliger Anbieter im Portfolio hat und wo eine Applikation durch Hochverfügbarkeit auf der Programmebene möglicherweise selbst eingreifen muss. AWS ist dafür ein perfektes Beispiel: In den SLAs finden sich viele wohltuende Versprechungen und sogar Vertragsstrafen, falls AWS seine Dienste nicht "online" hält. Was "online" allerdings heißt, ist sehr schwammig definiert. Ist der Admin etwa zu einem bestimmten Zeitpunkt in der Lage, einen abgestürzten Workload irgendwo anders in AWS zu starten, nachdem eine Region ausgefallen ist, gilt das nicht als "Downtime". Im Vorfeld gilt ganz klar: Testen, evaluieren, ausprobieren.

Zum Teil besteht die Möglichkeit, per API an die Daten zu kommen – das gilt spezifisch für die Dienste, die Daten in Form binärer Objekte exponieren, etwa Amazon S3. Ebenso per API erreichbar sind oftmals die Dienste, die persistenten Speicher für virtuelle Instanzen anbieten, wie Amazon EBS. Ob es hier einen Weg gibt, die Daten unmittelbar per API zu exportieren, ist allerdings fraglich. Grundsätzlich gilt: Wenn Unternehmen bestimmte As-a-Service-Angebote haben, um Daten zu verwalten, ist es sinnvoll, diese zu verwenden. Wer etwa NFS-as-a-Service nutzt, bekommt eine API-Schnittstelle zum Zugriff auf die Daten hinzu. Das steigert zwar wieder die Abhängigkeit vom jeweiligen Anbieter, ist in der Regel aber deutlich effizienter, als eine VM mit den jeweiligen Diensten selbst zu verwalten. Das beschriebene Problem ist übrigens einer der Gründe dafür, dass das europäische Cloudprojekt GAIA-X überhaupt existiert. Hier geht es auch darum, generische, offene APIs zu schaffen, die nicht so sehr für IaaS zur Verfügung stehen sollen, sondern für den API-basierten, strukturierten Austausch von Daten. Ob GAIA-X die Situation absehbar verbessert, muss sich allerdings erst herausstellen.

Monitoring ist meiner Erfahrung nach eines der Themen, die durch die Cloud eher schwieriger und komplexer handzuhaben geworden sind. Ich rate grundsätzlich dazu, Monitoring über eigens ausgerollte Dienste zu realisieren, etwa Prometheus mit Grafana. Die können dann durchaus an die APIs der Cloud andocken und dort verschiedene Laufzeitwerte auslesen. Der Ansatz garantiert aber, dass ich eine offene, generische Monitoringschnittstelle in Form von Prometheus habe, die sich mit beliebigen Daten anreichern lässt. Alternativen wie InfluxDB sind natürlich auch eine Möglichkeit, der Admin sollte aber darauf achten, dass es sich um eine Monitoring-Alerting-Trending-Lösung handelt. Denn Trending ist in Clouds ein essenzielles Thema mit technisch sehr ähnlichen Voraussetzungen.

Aber sowas von! Mir sind mehrere Geschichten bekannt, bei denen IT-Abteilungen und KMUs plötzlich Rechnungen von Amazon & Co.über Tausende Euro für "vergessene" Dienste ins Haus flatterten. Admins müssen sich hier einfach am Riemen reißen und bei Tests und Experimenten ihre Ressourcen sorgfältig wieder abräumen. Und grundsätzlich gilt: Public Clouds werben mit niedrigen Preisen, aber Unternehmen sollten die voraussichtlich anfallenden Kosten der Ressourcennutzung in Clouds trotzdem im Vorfeld sorgfältig kalkulieren. Denn ansonsten droht ein böses Erwachen. Eine hochperformante AWS-Instanz, wie viele sie sich für eigene Anwendungen wünschen, schlägt problemlos mit etlichen Hundert Euro pro Monat zu Buche.

Praktisch alle Public Clouds bieten Werkzeuge und Tools inklusive Warnfunktionen an, um aus dem Ruder laufende Rechnungen zu vermeiden. Diese "Guardrails" sollten Unternehmen ausgiebig nutzen, um böse Überraschungen zu vermeiden. Compliance-Werkzeuge, wie die Clouds sie einerseits bieten und wie sie mit Werkzeugen wie Chef InSpec andererseits implementierbar sind, sollten die laufenden Ressourcen zudem kontinuierlich überwachen und Alarm schlagen, falls die laufenden Ressourcen von einer zuvor genehmigten Liste abweichen.

Ich würde behaupten, dass es nicht so sehr das Wissen ist, das sich ändert, sondern vor allem der Aufwand. Der Wechsel von lokalem Blech in eine Public Cloud ist ja im Grunde der Deal, gegen Einwurf von Münzen selbst den Betrieb von Infrastruktur nicht mehr organisieren zu müssen. Und wer schon einmal Rechenzentren und physische Setups gebaut hat, weiß: das ist eine hochkomplexe, schwierige Aufgabe mit vielen Möglichkeiten, so richtig ins Klo zu greifen. Wer eine eigene Virtualisierungsplattform oder auch ein nicht-virtualisiertes Setup betreiben möchte, braucht Fachleute für Storage und Netzwerk und klassische Systemadministration. Wer hingegen vorrangig in der Public Cloud operiert, braucht vor allem gute Systemverwalter, deren Wissen die grundlegenden Aspekte von Storage und Netzwerk ebenfalls abdeckt, Hinzu kommt Spezialwissen wie jenes in Sachen Automation und Orchestrierung, ohne das Clouds nicht sinnvoll zu nutzen sind. Das Anforderungsprofil ist insofern tatsächlich ein anderes, aber kein wesentlich weniger komplexes.

Insbesondere Nutzdaten, also der Inhalt von Datenbanken, Speicherlaufwerken – alles, was per Automation aus dem Netz nicht wieder herstellbar ist –, sind regelmäßig und automatisiert verschlüsselt an einem anderen Ort und am besten in einem Setup eines anderen Anbieters zu hinterlegen. Wer seine VMs in Azure hostet, sollte Backups automatisiert in Amazon S3 erstellen. Wer Speicher wie Ceph nutzt, kann entsprechende Features eventuell auch auf der Applikationsebene verwenden. Das gilt übrigens unabhängig davon, wo die Daten herkommen und für welchen Teil des hybriden Setups sie notwendig sind. Darüber hinaus gilt: Egal, wo ich welche Teile des Workloads betreibe – alles, was nicht automatisiert ist, existiert auch nicht. Es bringt dem Admin gar nichts, nach einem katastrophalen Ausfall eines Teils der Infrastruktur anzufangen, Instanzen mühsam zu rekonstruieren. Das "Immutable Underlay" ist stattdessen nötig: Instanzen kommen aus Images oder aus Ansible, Chef et cetera und Nutzdaten sind schnell aus dem Off-Site-Backup zu holen.

Der Widerspruch zwischen DSGVO und amerikanischem CLOUD-Act ist bis heute ein Problem, das vielen Unternehmen Bauchschmerzen bereitet. Ich bin kein Anwalt und kann die Situation rechtlich insofern nur bedingt einordnen. Ganz grundsätzlich rate ich Unternehmen aber dazu, bei der Suche nach einem Platz in der Cloud nicht nur amerikanische Angebote wie GCP, Azure oder AWS zu evaluieren, sondern sich auch mit den durchaus vorhandenen europäischen Alternativen zu befassen. Im Sinne einer europäischen Datensouveränität ist das ohnehin notwendig und angezeigt. Manche Unternehmen machen zudem gute Erfahrungen mit dem Ansatz, bestimmte Arten von Daten nur noch verschlüsselt in der Cloud zu speichern. Dann hätte "Uncle Sam" im Falle eines Falles zwar den Inhalt von Festplatten von Cloudservern, könnte damit aber nichts anfangen. Die jeweilige Anwendung muss solch ein Modell allerdings unterstützen.