Eine häufige Kritik an der Public Cloud lautet: „Ist man einmal drin, kommt man nie wieder raus!“. Aber stimmt dies wirklich? Wir haben einen Cloud-Architekten der ersten Stunde gefragt.
Zur Person
Marcel Gocke ist Software-Architekt und Cloud-Nutzer der ersten Stunde. Sein Glück: in den 2010ern lebte und arbeitete er in New York und konnte die aufkommenden Public Clouds nach Belieben ausprobieren und nutzen - unberührt von hiesigen Datenschutz- und Souveränitätsdebatten. Gepaart mit viel Erfahrung in klassischen IT-Landschaften im Enterprise-Umfeld, Open-Source-Softwares sowie Produkt-Entwicklung im E-Commerce, ist er der ideale Gesprächspartner für unsere Content-Reihe „Abhängigkeiten in der IT“.
Gregor: In der Matrix der Klebrigkeit haben wir aufgezeigt, wie schwer es für Unternehmen sein kann, sich von einem Public-Cloud-Ökosystem zu lösen. Ist die Situation wirklich so dramatisch?
Marcel: Wie immer ist die erste Antwort ‚‚Das kommt drauf an‘‘. Kleinere können sich von den Cloud-Ökosystemen häufig viel einfacher lösen und je größer du wirst, desto schwieriger wird es.
Gregor: Warum geraten besonders Konzerne und große Organisationen schnell in eine Cloud-Abhängigkeit?
Marcel: Da liegt vor allem an ihrer inneren Komplexität. Mit der Migration in das Cloud-Ökosystem beginnen sie ihre Regularien, ihre Prozesse und ihre Organisation in der IT-Landschaft abzubilden. Dafür gibt es viele gute Gründe: Unternehmen möchten sicherstellen, dass nur die richtigen Personen Zugriff auf Daten und Applikationen erhalten. Wenn zusätzliche Kosten entstehen, müssen Führungskräfte und Finanz-Controller eingebunden werden. Es gibt Nachweispflichten für Compliance, das Top-Management benötigt Reports und vieles mehr.
"Die Schwerfälligkeit nimmt gefühlt exponentiell mit der Größe des Unternehmens zu."
Diese Vielfalt der – manchmal auch selbstgewählten – Anforderungen verlangsamt einerseits die Migration in die Cloud, erhöht dann aber auch die Hürden, die gleiche Cloud wieder zu verlassen.
Diese Schwerfälligkeit nimmt gefühlt exponentiell mit der Größe des Unternehmens zu. Mit jeder Hierarchieebene gibt es komplexere Entscheidungsprozesse, mit jedem Portfolioelement gibt es mehr Compliance-Anforderungen, mit jeder gewünschten Synergie mehr Abstimmungsbedarf bei der Standardisierung. Da unterlassen es die Unternehmen häufig, ihre Prozesse zu entschlacken.
Gregor: Man könnte also sagen ‚‚selbst Schuld‘‘?
Marcel: Die großen Cloud-Ökosysteme tragen dazu natürlich bei, allerdings auf eine fast ironische Weise. Sie kennen den Bedarf ihrer Großkunden nach Zugangskontrolle, Kostenkontrolle, Prozessen und Transparenz sehr genau und haben mit der Zeit exzellente Angebote hierfür entwickelt. Beispiele bei Microsoft sind hier Purview, Active Directory und die Power Platform. Diese Services wiederum ziehen ihre Daten direkt aus IT-Kernleistungen, wie virtuellen Maschinen, Netzwerk und Identity-Management. Konzerne können auf diese Weise ein Maß an automatisierter Kontrolle und Transparenz erreichen, von denen die meisten Private Clouds nur träumen.
Möchten große Organisationen zurück in die eigene IT-Infrastruktur, dann müssen sie nicht nur migrieren, sondern die, bisher gemieteten, Errungenschaften neu aufbauen. Und da sie eben sehr komplex und schwerfällig sind, fällt ihnen das doppelt schwer.
Hätten die Hyperscaler ihre Großkunden also von Beginn an allein gelassen mit ihren Governance-Problemen, dann würde es diesen jetzt leichter fallen, in ihre eigene IT-Infrastruktur zurückzukehren.
"Hyperscaler tragen auf fast ironische Weise zur Abhängigkeit bei."
Gregor: Erkläre uns bitte einmal die Matrix der Klebrigkeit.
Marcel: Ich würde gerne in der Diskussion die drei Themen Infrastruktur, Middleware und Anwendungs-Software unterscheiden.
Im Bereich der Infrastruktur können Unternehmen u.a. ihre Wechselfähigkeit erhöhen, wenn sie sogenannte Container-Technologien nutzen. Der Begriff ‚‚Container‘‘ ist dabei tatsächlich der Schifffahrt entlehnt. Die Idee dahinter ist, dass Applikationen in eine Art ‚‚Container‘‘ gepackt werden, der nach außen hin so standardisiert ist, dass er einfach auf unterschiedliche IT-Infrastrukturen (‚‚Schiffe‘‘) umgeladen werden kann. Im Detail ist das wieder nicht so einfach, weil Cloud-Plattformen nicht genauso 100%ig standardisiert sind wie Schiffsplattformen. Aber das Container-Konzept vereinfacht die Migrationsfähigkeit von Applikationen deutlich. Daher haben wir IT-Infrastruktur eher unten links eingeordnet.
Dann gibt es die Middleware. Dazu gehören etwa Datenbanken oder Streaming-Services. Hier hat der Cloud-Kunde ein Spektrum von Optionen beginnend von proprietären Services des Hyperscalers (z.B. AWS Kinesis) über open-source-basierte Standard-Services des Hyperscalers (z.B. Amazon Managed Streaming for Apache Kafka), bis zum Eigenbetrieb des Open-Source Services Kafka auf AWS. Auf der einen Seite des Spektrums kann der Cloud-Kunde schnell skalierende Software entwickeln, eine Migration aber ist aufwändig und teuer – auf der anderen Seite ist es genau umgekehrt: Aufwändigeres Setup, Entwicklung und Betrieb, dafür einfachere Migration. Diese Services haben wir rechts/mittig eingeordnet auf der Matrix, denn es gibt viele Alternativen, aber die Migration ist dennoch aufwändig.
Als dritten Bereich sehe ich alle Services, in denen fachliche NutzerInnen unternehmensspezifische Prozesse und Inhalte abbilden. Dazu gehören die oben bereits genannten Governance-Services, aber auch Tools wie Miro. Viele dieser Tools enthalten unternehmenskritische Daten und Dokumentationen, für die wenigsten aber gibt es Standardschnittstellen oder -Formate, die eine Migration zu einem Wettbewerber erleichtern. Die Anzahl der Wettbewerber hier ist häufig gering, eine Migration würde sehr viel manuellen Aufwand erzeugen. Zudem werden die Tools sehr stark eingefordert von den NutzerInnen. Agile Coaches werden sehr leidenschaftlich, wenn es um Miro geht, ManagerInnen hängen ähnlich emotional an ihren Compliance-Reportings.
"Die wenigsten wissen wirklich, was sie meinen, wenn sie über Multi-Cloud reden."
Gregor: Wie sieht denn der Umgang mit dem Thema Lock-In in der Praxis aus?
Startups setzen meist auf ein Ökosystem und rennen los. Motto: Geschwindigkeit ist alles, und nach mir die Sintflut. Das macht für die auch Sinn, denn sie haben meist noch wenig Last auf ihren Systemen und müssen beim Pay-as-you-Go der Hyperscaler wenig zahlen. Einige davon werden erfolgreich, unter anderem dank genau der Vorteile der Hyperscaler. Sarah Wang vom VC-Fonds A16z hat hier eine spannende Analyse gemacht: Erfolgreiche cloud-basierte Unternehmen wie Slack oder Asana müssen 40-60% ihres Umsatzes direkt an die Cloud-Anbieter weitergeben. Bei solchen Grown-Ups, mit IT als Kerngeschäft, macht eine sogenannte Repatriation dann häufig Sinn. Es war dann aber kein Fehler, die Public Cloud zu nutzen, es handelt sich eher um ein Reifegrad-Thema.
Konzerne hingegen brauchen viel Zeit, um sich für eine Cloud zu entscheiden, häufig wegen langwieriger Datenschutz- und Compliance-Analysen. Sind sie dann erst einmal drin, wirken genau jene Datenschutz-Assessments wie ein Compliance-Lock-In. Wenn ich als EntwicklerIn erst mit Anwälten reden muss, bevor ich Multi-Cloud-Architekturen baue, bleibe ich lieber im bereits freigegebenen Ökosystem. Das spielt definitiv dem Platzhirsch in die Hände.
Gregor: Multi-Cloud hört man häufig als pauschale Lösung. Was hältst du davon?
Der Begriff kann vieles bedeuten. Ich wage die These, dass die wenigsten, die ihn verwenden, wirklich wissen, was sie damit meinen. Ich habe in meinem Leben schon EinkäuferInnen gesehen, die träumten von einem Bestellportal für virtuelle Maschinen. So ein Portal wie verivox, in dem ich einen Mietwagen spezifiziere, vergleiche und den Billigsten nehme.
Das geht völlig vorbei an der Realität von Software-Entwicklung und -Betrieb. Wie man in der Matrix oben sieht: Die Stickyness liegt gar nicht so sehr in der Infrastruktur. Und tausche ich lediglich die virtuellen Maschinen aus, bleibe aber in allen anderen Bereichen beim alten Ökosystem, dann komme ich in Teufels Küche. Hohe Migrationskosten, hohe Anpassungskosten in den nicht-migrierten Services, Latenzen, Kosten für Traffic, Ausbildung, Aufbau neuer Teams und vieles mehr. Und das alles für 5% Effizienzgewinne in der Infrastruktur?
"IT war nie frei von Lock-Ins"
Gregor: Für mich klingt es so, als sei ein Lock-In unvermeidbar, sobald ich in eine Public Cloud gehe?
Marcel: Ja, auf eine bestimmte Art und Weise schon. Aber um fair zu sein, war IT nie frei von Lock-Ins. Viele Banken und Fluggesellschaften sind noch in Mainframe-Architekturen der 1980er gefangen und Rechenzentrums-Migrationen im Vor-Cloud-Zeitalter dauerten in den 2010ern auch mehrere Jahre.
Daher empfehle ich allen ManagerInnen, die sich um Abhängigkeiten in der IT sorgen: Redet mit euren ArchitektInnen. Wenn klar ist, welche Abhängigkeiten vermieden werden sollen und in welche Richtung sich das Geschäft entwickelt, dann können wir das Gröbste verhindern. Wir vermeiden dann proprietäre Dienste und Tools, verwenden Standards, nutzen viel Open Source, erhöhen die Eigenleistung und ziehen Zwischenebenen ein. Das kostet dann Budget und Geschwindigkeit, aber es ist machbar.
Alles, was dann über den Horizont von 2-3 Jahren hinausgeht, ist in der IT ohnehin nicht planbar. Da hilft dann nur eigene Kompetenz und Flexibilität.
Gregor: Vielen Dank für das Gespräch!
