Sie nutzen die Cloud? Dann aber auch richtig.

Viele unserer Kunden nutzen bereits die „Cloud“, um ihre Anwendungen dort bereitzustellen. Leider wird dabei sehr oft nicht das volle Potential von Cloud Computing ausgeschöpft, da typischerweise sehr wenige native und/oder proprietäre Dienste genutzt werden. Ein häufig genannter Grund ist der, dass sich die Kunden nicht von einem Cloud-Anbieter abhängig machen wollen. Daher werden nur Basis-Dienste genutzt, die bei allen Cloud Anbietern zur Verfügung stehen, um einen späteren Wechsel zu ermöglichen. In der Regel sind das die klassischen IaaS-Dienste für Compute, Storage und Network. Doch was sind die Gründe für dieses Verhalten? Einerseits befürchten Unternehmen, dass einzelne Cloud-Dienste durch den Cloud-Anbieter abgekündigt werden (oder komplette regionale Angebote, wie letztes Jahr im Fall der Deutschland Cloud von Microsoft) , was zu hohen Aufwänden für eine Migration der nutzenden Anwendungen führen kann. Andererseits wird den Cloud-Anbietern unterstellt, dass diese nach Erreichung signifikanter Marktanteile die Preise für bestimmte Dienste anheben könnten, was zu unplanbaren Belastungen der IT Budgets führen würde. Doch wie realistisch sind diese Befürchtungen? Betrachtet man sich beispielsweise die Entwicklung von Amazon Web Services (AWS) als führendem Cloud-Anbieter über die letzten Jahre, kann man feststellen, dass die Anzahl der bereitgestellten Services stetig zugenommen hat, aber keiner der existierenden Services aufgekündigt wurde. Uns erscheint das Abschalten eines Dienstes oder sogar ein vollständiger Rückzug eines der großen Hyperscaler kurz- bzw. mittelfristig als äußert unwahrscheinlich. Langfristig kann man hierzu selbstverständlich keine verbindliche Aussage treffen, wobei auch traditionelle Softwareanbieter wie IBM, Microsoft oder Oracle eigene Produkte bzw. ganze Produktfamilien abkündigen. Dies geschieht aber selten über Nacht, sondern erst nach entsprechender Ankündigung und Vorlaufzeit. Warum sollte es sich in der Cloud anders verhalten? Der oben erwähnte Spezialfall der Microsoft Azure Cloud mit deutschem Datentreuhänder-Konzept dient hier unseres Erachtens als Ausnahme, die die Regel bestätigt.

Wie aber schützt man sich gegen steigende Preise oder andere negative „Lock-In“-Effekte bei Verwendung eines speziellen Dienstes? Native und proprietäre Cloud-Dienste überhaupt nicht zu nutzen erscheint uns als der falsche Weg. Hier empfehlen wir analog zum Thought Works Tech Radar, dass man die Chancen der Nutzung eines innovativen Services den Risiken und Kosten gegenüberstellen muss, die entstehen, wenn der Provider die Preise erhöht oder man den Anbieter wechseln möchte. Sollte ein Dienst eines Cloud-Anbieters tatsächlich sehr stark preislich ansteigen, besteht grundsätzlich die Möglichkeit, den gleichen Dienst eines anderen Cloud-Anbieters zu nutzen. Sie sind der Meinung, das ist nicht möglich? Ganz im Gegenteil: Aus unseren Erfahrungen ist sogar ein Wechsel des Cloud-Providers inklusive des PaaS-Layers (beispielsweise ein Ersetzen von Cloud Foundry durch Kubernetes) mit vertretbarem Aufwand möglich, wenn man einige grundsätzlichen Randbedingungen wie den notwendigen Skillaufbau für den Einsatz der neuen Technologie beachtet. Auch ein Wechsel des Cloud-Anbieters inklusive Programmiersprache im Bereich Serverless Computing konnte im Rahmen von ein bis zwei Sprints problemlos realisiert werden.

Natürlich verursacht die gleichzeitige Verwendung von Services unterschiedlicher Cloud-Provider (der sogenannte Polycloud Ansatz, heute auch gerne in anderem Kontext als Multi-Cloud bezeichnet) im Rahmen einer Applikation auch unerwünschte Effekte wie z.B. Latenzen und zusätzliche Sicherheitsrisiken. Beispiel: die Migration einer Datenbank Komponente zu Cloud Anbieter A, bei gleichzeitigem Verbleib des Applikations-Servers bei Anbieter B, war technisch problemlos machbar, führte aber zu einem nicht zufriedenstellenden Antwortzeitverhalten der Applikation aus Endbenutzer-Sicht. Die Lösung bestand in diesem Fall darin, sich für einen der Anbieter zu entscheiden. Die Portierbarkeit der Applikation war dennoch unter Beweis gestellt.

