Viele Clouds, viele Probleme? Muss nicht sein. Wir haben Experten gefragt, wie Multicloud in der Praxis geht.Juice Flair | shutterstock.com Multicloud-Architekturen versprechen das Beste aus sämtlichen Welten, indem sie es ermöglichen, spezielle Funktionen mehrerer Anbieter zu nutzen. Die Voraussetzung dafür sind allerdings Entwicklungsprozesse, die dazu geeignet sind, die mit einem Multicloud-Ansatz einhergehenden Herausforderungen und Komplexitäten zu bewältigen. Denn im Vergleich zu traditionellem Cloud Computing erfordert es strategische, architektonische und operative Umstellungen, um Code zu schreiben, der zuverlässig in mehreren verschiedenen Cloud-Instanzen läuft. Dazu gilt es, sämtliche Parts des Entwicklungsprozesses weiterzuentwickeln – von der Container-Orchestrierung über Observability bis hin zu internen Tools. Wie sich das in der Praxis ganz konkret umsetzen lässt, dazu haben wir erfahrene Cloud-Experten befragt. Diese geben dabei nicht nur Auskunft über ihre Erfolge, sondern auch über ihre Fails – beziehungsweise die daraus gelernten Lektionen. Kommunikation & Strategie Bevor Entwicklungsteams auch nur eine Zeile Code für Multicloud-Umgebungen schreiben, muss klar sein, warum. Darüber aufzuklären, sieht Drew Firment, Chief Cloud Strategist beim E-Learning-Anbieter Pluralsight, als Aufgabe des Managements an: “Multicloud ist kein Thema für Entwickler. Es handelt sich um ein strategisches Problem, das ein klares Cloud-Betriebsmodell erfordert. Dieses sollte klar definieren, wann, wo und warum Entwicklungsteams bestimmte Cloud-Funktionen nutzen.” Ohne ein solches Modell riskierten Unternehmen hohe Kosten, Sicherheitsprobleme und letztendlich den Projekterfolg, warnt Firment. Er empfiehlt an dieser Stelle mit einem strategischen Framework zu beginnen, das auf die Geschäftsziele abgestimmt ist und zudem klare Verantwortlichkeiten für Multicloud-Entscheidungen zuweist. Dieser Prozess sollte jedoch nicht nur Top-Down verlaufen. Deshalb ist für Heather Davis Lam, Gründerin und CEO der IT-Beratung Revenue Ops, abteilungsübergreifende Kommunikation in diesem Zusammenhang unabdingbar: “Sprechen Sie miteinander. An Multicloud-Projekten sind Entwickler, Betriebsspezialisten, Security-Profis und manchmal auch die Rechtsabteilung beteiligt. Die Probleme entstehen dabei in der Regel durch Missverständnisse, nicht durch schlechten Code. Regelmäßige Check-ins und ehrliche Gespräche sind deshalb enorm hilfreich wenn es um Multicloud-Projekte geht.” Dieser Planungsprozess sollte die Frage klären, warum Multicloud für das Unternehmen ein geeignetes Konzept ist und wie die spezifischen Plattformen innerhalb der Infrastruktur optimal genutzt werden können. Umgebungspluralität Das Multicloud-Entwicklungsteam wird sich in weiten Teilen vor allem mit der Frage beschäftigen, wann und wie Cloud-agnostischer oder plattformübergreifender Code geschrieben werden sollte. Dabei versuchten nicht wenige Teams, ihren Code vollständig Cloud-portabel zu gestalten, meint Gründerin Lam: “Das ist eine schöne Idee, aber in der Praxis kann sie zu Overengineering und noch mehr Kopfzerbrechen führen. Wenn das Team damit anfängt, zusätzliche Layer aufzubauen, nur damit alles funktioniert, ist es an der Zeit, innezuhalten.” Das kann Patrik Dudits, Senior Software Engineer bei der Open-Source-Company Payara Services, aus eigener Erfahrung bestätigen: “Der Versuch, die Architektur auf den ‚kleinsten gemeinsamen Nenner‘ zu beschränken, ist ein gängiger Fehler. In der Praxis ist es deutlich erfolgversprechender, die jeweiligen Stärken der einzelnen Clouds zu nutzen.” Damit meint der Softwareentwickler, Systeme mit Blick auf ihre Autonomie zu entwickeln, um Services unabhängig in ihren jeweiligen Clouds zu betreiben – ohne eine zu enge Kopplung entstehen zu lassen. Dieses Prinzip spielt auch im Ansatz von Matt Dimich, VP of Platform Engineering beim Medienkonzern Thomson Reuters, eine tragende Rolle: “Unser Ziel ist es, die Plattform, auf der wir unsere Anwendungen ausführen, agil zu gestalten. Jedes Jahr kommen neue Innovationen und Rechenleistung wird immer kostengünstigerer. Je schneller wir das nutzen können, umso mehr Wert können wir für unsere Kunden generieren.” Die ultimative Multicloud-Herausforderung besteht laut Pluralsight-Manager Firment darin, Cloud-Fähigkeiten zu optimieren, ohne dabei Chaos zu verursachen: “Die erste Faustregel lautet, die gemeinsamen Kernservices, die in allen Clouds vorhanden sind, zu abstrahieren und gleichzeitig Cloud-spezifische Services, die einen einzigartigen Kundennutzen bieten, zu isolieren. Nutzen Sie beispielsweise einen standardisierten Authentifizierungs- und Compute-Layer für alle Clouds und optimieren Sie gleichzeitig mit AWS-spezifischen Tools wie S3 oder Athena die Kosten und die Query-Performance bei großen Datensätzen.” Das deckt sich mit der Empfehlung von Gründerin Lam: “Halten Sie die Kerngeschäftslogik portabel – APIs, containerisierte Anwendungen, gemeinsame Sprachen wie Python oder Node – dort ist Portabilität wirklich wichtig. Geht es hingegen um Infrastruktur oder Orchestrierung, würde ich dazu raten, auf das zu setzen, was die jeweilige Cloud am besten kann.” Plattformübergreifender Code Der Schlüssel, um die Kerngeschäftslogik Cloud-übergreifend so portabel wie möglich zu gestalten, ist für so gut wie alle unsere Gesprächspartner die Container-Orchestrierungsplattform Kubernetes. Diese empfiehlt zum Beispiel auch Radhakrishnan Krishna Kripa, leitender DevOps-Ingenieur beim Entwicklungsspezialisten Ansys, um Bereitstellungen zu standardisieren: “Indem wir Kubernetes und Docker Container einsetzen, können wir den Code einmal schreiben und ihn anschließend mit minimalen Änderungen in AKS, AWS EKS oder sogar in lokalen Clustern ausführen.” Mit diesem Ansatz rennt Kripa bei Sidd Seethepalli, CTO und Mitbegründer des KI-Unternehmens Vellum, offene Türen ein: “Wir verlassen uns auf Kubernetes statt auf anbieterspezifische Services. So können wir Kubernetes-Cluster überall konsistent bereitstellen, wo sie benötigt werden.” Neil Qylie, Principal Solutions Architect bei der IT-Beratung Myriad360, betrachtet Kubernetes ebenfalls als gute Grundlage: “Indem wir auf Kubernetes aufbauen, können wir Anwendungsdefinitionen und -Deployments mit Helm standardisieren. Der Rollout lässt sich in der Regel über einen GitOps-Workflow mit Tools wie ArgoCD automatisieren.” Dieser Ansatz biete laut Qylie “echte Workload-Mobilität” und gewährleiste parallel konsistente und validierte Deployments über CI/CD-Pipelines. Apropos CI/CD: Diese Tools sind ebenso wichtig wie die Infrastruktur, auf der der Code läuft. Kripa empfiehlt, diese mit Hilfe Cloud-neutraler Tools wie GitHub Actions oder Terraform zu standardisieren: “Wir nutzen hauptsächlich Azure, aber Tools wie GitHub Actions ermöglichen es uns, Builds und Infrastruktur über mehrere Umgebungen hinweg mit einem konsistenten Workflow zu managen. Das trägt dazu bei, die Belastung für die Entwickler bei einem Anbieterwechsel oder einem Deployment in hybriden Umgebungen zu reduzieren.” Unabhängig davon, wie stark Sie Ihren Code standardisieren, müssen Sie dennoch mit den APIs und SDKs der einzelnen Cloud-Anbieter interagieren. Um das ohne Portabilitätseinbußen zu realisieren, hat Anant Agarwal, Mitbegründer und CTO des Softwareunternehmens Aidora, ein Pattern entwickelt: “Wir behandeln jede Cloud-API und jedes SDK wie eine Abhängigkeit: Wir verpacken sie in eine interne Bibliothek und stellen dem Rest der Codebasis eine saubere, generische Schnittstelle zur Verfügung. So bleibt die Cloud-spezifische Logik isoliert und austauschbar, die Kernlogik der Anwendung ist hingegen einfacher zu warten und wird widerstandsfähiger gegen Plattformabhängigkeiten.” Insbesondere dort, wo proprietäre Cloud-Funktionen in der Vergangenheit zu Reibungsverlusten geführt haben, helfe die Open-Source-Community dabei, die Lücken zu schließen, meint Qylie und verweist auf das Serverless-Workflow-Projekt. “Ich behalte die CNCF-Landschaft stets im Auge. Es gibt regelmäßig neue Projekte, die genau diese ‚Knackpunkte‘ adressieren”, so der Entwickler. Komplexitätsbewältigung Heterogene Multi-Cloud-Umgebungen sind komplex. Diesen Umstand sollte auch der Entwicklungsprozess berücksichtigen – insbesondere, wenn es um Sichtbarkeit geht. Der erste Schritt sollte entsprechend darin bestehen Logs und Alerts zu zentralisieren – so wie es auch bei Aidora geschieht: “Wir leiten sämtliche Protokolle an eine einheitliche Observability-Plattform weiter und erstellen eine konsolidierte Ansicht. Bei neueren Tools alles komplett abzudecken, ist schwierig, aber dieser Ansatz unterstützt uns dabei, Vorfälle schnell zu triagieren und dabei Transparenz über alle Cloud-Anbieter hinweg zu gewährleisten.” Diese Vorgehensweise empfiehlt auch Payara-Chefentwickler Dudits: “Es macht Sinn, in ein zentrales, anbieterunabhängiges Dashboard mit hochwertigen Metriken für die gesamte Multicloud-Umgebung zu investieren. Das erleichtert es, anbieterübergreifende Probleme zu erkennen – auch wenn tiefgehendere Analysen weiterhin über anbieterspezifische Tools laufen.” RevenueOps-CEO Lam schreibt hochwertigen Logging-Tools mit Blick auf Multicloud-Umgebungen eine besondere Bedeutung zu: “Es ist schon schwierig genug, eine Cloud zu debuggen. Wenn Sie mit drei oder vier Clouds arbeiten, können Sie mit einem guten Logging- und Monitoring-Tool Stunden oder sogar Tage an Arbeit einsparen.” CTO Agarwal merkt zudem an, dass komplexe Multicloud-Workflows nicht nur durch Automatisierung, sondern auch interne KI-Tools optimiert werden können: “Wir haben unsere internen Playbooks in ein benutzerdefiniertes GPT umgewandelt, das kontextspezifische Fragen wie ‚Wo stelle ich diesen Service bereit?‘ direkt beantwortet. Um Reibungsverluste weiter zu reduzieren, haben wir dieselben Regeln in Cursor kodifiziert, sodass Entwickler Inline-Anleitungen direkt in ihrer IDE erhalten.” Als vielleicht wichtigste Multicloud-Erkenntnis sieht Managerin Lam, dass man in solchen Umgebungen mit Ausfällen rechnen muss. Je mehr Clouds und Services miteinander verbunden würden, desto größer sei die Wahrscheinlichkeit, dass etwas schiefgeht: “Probleme treten häufig an den Verbindungsstellen auf – etwa API-Timeouts, abgelaufene Authentifizierungstoken oder seltsame Latenzspitzen. Sie sollten mit solchen Unwägbarkeiten rechnen.” (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Praxistipps von Multicloud-Entwicklern
Viele Clouds, viele Probleme? Muss nicht sein. Wir haben Experten gefragt, wie Multicloud in der Praxis geht.Juice Flair | shutterstock.com Multicloud-Architekturen versprechen das Beste aus sämtlichen Welten, indem sie es ermöglichen, spezielle Funktionen mehrerer Anbieter zu nutzen. Die Voraussetzung dafür sind allerdings Entwicklungsprozesse, die dazu geeignet sind, die mit einem Multicloud-Ansatz einhergehenden Herausforderungen und Komplexitäten zu bewältigen. Denn im Vergleich zu traditionellem Cloud Computing erfordert es strategische, architektonische und operative Umstellungen, um Code zu schreiben, der zuverlässig in mehreren verschiedenen Cloud-Instanzen läuft. Dazu gilt es, sämtliche Parts des Entwicklungsprozesses weiterzuentwickeln – von der Container-Orchestrierung über Observability bis hin zu internen Tools. Wie sich das in der Praxis ganz konkret umsetzen lässt, dazu haben wir erfahrene Cloud-Experten befragt. Diese geben dabei nicht nur Auskunft über ihre Erfolge, sondern auch über ihre Fails – beziehungsweise die daraus gelernten Lektionen. Kommunikation & Strategie Bevor Entwicklungsteams auch nur eine Zeile Code für Multicloud-Umgebungen schreiben, muss klar sein, warum. Darüber aufzuklären, sieht Drew Firment, Chief Cloud Strategist beim E-Learning-Anbieter Pluralsight, als Aufgabe des Managements an: “Multicloud ist kein Thema für Entwickler. Es handelt sich um ein strategisches Problem, das ein klares Cloud-Betriebsmodell erfordert. Dieses sollte klar definieren, wann, wo und warum Entwicklungsteams bestimmte Cloud-Funktionen nutzen.” Ohne ein solches Modell riskierten Unternehmen hohe Kosten, Sicherheitsprobleme und letztendlich den Projekterfolg, warnt Firment. Er empfiehlt an dieser Stelle mit einem strategischen Framework zu beginnen, das auf die Geschäftsziele abgestimmt ist und zudem klare Verantwortlichkeiten für Multicloud-Entscheidungen zuweist. Dieser Prozess sollte jedoch nicht nur Top-Down verlaufen. Deshalb ist für Heather Davis Lam, Gründerin und CEO der IT-Beratung Revenue Ops, abteilungsübergreifende Kommunikation in diesem Zusammenhang unabdingbar: “Sprechen Sie miteinander. An Multicloud-Projekten sind Entwickler, Betriebsspezialisten, Security-Profis und manchmal auch die Rechtsabteilung beteiligt. Die Probleme entstehen dabei in der Regel durch Missverständnisse, nicht durch schlechten Code. Regelmäßige Check-ins und ehrliche Gespräche sind deshalb enorm hilfreich wenn es um Multicloud-Projekte geht.” Dieser Planungsprozess sollte die Frage klären, warum Multicloud für das Unternehmen ein geeignetes Konzept ist und wie die spezifischen Plattformen innerhalb der Infrastruktur optimal genutzt werden können. Umgebungspluralität Das Multicloud-Entwicklungsteam wird sich in weiten Teilen vor allem mit der Frage beschäftigen, wann und wie Cloud-agnostischer oder plattformübergreifender Code geschrieben werden sollte. Dabei versuchten nicht wenige Teams, ihren Code vollständig Cloud-portabel zu gestalten, meint Gründerin Lam: “Das ist eine schöne Idee, aber in der Praxis kann sie zu Overengineering und noch mehr Kopfzerbrechen führen. Wenn das Team damit anfängt, zusätzliche Layer aufzubauen, nur damit alles funktioniert, ist es an der Zeit, innezuhalten.” Das kann Patrik Dudits, Senior Software Engineer bei der Open-Source-Company Payara Services, aus eigener Erfahrung bestätigen: “Der Versuch, die Architektur auf den ‚kleinsten gemeinsamen Nenner‘ zu beschränken, ist ein gängiger Fehler. In der Praxis ist es deutlich erfolgversprechender, die jeweiligen Stärken der einzelnen Clouds zu nutzen.” Damit meint der Softwareentwickler, Systeme mit Blick auf ihre Autonomie zu entwickeln, um Services unabhängig in ihren jeweiligen Clouds zu betreiben – ohne eine zu enge Kopplung entstehen zu lassen. Dieses Prinzip spielt auch im Ansatz von Matt Dimich, VP of Platform Engineering beim Medienkonzern Thomson Reuters, eine tragende Rolle: “Unser Ziel ist es, die Plattform, auf der wir unsere Anwendungen ausführen, agil zu gestalten. Jedes Jahr kommen neue Innovationen und Rechenleistung wird immer kostengünstigerer. Je schneller wir das nutzen können, umso mehr Wert können wir für unsere Kunden generieren.” Die ultimative Multicloud-Herausforderung besteht laut Pluralsight-Manager Firment darin, Cloud-Fähigkeiten zu optimieren, ohne dabei Chaos zu verursachen: “Die erste Faustregel lautet, die gemeinsamen Kernservices, die in allen Clouds vorhanden sind, zu abstrahieren und gleichzeitig Cloud-spezifische Services, die einen einzigartigen Kundennutzen bieten, zu isolieren. Nutzen Sie beispielsweise einen standardisierten Authentifizierungs- und Compute-Layer für alle Clouds und optimieren Sie gleichzeitig mit AWS-spezifischen Tools wie S3 oder Athena die Kosten und die Query-Performance bei großen Datensätzen.” Das deckt sich mit der Empfehlung von Gründerin Lam: “Halten Sie die Kerngeschäftslogik portabel – APIs, containerisierte Anwendungen, gemeinsame Sprachen wie Python oder Node – dort ist Portabilität wirklich wichtig. Geht es hingegen um Infrastruktur oder Orchestrierung, würde ich dazu raten, auf das zu setzen, was die jeweilige Cloud am besten kann.” Plattformübergreifender Code Der Schlüssel, um die Kerngeschäftslogik Cloud-übergreifend so portabel wie möglich zu gestalten, ist für so gut wie alle unsere Gesprächspartner die Container-Orchestrierungsplattform Kubernetes. Diese empfiehlt zum Beispiel auch Radhakrishnan Krishna Kripa, leitender DevOps-Ingenieur beim Entwicklungsspezialisten Ansys, um Bereitstellungen zu standardisieren: “Indem wir Kubernetes und Docker Container einsetzen, können wir den Code einmal schreiben und ihn anschließend mit minimalen Änderungen in AKS, AWS EKS oder sogar in lokalen Clustern ausführen.” Mit diesem Ansatz rennt Kripa bei Sidd Seethepalli, CTO und Mitbegründer des KI-Unternehmens Vellum, offene Türen ein: “Wir verlassen uns auf Kubernetes statt auf anbieterspezifische Services. So können wir Kubernetes-Cluster überall konsistent bereitstellen, wo sie benötigt werden.” Neil Qylie, Principal Solutions Architect bei der IT-Beratung Myriad360, betrachtet Kubernetes ebenfalls als gute Grundlage: “Indem wir auf Kubernetes aufbauen, können wir Anwendungsdefinitionen und -Deployments mit Helm standardisieren. Der Rollout lässt sich in der Regel über einen GitOps-Workflow mit Tools wie ArgoCD automatisieren.” Dieser Ansatz biete laut Qylie “echte Workload-Mobilität” und gewährleiste parallel konsistente und validierte Deployments über CI/CD-Pipelines. Apropos CI/CD: Diese Tools sind ebenso wichtig wie die Infrastruktur, auf der der Code läuft. Kripa empfiehlt, diese mit Hilfe Cloud-neutraler Tools wie GitHub Actions oder Terraform zu standardisieren: “Wir nutzen hauptsächlich Azure, aber Tools wie GitHub Actions ermöglichen es uns, Builds und Infrastruktur über mehrere Umgebungen hinweg mit einem konsistenten Workflow zu managen. Das trägt dazu bei, die Belastung für die Entwickler bei einem Anbieterwechsel oder einem Deployment in hybriden Umgebungen zu reduzieren.” Unabhängig davon, wie stark Sie Ihren Code standardisieren, müssen Sie dennoch mit den APIs und SDKs der einzelnen Cloud-Anbieter interagieren. Um das ohne Portabilitätseinbußen zu realisieren, hat Anant Agarwal, Mitbegründer und CTO des Softwareunternehmens Aidora, ein Pattern entwickelt: “Wir behandeln jede Cloud-API und jedes SDK wie eine Abhängigkeit: Wir verpacken sie in eine interne Bibliothek und stellen dem Rest der Codebasis eine saubere, generische Schnittstelle zur Verfügung. So bleibt die Cloud-spezifische Logik isoliert und austauschbar, die Kernlogik der Anwendung ist hingegen einfacher zu warten und wird widerstandsfähiger gegen Plattformabhängigkeiten.” Insbesondere dort, wo proprietäre Cloud-Funktionen in der Vergangenheit zu Reibungsverlusten geführt haben, helfe die Open-Source-Community dabei, die Lücken zu schließen, meint Qylie und verweist auf das Serverless-Workflow-Projekt. “Ich behalte die CNCF-Landschaft stets im Auge. Es gibt regelmäßig neue Projekte, die genau diese ‚Knackpunkte‘ adressieren”, so der Entwickler. Komplexitätsbewältigung Heterogene Multi-Cloud-Umgebungen sind komplex. Diesen Umstand sollte auch der Entwicklungsprozess berücksichtigen – insbesondere, wenn es um Sichtbarkeit geht. Der erste Schritt sollte entsprechend darin bestehen Logs und Alerts zu zentralisieren – so wie es auch bei Aidora geschieht: “Wir leiten sämtliche Protokolle an eine einheitliche Observability-Plattform weiter und erstellen eine konsolidierte Ansicht. Bei neueren Tools alles komplett abzudecken, ist schwierig, aber dieser Ansatz unterstützt uns dabei, Vorfälle schnell zu triagieren und dabei Transparenz über alle Cloud-Anbieter hinweg zu gewährleisten.” Diese Vorgehensweise empfiehlt auch Payara-Chefentwickler Dudits: “Es macht Sinn, in ein zentrales, anbieterunabhängiges Dashboard mit hochwertigen Metriken für die gesamte Multicloud-Umgebung zu investieren. Das erleichtert es, anbieterübergreifende Probleme zu erkennen – auch wenn tiefgehendere Analysen weiterhin über anbieterspezifische Tools laufen.” RevenueOps-CEO Lam schreibt hochwertigen Logging-Tools mit Blick auf Multicloud-Umgebungen eine besondere Bedeutung zu: “Es ist schon schwierig genug, eine Cloud zu debuggen. Wenn Sie mit drei oder vier Clouds arbeiten, können Sie mit einem guten Logging- und Monitoring-Tool Stunden oder sogar Tage an Arbeit einsparen.” CTO Agarwal merkt zudem an, dass komplexe Multicloud-Workflows nicht nur durch Automatisierung, sondern auch interne KI-Tools optimiert werden können: “Wir haben unsere internen Playbooks in ein benutzerdefiniertes GPT umgewandelt, das kontextspezifische Fragen wie ‚Wo stelle ich diesen Service bereit?‘ direkt beantwortet. Um Reibungsverluste weiter zu reduzieren, haben wir dieselben Regeln in Cursor kodifiziert, sodass Entwickler Inline-Anleitungen direkt in ihrer IDE erhalten.” Als vielleicht wichtigste Multicloud-Erkenntnis sieht Managerin Lam, dass man in solchen Umgebungen mit Ausfällen rechnen muss. Je mehr Clouds und Services miteinander verbunden würden, desto größer sei die Wahrscheinlichkeit, dass etwas schiefgeht: “Probleme treten häufig an den Verbindungsstellen auf – etwa API-Timeouts, abgelaufene Authentifizierungstoken oder seltsame Latenzspitzen. Sie sollten mit solchen Unwägbarkeiten rechnen.” (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Praxistipps von Multicloud-Entwicklern Viele Clouds, viele Probleme? Muss nicht sein. Wir haben Experten gefragt, wie Multicloud in der Praxis geht.Juice Flair | shutterstock.com Multicloud-Architekturen versprechen das Beste aus sämtlichen Welten, indem sie es ermöglichen, spezielle Funktionen mehrerer Anbieter zu nutzen. Die Voraussetzung dafür sind allerdings Entwicklungsprozesse, die dazu geeignet sind, die mit einem Multicloud-Ansatz einhergehenden Herausforderungen und Komplexitäten zu bewältigen. Denn im Vergleich zu traditionellem Cloud Computing erfordert es strategische, architektonische und operative Umstellungen, um Code zu schreiben, der zuverlässig in mehreren verschiedenen Cloud-Instanzen läuft. Dazu gilt es, sämtliche Parts des Entwicklungsprozesses weiterzuentwickeln – von der Container-Orchestrierung über Observability bis hin zu internen Tools. Wie sich das in der Praxis ganz konkret umsetzen lässt, dazu haben wir erfahrene Cloud-Experten befragt. Diese geben dabei nicht nur Auskunft über ihre Erfolge, sondern auch über ihre Fails – beziehungsweise die daraus gelernten Lektionen. Kommunikation & Strategie Bevor Entwicklungsteams auch nur eine Zeile Code für Multicloud-Umgebungen schreiben, muss klar sein, warum. Darüber aufzuklären, sieht Drew Firment, Chief Cloud Strategist beim E-Learning-Anbieter Pluralsight, als Aufgabe des Managements an: “Multicloud ist kein Thema für Entwickler. Es handelt sich um ein strategisches Problem, das ein klares Cloud-Betriebsmodell erfordert. Dieses sollte klar definieren, wann, wo und warum Entwicklungsteams bestimmte Cloud-Funktionen nutzen.” Ohne ein solches Modell riskierten Unternehmen hohe Kosten, Sicherheitsprobleme und letztendlich den Projekterfolg, warnt Firment. Er empfiehlt an dieser Stelle mit einem strategischen Framework zu beginnen, das auf die Geschäftsziele abgestimmt ist und zudem klare Verantwortlichkeiten für Multicloud-Entscheidungen zuweist. Dieser Prozess sollte jedoch nicht nur Top-Down verlaufen. Deshalb ist für Heather Davis Lam, Gründerin und CEO der IT-Beratung Revenue Ops, abteilungsübergreifende Kommunikation in diesem Zusammenhang unabdingbar: “Sprechen Sie miteinander. An Multicloud-Projekten sind Entwickler, Betriebsspezialisten, Security-Profis und manchmal auch die Rechtsabteilung beteiligt. Die Probleme entstehen dabei in der Regel durch Missverständnisse, nicht durch schlechten Code. Regelmäßige Check-ins und ehrliche Gespräche sind deshalb enorm hilfreich wenn es um Multicloud-Projekte geht.” Dieser Planungsprozess sollte die Frage klären, warum Multicloud für das Unternehmen ein geeignetes Konzept ist und wie die spezifischen Plattformen innerhalb der Infrastruktur optimal genutzt werden können. Umgebungspluralität Das Multicloud-Entwicklungsteam wird sich in weiten Teilen vor allem mit der Frage beschäftigen, wann und wie Cloud-agnostischer oder plattformübergreifender Code geschrieben werden sollte. Dabei versuchten nicht wenige Teams, ihren Code vollständig Cloud-portabel zu gestalten, meint Gründerin Lam: “Das ist eine schöne Idee, aber in der Praxis kann sie zu Overengineering und noch mehr Kopfzerbrechen führen. Wenn das Team damit anfängt, zusätzliche Layer aufzubauen, nur damit alles funktioniert, ist es an der Zeit, innezuhalten.” Das kann Patrik Dudits, Senior Software Engineer bei der Open-Source-Company Payara Services, aus eigener Erfahrung bestätigen: “Der Versuch, die Architektur auf den ‚kleinsten gemeinsamen Nenner‘ zu beschränken, ist ein gängiger Fehler. In der Praxis ist es deutlich erfolgversprechender, die jeweiligen Stärken der einzelnen Clouds zu nutzen.” Damit meint der Softwareentwickler, Systeme mit Blick auf ihre Autonomie zu entwickeln, um Services unabhängig in ihren jeweiligen Clouds zu betreiben – ohne eine zu enge Kopplung entstehen zu lassen. Dieses Prinzip spielt auch im Ansatz von Matt Dimich, VP of Platform Engineering beim Medienkonzern Thomson Reuters, eine tragende Rolle: “Unser Ziel ist es, die Plattform, auf der wir unsere Anwendungen ausführen, agil zu gestalten. Jedes Jahr kommen neue Innovationen und Rechenleistung wird immer kostengünstigerer. Je schneller wir das nutzen können, umso mehr Wert können wir für unsere Kunden generieren.” Die ultimative Multicloud-Herausforderung besteht laut Pluralsight-Manager Firment darin, Cloud-Fähigkeiten zu optimieren, ohne dabei Chaos zu verursachen: “Die erste Faustregel lautet, die gemeinsamen Kernservices, die in allen Clouds vorhanden sind, zu abstrahieren und gleichzeitig Cloud-spezifische Services, die einen einzigartigen Kundennutzen bieten, zu isolieren. Nutzen Sie beispielsweise einen standardisierten Authentifizierungs- und Compute-Layer für alle Clouds und optimieren Sie gleichzeitig mit AWS-spezifischen Tools wie S3 oder Athena die Kosten und die Query-Performance bei großen Datensätzen.” Das deckt sich mit der Empfehlung von Gründerin Lam: “Halten Sie die Kerngeschäftslogik portabel – APIs, containerisierte Anwendungen, gemeinsame Sprachen wie Python oder Node – dort ist Portabilität wirklich wichtig. Geht es hingegen um Infrastruktur oder Orchestrierung, würde ich dazu raten, auf das zu setzen, was die jeweilige Cloud am besten kann.” Plattformübergreifender Code Der Schlüssel, um die Kerngeschäftslogik Cloud-übergreifend so portabel wie möglich zu gestalten, ist für so gut wie alle unsere Gesprächspartner die Container-Orchestrierungsplattform Kubernetes. Diese empfiehlt zum Beispiel auch Radhakrishnan Krishna Kripa, leitender DevOps-Ingenieur beim Entwicklungsspezialisten Ansys, um Bereitstellungen zu standardisieren: “Indem wir Kubernetes und Docker Container einsetzen, können wir den Code einmal schreiben und ihn anschließend mit minimalen Änderungen in AKS, AWS EKS oder sogar in lokalen Clustern ausführen.” Mit diesem Ansatz rennt Kripa bei Sidd Seethepalli, CTO und Mitbegründer des KI-Unternehmens Vellum, offene Türen ein: “Wir verlassen uns auf Kubernetes statt auf anbieterspezifische Services. So können wir Kubernetes-Cluster überall konsistent bereitstellen, wo sie benötigt werden.” Neil Qylie, Principal Solutions Architect bei der IT-Beratung Myriad360, betrachtet Kubernetes ebenfalls als gute Grundlage: “Indem wir auf Kubernetes aufbauen, können wir Anwendungsdefinitionen und -Deployments mit Helm standardisieren. Der Rollout lässt sich in der Regel über einen GitOps-Workflow mit Tools wie ArgoCD automatisieren.” Dieser Ansatz biete laut Qylie “echte Workload-Mobilität” und gewährleiste parallel konsistente und validierte Deployments über CI/CD-Pipelines. Apropos CI/CD: Diese Tools sind ebenso wichtig wie die Infrastruktur, auf der der Code läuft. Kripa empfiehlt, diese mit Hilfe Cloud-neutraler Tools wie GitHub Actions oder Terraform zu standardisieren: “Wir nutzen hauptsächlich Azure, aber Tools wie GitHub Actions ermöglichen es uns, Builds und Infrastruktur über mehrere Umgebungen hinweg mit einem konsistenten Workflow zu managen. Das trägt dazu bei, die Belastung für die Entwickler bei einem Anbieterwechsel oder einem Deployment in hybriden Umgebungen zu reduzieren.” Unabhängig davon, wie stark Sie Ihren Code standardisieren, müssen Sie dennoch mit den APIs und SDKs der einzelnen Cloud-Anbieter interagieren. Um das ohne Portabilitätseinbußen zu realisieren, hat Anant Agarwal, Mitbegründer und CTO des Softwareunternehmens Aidora, ein Pattern entwickelt: “Wir behandeln jede Cloud-API und jedes SDK wie eine Abhängigkeit: Wir verpacken sie in eine interne Bibliothek und stellen dem Rest der Codebasis eine saubere, generische Schnittstelle zur Verfügung. So bleibt die Cloud-spezifische Logik isoliert und austauschbar, die Kernlogik der Anwendung ist hingegen einfacher zu warten und wird widerstandsfähiger gegen Plattformabhängigkeiten.” Insbesondere dort, wo proprietäre Cloud-Funktionen in der Vergangenheit zu Reibungsverlusten geführt haben, helfe die Open-Source-Community dabei, die Lücken zu schließen, meint Qylie und verweist auf das Serverless-Workflow-Projekt. “Ich behalte die CNCF-Landschaft stets im Auge. Es gibt regelmäßig neue Projekte, die genau diese ‚Knackpunkte‘ adressieren”, so der Entwickler. Komplexitätsbewältigung Heterogene Multi-Cloud-Umgebungen sind komplex. Diesen Umstand sollte auch der Entwicklungsprozess berücksichtigen – insbesondere, wenn es um Sichtbarkeit geht. Der erste Schritt sollte entsprechend darin bestehen Logs und Alerts zu zentralisieren – so wie es auch bei Aidora geschieht: “Wir leiten sämtliche Protokolle an eine einheitliche Observability-Plattform weiter und erstellen eine konsolidierte Ansicht. Bei neueren Tools alles komplett abzudecken, ist schwierig, aber dieser Ansatz unterstützt uns dabei, Vorfälle schnell zu triagieren und dabei Transparenz über alle Cloud-Anbieter hinweg zu gewährleisten.” Diese Vorgehensweise empfiehlt auch Payara-Chefentwickler Dudits: “Es macht Sinn, in ein zentrales, anbieterunabhängiges Dashboard mit hochwertigen Metriken für die gesamte Multicloud-Umgebung zu investieren. Das erleichtert es, anbieterübergreifende Probleme zu erkennen – auch wenn tiefgehendere Analysen weiterhin über anbieterspezifische Tools laufen.” RevenueOps-CEO Lam schreibt hochwertigen Logging-Tools mit Blick auf Multicloud-Umgebungen eine besondere Bedeutung zu: “Es ist schon schwierig genug, eine Cloud zu debuggen. Wenn Sie mit drei oder vier Clouds arbeiten, können Sie mit einem guten Logging- und Monitoring-Tool Stunden oder sogar Tage an Arbeit einsparen.” CTO Agarwal merkt zudem an, dass komplexe Multicloud-Workflows nicht nur durch Automatisierung, sondern auch interne KI-Tools optimiert werden können: “Wir haben unsere internen Playbooks in ein benutzerdefiniertes GPT umgewandelt, das kontextspezifische Fragen wie ‚Wo stelle ich diesen Service bereit?‘ direkt beantwortet. Um Reibungsverluste weiter zu reduzieren, haben wir dieselben Regeln in Cursor kodifiziert, sodass Entwickler Inline-Anleitungen direkt in ihrer IDE erhalten.” Als vielleicht wichtigste Multicloud-Erkenntnis sieht Managerin Lam, dass man in solchen Umgebungen mit Ausfällen rechnen muss. Je mehr Clouds und Services miteinander verbunden würden, desto größer sei die Wahrscheinlichkeit, dass etwas schiefgeht: “Probleme treten häufig an den Verbindungsstellen auf – etwa API-Timeouts, abgelaufene Authentifizierungstoken oder seltsame Latenzspitzen. Sie sollten mit solchen Unwägbarkeiten rechnen.” (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!