Randy Gupta ist seit 1995 in der Softwareentwicklung tätig. Seit 2011 liegt sein Schwerpunkt auf der Entwicklung und Umsetzung von Clou-Architekturen für internationale Konzerne, unter anderem aus den Bereichen Telekommunikation und Logistik. Seit 2009 ist er ehrenamtlicher Community Organizer der GDG Düsseldorf und wurde 2018 von Google als Google Developer Expert Cloud ausgezeichnet.
Randy, du bist Google Developer Expert und zertifizierter Google Cloud Architect und organisierst seit Jahren das Google Developer Cloud Meetup in Düsseldorf. Dein jüngster Vortrag zu dem Thema hieß "No Regrets – How to Use the Cloud without the Vendor Lock-In" – passenderweise nicht bei deinem eigenen Meetup gehalten, sondern beim Nürnberger AWS Developer Meetup.
Ich fange mal mit einer ganz naiven Frage an: Jahrelang war der Weg in die Cloud der heilige Gral der IT-Transformation. Wörtlich „grenzenlose“ Flexibilität und Skalierbarkeit waren zentrale Versprechen. Nun hat ein großer Teil der Unternehmen den Weg geschafft. Was ist denn jetzt schlimm daran, wenn sie sich dabei auf einen der großen Hersteller festlegen, die ja jeder für sich mehr Kapazitäten und mehr Services anbieten, als irgendein Kunde zu nutzen in der Lage wäre?
Randy: Es gibt eine ganze Reihe von Problemen, die ich mit der Beschränkung auf einen Anbieter habe oder bekommen kann. Zunächst mal die offensichtlichen Probleme beim "Vendor-Lock-in": Ich mache mich abhängig vom Angebot des Cloud Providers. Für mich wichtige Produkte werden vielleicht abgekündigt, oder Preise steigen deutlich im Vergleich zu anderen Anbietern. Dann gibt es juristische Fallstricke – darf ich zum Beispiel persönliche Daten von Nutzern aus einer bestimmten Region bei meinem Cloud-Anbieter speichern? Oder Einschränkungen der globalen Verfügbarkeit. Selbst AWS und Google sind nicht überall verfügbar, oder nah genug an meinen Nutzern, um niedrige Latenzen zu erreichen. Stichwort: Chinese Firewall. Und es gibt noch ein weniger offensichtliches Problem im B2B-Bereich: Manche meiner potentiellen Kunden wollen ihre Daten nicht bei bestimmten Anbietern sehen, weil sie sich in einer Konkurrenzsituation befinden – was sich natürlich auch erst im Laufe der Zeit ergeben kann. Grundsätzlich gilt also: Selbst, wenn ich es heute nicht unbedingt benötige, sollte ich für diese Situationen vorbereitet sein. Und ich steigere auch ganz einfach die Wiederverwendbarkeit meines Produktes, wenn ich es von vornherein Cloud-agnostisch plane.
Ok, es gibt also eine Reihe von Gründen, eine Multi-Cloud-Strategie zu nutzen. Was sind denn die großen Hindernisse – also womit mache ich es mir besonders schwer, meine Applikationen und Services einfach bei einem weiteren Cloud-Anbieter auszurollen?
Randy: Das sind zum einen proprietäre Technologien und APIs. Beispielsweise kann ich Serverless-Apps wie AWS Lambdas nicht ohne großen Aufwand in eine andere Cloud übertragen, weil allein schon die Orchestrierung mit anderen Services komplett anders läuft. Häufig sind es auch spezielle Technologien oder Sprachen (etwa .Net), die nicht überall verfügbar sind. Und dann gibt es natürlich proprietäre Services wie spezielle BI-Features eines Providers, die ich woanders nicht oder ganz anders vorfinde.
Brauche ich die Multi-Cloud-Strategie denn wirklich immer? Stichwort Kosten/Nutzen: Gibt es Fälle, in denen eine Multi-Cloud-Strategie eher nicht in Frage kommt und ich besser ein Vendor-Lock-in in Kauf nehme?
Randy: Natürlich gibt es manchmal spezielle Features oder Kostenmodelle, die nur bestimmte Anbieter haben (wie Analytics, spezielle Rechenkapazitäten oder Ähnliches), die vielleicht für meine Applikationen eine ganz wichtige Rolle spielen. Oder ich habe ein grundsätzlich regional orientiertes Unternehmen, bei dem ich praktisch ausschließen kann, irgendwann global auszurollen. Grundsätzlich macht es aber immer Sinn, auf Produkte und Services zu setzen, die möglichst durchgehend bei den verschiedenen Providern angeboten werden – die ich aber zur Not auch selbst betreiben kann. Ein konkretes Beispiel: Die PostgreSQL-Datenbank wird in allen großen Clouds als Managed Service angeboten. Ich kann es aber als Open Source auch selbst betreiben – wenn es unbedingt nötig sein sollte (normalerweise möchte ich das nicht – nicht nur die Risiken, auch die versteckten Kosten des Eigenbetriebs werden häufig unterschätzt).
Wenn es also Besonderheiten einzelner Anbieter gibt: Kann eine Multi-Cloud-Strategie dann auch "asymmetrisch" sein?
Randy: Nicht nur "kann" – de facto wird dies häufig genutzt. Ein gutes Beispiel ist BigQuery von Google – viele Kunden, die eigentlich auf AWS setzen, verwenden dies parallel.
Dann lass uns mal über das konkrete Projekt sprechen, das du in deinem Vortrag als Beispiel verwendet hast. Was waren dort die größten Pain Points und was die Hindernisse bei der Umsetzung einer Multi-Cloud-Strategie?
Randy: Die Pain Points haben wir im Grunde schon genannt – hauptsächlich Probleme juristischer Natur und hohe Latenzzeiten für Kunden in manchen Regionen, etwa China. Hindernisse – wenn man das so nennen kann – waren proprietäre Services, die genutzt wurden und nicht ohne größeren Aufwand migriert werden konnten. Im konkreten Fall Google Cloud Run als Serverless-Container- Runtime und Cloud Spanner sowie FireStore für die Daten- und Dokument-Persistenz. Auch das Cloud-Monitoring wurde direkt vom Provider genutzt und ließ sich nicht einfach übertragen. Die Architektur an sich war grundsätzlich sinnvoll, wenn man es auf rein technischer Ebene betrachtet. Aber sie führte zu den erwähnten Einschränkungen beim globalen Rollout inklusiver datenschutzrechtlicher Probleme, Latenzen etc. – und passte entsprechend nicht zu den Anforderungen des Business.
Zur Beseitigung der Hindernisse hast Du ein paar konkrete Maßnahmen vorgeschlagen. Kannst Du sie kurz beschreiben?
Randy: Zum einen haben wir von Cloud Run direkt auf Kubernetes als Abstraktionsschicht und Knative migriert. Damit haben wir eine Plattform, die wir ohne weitere Änderungen in andere Clouds übertragen können. Dann sind wir von FireStore auf Minio umgestiegen. Dazu war ein Code Refactoring notwendig, aufgrund der API-Änderungen. Minio verwendet aber die S3 API von AWS – diese ist also damit überall nutzbar. Die härteste Nuss war der Umstieg von CloudSpanner: Jeder einzelne DB-Zugriff musste refactored werden. CloudSpanner ist eine global konsistente DB (Multi-Master). Die Entscheidung war, PostgreSQL zu verwenden, da es hier mit CockroachDB ein Produkt gibt, das ebenfalls globale Konsistenz anbietet. Sprich: Mit PostgreSQL habe ich eine gute Basis, und wenn ich hohe Konsistenzanforderungen habe, nehme ich CockroachDB – ohne Änderungen am Code. Im Weiteren hat Google bereits angekündigt, zukünftig auch die PostgreSQL API mit Cloud Spanner zu unterstützen. Da könnte man natürlich überlegen, ob es Sinn macht, Cloud Spanner direkt über das PostgreSQL-API anzusprechen, wenn die Implementierung gut genug ist. Kommen wir zum Monitoring: Das basiert jetzt auf Prometheus und Grafana, die extrem weit verbreitet sind. Grafana Loki wird für Logs genutzt. Für das Tracing wird Grafana Tempo eingesetzt, zusammen mit dem OpenTelemetry Collector, der wiederum das zipkin-API nutzt und entsprechend kompatibel mit den meisten anderen Instrumentierungs-Libraries ist.
Auf der Grundlage dieser Maßnahmen hast Du dann die „Cloud Agnostic Toolbox“ zusammengestellt. Lass uns mal die einzelnen Werkzeuge und ihren Nutzen anschauen.
Randy: Kubernetes als Cluster-OS bildet die Basis. Für Block Storage, also ein Dateisystem mit Schreib-Lese-Zugriffen, wird – beim On-Premises-Betrieb – Rancher Longhorn oder OpenEBS verwendet, beim Cloud Provider das jeweilige Pendant, etwa AWS EBS oder Google PersistentDisk. Für Object Storage wird das S3-API genutzt. Auch hier stehen mit Minio und Rook wieder kompatible On-Premises-Implementierungen zur Verfügung; bei AWS ist es dann natürlich S3 selbst, bei Google CloudStorage usw. Über das Monitoring – Prometheus und Grafana – haben wir vorhin schon gesprochen. Was natürlich auch wichtig ist: Das ganze Setup sollte mittels Infrastructure-as-Code automatisiert sein; Terraform für den Aufbau der Infrastruktur, Helm für die Services auf Kubernetes, Packer für die VM Image-Erstellung.
Damit habe ich dann also ein Bündel von Werkzeugen, mit denen ich bei allen großen Cloud-Anbietern und auch on-premise meine Applikationen immer auf die – zumindest annähernd – gleiche Weise ausrollen kann. Als abschließende Frage: Kann ich jetzt noch einen Schritt weiter gehen, und bestimmte Dinge über die verschiedenen Clouds wieder zusammenführen? Also beispielsweise Monitoring, zentrale Code Repositories, aber auch Service Management, Kostenkontrolle etc.?
Randy: Grundsätzlich kann ich mit Prometheus Cloud-übergreifend inklusive on-premises Metriken einsammeln und zentralisiert auswerten (beispielsweise über Prometheus Exporter). Gleiches gilt für OpenTelemetry. Grafana Loki bietet direkt keine Federation an, ich kann aber Loki gegen ein gemeinsames S3-Backend laufen lassen, und dort die Log-Messages von verschiedenen Providern einsammeln. Auch für weitergehende Integration gibt es heute Angebote der großen Cloud-Provider. Beispielsweise bietet Google Anthos genau diesen Überblick über heterogene Cloud-Landschaften. Daneben gibt es auch Open-Source-Bibliotheken, die dies zumindest in Teilen unterstützen, wie etwa Eukalyptus für AWS-kompatible Implementierungen. Aber hier ist sicher noch viel Potential vorhanden.
Vielen Dank für das interessante Gespräch!