Viele Dienste in der Cloud stehen bei sämtlichen Cloud Anbieter fast baugleich zur Verfügung. Als Beispiel sei hier ein relationaler Datenbankservice, Elastic Search oder eine Container-Runtime wie Kubernetes genannt. Unterschiede existieren lediglich in der Art der Authentifizierung und dem Verbindungsaufbau, der Provider-spezifische Aspekte umfasst. Die stellen aber im Vergleich mit der Geschäftslogik nur einen Bruchteil der Funktionalität dar, so dass im Falle eines Wechsel des Cloud Providers auch hier keine großen Hürden zu erwarten sind. Ein klein wenig anders verhält es sich mit Services, wie beispielsweise im Bereich der NoSQL- Datenbanken oder dem Maschine Learning, in denen keine vollständig standardisierten Schnittstellen zur Verfügung stehen. Hier kann man durch Entkopplung des Services von der Geschäftsanwendung (Einsatz eines Anti-Corruption Layers) versuchen, die Aufrufe des Services innerhalb einer Abstraktionsschicht zu bündeln, um einen späteren Austausch zu erleichtern. Wie aufwändig der Wechsel des Cloud Anbieters in diesem Falle ist, ist sehr stark davon abhängig ob die nicht-standardisierten Service-Schnittstellen eine ähnliche Semantik und Struktur aufweisen. Zukünftig kann man sich hier noch Verbesserungen versprechen, da aktuell an einem Standard (ISO/IEC 19941:2017) zur Interoperabilität und Portabilität von Cloud Plattformen gearbeitet wird. In einem Microsoft Blog lässt sich hierzu folgende Aussage finden:

In order to attract new customers who may already be using a competing service, cloud computing companies like Microsoft are making significant efforts into achieving interoperability and portability. To advance better understanding of the technical complexities of this topic, a new international standard (ISO/IEC 19941) has been written by international cloud computing experts, many of them based in the EU.

Ein weiterer Aspekt, warum einige Kunden Cloud-Dienste nicht nutzen, sind Sicherheitsbedenken. Nachdem das Thema Sicherheit in einem unserer kommenden Blog-Beiträge zum Cloud-Computing spezifisch behandelt wird, sei hier nur der Hinweis gegeben, dass Cloud-Dienste der führenden Hyperscaler von Grund auf unter Berücksichtigung umfassender Datenschutz- und Datensicherheits-Gesichtspunkte von Experten auf ihrem Gebiet entwickelt wurden. Deshalb sollte sich aus unserer Sicht jeder Entscheider die Frage stellen: Bin ich innerhalb meines Unternehmens in der Lage, Dienste resilienter und sicherer bereitzustellen als einer der großen Cloud-Anbieter? Unsere Erfahrungen deuten eher nicht darauf hin.

Unabhängig davon, aus welchem Grund die nativen oder (vermeintlich) proprietären Dienste eines Cloud-Anbieters nicht genutzt werden, besitzt dieses Vorgehen den Nachteil, dass Unternehmen in der Konsequenz diese Dienste selbst aufbauen und selbst betreiben – entweder in der Cloud, aufsetzend auf reinen Infrastrukturkomponenten, oder gar im eigenen Rechenzentrum. Hier haben wir die Erfahrung gemacht, dass es für ein Unternehmen sehr schwierig ist, das entsprechende Know-How dafür vorzuhalten, und teuer, es einzukaufen. Selbst wenn das Know-How im Unternehmen vorhanden ist, wird dadurch die Umsetzungsgeschwindigkeit von Vorhaben erheblich beeinflusst, da in der Regel signifikante Aufwände für die initiale interne Bereitstellung und adäquate Security, aber auch für kontinuierliche administrative Arbeiten, wie die Durchführung von Versionsupdates, für die Dienste anfallen. Diese Kapazitäten wären sinnvoller in die Entwicklung der eigenen Geschäftslogik investiert.

Und wie wäre es, das Beste aus beiden Welten zu nutzen? Also eine Private Cloud, bei der ich mich als Unternehmen nicht von einzelnen Anbietern abhängig mache, und allen Sicherheitsbedenken in eigener Hoheit Rechnung tragen kann, mit dem vollen Nutzen der Flexibilität und Elastizität echter Cloud-Dienste für meine Anwendungen? Auch diesen Aspekt wollen wir in einem separaten Blog-Beitrag noch detaillierter diskutieren. Soviel sei verraten: die meisten der oben genannten Nachteile eines Nachbaus von Cloud-Diensten in Eigenregie gelten auch für einen Private Cloud Ansatz, und die Nachhaltigkeit einer derartigen Investition muss langfristig gedacht werden. Auch die Abkündigung einer haus-internen Private Cloud kann für die Applikationsverantwortlichen schlaflose Nächte bedeuten.

Als Fazit bleibt festzuhalten, dass es aus unserer Sicht nicht sinnvoll ist, wenn existierende, erprobte Cloud-Services, unabhängig davon ob zum PaaS- oder SaaS-Angebot eines Cloud Providers gehörend, aus dogmatischen Erwägungen heraus nicht genutzt werden. Wenn auf die Nutzung dieser Dienste verzichtet wird, handeln sich viele Unternehmen damit, nach unserer Beobachtung, gravierende Nachteile in Form von reduzierter Agilität und erhöhten Kosten ein, da der Aufbau und der Betrieb dieser Dienste über kurz oder lang stattdessen vom eigenen IT Betrieb durchgeführt werden muss. Die Risikoabwägung gegen potentiell anfallende Exit- und Migrations-Kosten hat natürlich zu erfolgen, aber mit dem notwendigen Augenmaß eines erfahrenen Architekten und unter Berücksichtigung aller Opportunitätskosten.