Im ersten Teil dieses Beitrages wurden die verschiedenen Ansätze einer Cloudstrategie erläutert. Egal ob IaaS, PaaS oder gar SaaS – jedes Konzept beinhaltet Vorzüge, aber auch Risiken, die beim öffentlichen Diskurs zuweilen vernachlässigt – teilweise sogar bewusst verschwiegen werden. Dieser Diskurs ist nicht unbedingt im Interesse der großen Cloudanbieter und entspricht natürlich auch nicht deren Selbstdarstellung. Denn das übliche Cloud-Geschäftsmodell lässt sich eher als Einbahnstraße beschreiben: einfach und schnell rein in die Cloud und nur mit ganz großen Schmerzen wieder raus. Da verwundert es nicht, dass große Serviceprovider auf ihren Veranstaltungen teils die Gastredner vertraglich dazu verpflichten, den Begriff „Multi Cloud“ nicht zu verwenden.

Noch einmal rekapitulierend: Für kleine und mittelständische Unternehmen kann die umfangreiche Nutzung angebotener Services im Verhältnis zu erforderlichen Investitionen in eigene OnPremises-IT-Lösungen durchaus sinnvoll sein.
Eine Cloudstrategie im Enterprise-Segment entfaltet ihre Wirkung jedoch vor allem unter dem Aspekt der Flexibilisierung von IT. Und hier ist der altbekannte Vendor lock-in eines der Hauptprobleme der vergangenen Dekade. Dieser kann nicht nur zu hohen Kosten und starren Strukturen führen, sondern darüber hinaus auch noch hinderlich sein bei Innovationen und der Adaption neuer Technologien. Von daher richtet sich die folgende Skizze auch tendenziell an größere Unternehmen bzw. Konzerne, die sich für ein IT-Modell zur Wahrung der eigenen Unabhängigkeit entschieden haben.

Auf der grünen Wiese

Nehmen wir einmal an, man könnte eine IT-Infrastruktur designen, ohne dabei Rücksicht auf die Befindlichkeiten aller Protagonisten innerhalb einer Organisation nehmen zu müssen. Was wären die Wünsche an eine flexible, aber gleichermaßen effiziente IT-Infrastruktur? Eigentlich ist der erste Schritt relativ leicht, denn es gilt, all das zu vermeiden, was ein Unternehmen in die direkte Abhängigkeit eines Cloudproviders führt. So eine Abhängigkeit bedeutet mangelnde Flexibilität und potenziell auch höhere Kosten. Somit finden wir uns am Anfang der Betrachtung in einem klassischen IaaS-Ansatz- Ansatz (Iaas = Infrastructure as a Service) wieder. Storage, Computing und Netzwerk – diese drei wesentlichen Teile einer Infrastruktur lassen sich verhältnismäßig leicht austauschen, sofern die richtige Architektur darüber gewählt wurde. Um eine maximale Flexibilität zu erreichen, bietet sich eine Containertechnologie an. Dabei handelt es sich – einfach gesprochen – um eine etwas andere Ebene der Virtualisierung, da im Unterschied zur klassischen virtuellen Maschine (VM) nicht jeder Container sein eigenes Betriebssystem benötigt. In vielschichtigen Micro-Service-Infrastrukturen (viele Container bilden eine Systemlösung) kann das den Betrieb einer Lösung deutlich erleichtern, da sich zum Beispiel im Fehlerfall die Ursachen leichter eingrenzen lassen. Die Arbeit mit containerbasierten Applikationen gleicht dabei eher einem Baukastenprinzip, während die klassische VM jeweils einen vollständigen Server (mit allem, was dazu gehört) repräsentiert. Da das Baukastensystem per Design beliebig kompliziert werden kann, wird in der Realität immer ein Container-Orchestrierungstool eingesetzt. Kubernetes ist der wohl bekannteste Vertreter dieser Gattung und wird als quelloffenes Produkt von der Linux Foundation gemanagt. Man nutzt so ein System, um die unterschiedlichen Container-Laufzeitumgebungen (zum Beispiel Docker) zu managen. Innerhalb eines Clusters sorgt eine Orchestrierungsschicht dafür, dass immer die gewünschte Anzahl von Containern verfügbar ist. Sie stoppt und startet dabei selbständig Instanzen, managt also das System im Idealfall stark automatisiert.

Aber Achtung, schon hier verbirgt sich der erste potenzielle Fallstrick beim Aufbau einer multi-cloudfähigen Infrastruktur. Denn es ist essenziell, dass ein Kubernetescluster als Verbund über mehrere Cloudanbieter hinweg funktionsfähig ist. Da hilft es wenig, sich auf die durch einzelne Cloudanbieter angepassten Kubernetes-Services zu verlassen. An dieser Stelle ist man gut beraten, eigenes Know-how aufzubauen und sich selbst ein Deployment zu erstellen. Zur Unterstützung dieser Deployments kann zum Beispiel Helm (ein weiteres Projekt der Linux Foundation) eingesetzt werden, um Installation, sowie spätere Updates operativ leichter organisieren zu können. In Kombination mit einer Kubernetes-Architektur können hierbei insbesondere die automatischen Skalierungsmöglichkeiten der Plattform genutzt werden, um wechselnde Lastanforderungen optimal zu bedienen.

Copyright: Deepshore GmbH

Aus der Abbildung geht hervor, dass die Orchestrierungsschicht selbst verteilt in der Cloud betrieben werden kann. So bilden alle Instanzen zusammen einen System-Cluster. Besonders eignen sich natürlich verteilte Lösungen, die sich an den Grundlagen eines Micro-Service-Gedanken anlehnen. Sprich, solche Architekturen sind dafür gedacht, viele Containerfiles zu managen. Einen ERP-Monolithen in fünf riesige Container zu pressen und diese dann als Cloud-Service zu betreiben, ist sicherlich auch möglich. Man könnte dann als Hersteller sogar behaupten Cloud-ready zu sein. Mit etwas negativer Grundeinstellung könnte man diese Ansätze auch als „alten Wein in neuen Schläuchen“ bezeichnen.

Der Vorteil der skizzierten Strategie in Kombination mit verteilten, als Container ausgelieferten Systemkomponenten, ist sicherlich auch die Fähigkeit der Datenreplikation. Sich solche Mechanismen zu Nutzen zu machen, bedeutet gleichzeitig, in verteilten Systemen zu denken. Im Vergleich zu monolithischen Ansätzen besteht hier die Möglichkeit, entsprechende Standardmechanismen zu nutzen, um Daten über verschiedene Cloudprovider zu verteilen, ohne dabei ein logisches System zu verlassen (siehe nächste Abbildung). Das führt automatisch zu einer Situation, in der einzelne Container bzw. auch Cloudanbieter „abgeschaltet“ werden können, ohne das fachliche Gesamtsystem zu beeinträchtigen. Auch die Anbindung externer Applikationen (zum Beispiel Kunden oder Geschäftspartner) kann so flexibilisiert werden, da bei Bedarf unabhängige Einstiegspunkte in verschiedenen Infrastrukturen definiert werden können.

Copyright: Deepshore GmbH

Natürlich bieten zentrale Systeme (auch, wenn sie in der Cloud laufen) einige Eigenschaften, die für bestimmte fachliche Usecases von Vorteil sind. Relationale Datenbanken mit deren zugesicherter ACID-Transaktionalität bilden dafür ein bekanntes Beispiel. Im Bereich von besonders schützenswerten Daten (wie Tax Compliance) verlässt man sich heute immer noch gern auf diese bewährten Technologien, die auch als Cloudservice angeboten werden. Im Anbetracht der vorherigen Beschreibung stellt sich jedoch die Frage, welche Vorzüge diese SaaS-Modelle gegenüber IaaS-Ansätzen im Enterprise-Segment haben? Ja, man muss sich nicht mehr um Hardware und Patches kümmern, begibt sich aber vollständig in die Abhängigkeit des Cloudproviders und verkompliziert damit die Option einer zukünftigen Migration deutlich.

Es stellen sich also vier grundlegende Fragen:

• Warum will ich einen Cloudservice nutzen (Kosten, Qualität und/oder Flexibilisierung)?
• Was will ich in der Cloud betreiben?
• Wie will ich es in der Cloud betreiben?
• Welche kurzfristigen und langfristigen Konsequenzen hat das für meine IT, insbesondere im Bereich der Flexibilisierung?

Ein durchdachtes und gut geplantes Cloudkonzept ist absolut sinnvoll. Man ist allerdings gut beraten, das Kind nicht gleich mit dem Bade auszuschütten. Wie immer sind dogmatische Herangehensweisen auch in der Frage rund um Cloudservice nicht besonders hilfreich. Allzu häufig kommen Dogmen im Gewand einer „IT-Strategie“ mit einem bestimmten Fokus daher. Im Spannungsfeld von Kosten, Servicequalität und Flexibilisierung (oder auch das Vermeiden von Abhängigkeiten) ist nüchterne Sachlichkeit gefragt. Erklärt Ihnen ein IT-Architekt, dass eine pure Cloudstrategie mit einem großen Anbieter die einzig sinnvolle Alternative sei, kann eine zweite Meinung sicherlich keinen Schaden anrichten. „Handle stets so, dass sich die Zahl Deiner Möglichkeiten erhöht.“ Dieses Zitat von Heinz von Förster sollte sich jeder IT-Entscheider neben die PowerPoint-Folien seiner Berater legen, wenn es um die Strategie, also die langfristige Perspektive der eigenen IT geht.