The Leap from Cloud to Multi-Cloud: Ein praxisnaher Leitfaden aus dem Talk von Damjan Gjurovski (Posedio)

Warum dieser Talk zählt

Bei DevJobs.at hören wir viele Sessions über Cloud-Strategien – selten jedoch so klar strukturiert und praxisnah wie „The Leap from Cloud to Multi-Cloud“ von Damjan Gjurovski (CTO, Posedio). In weniger Buzzwords und mehr Handwerk erklärt er, was eine Multi-Cloud-Strategie wirklich ausmacht, warum Organisationen diesen Schritt gehen sollten und wie man ihn technisch sauber umsetzt. Sein roter Faden: Multi-Cloud ist kein Sammelsurium an Tools, sondern eine „einheitliche Strategie“ über mehrere Anbieter hinweg – mit klaren Konventionen, Sicherheitsleitplanken und einem goldenen Pfad für Entwicklerteams.

Was Multi-Cloud ist – und was nicht

Viele Unternehmen starten mit etwas, das wie Multi-Cloud aussieht: Power BI, Office 365, einzelne Applikationen auf VMs oder in Kubernetes, Google Ads, das Daten in BigQuery schiebt, dazu On-Prem-Datenbanken. Das wirkt verteilt und vielfältig. Ist es damit schon Multi-Cloud? Aus Sicht von Gjurovski: nein.

Der Unterschied ist entscheidend: Ohne gemeinsame Architekturprinzipien, Governance, Sicherheit und Entwicklerpfade bleibt es Flickwerk. Erst die Vereinheitlichung macht aus „vielen Clouds“ eine echte Multi-Cloud.

Die drei Gründe für den Sprung in die Multi-Cloud

Damjan Gjurovski strukturiert das „Warum“ in drei Treiber. Aus unserer Sicht bilden sie einen nüchternen, aber vollständigen Entscheidungsrahmen für Technik- und Business-Seite.

1) Das richtige Werkzeug für die Aufgabe

Cloud-Anbieter profilieren sich in Nischen:

• GCP mit BigQuery, Data-Workloads, AI/ML.
• Azure mit Windows-Services und .NET.
• AWS mit reifen Serverless-Bausteinen wie Lambda und dem frühesten, breiten Portfolio.

Teams wissen am besten, welche Werkzeuge sie für ihre Domäne brauchen. „Right tool for the job“ wird zum Organisationsprinzip: Dezentralisierte Entscheidungen auf Teamebene entfalten das Potenzial der gesamten Organisation – statt einheitlich alle Lösungen in einem Cloud-Korsett zu bauen.

2) Risiko steuern – technisch, finanziell, organisatorisch

• Vendor Lock-in vermeiden: Wer fest gebunden ist, erlebt Preiserhöhungen und enge Verhandlungsspielräume.
• Kosten und TCO optimieren: Zwischen Angeboten vergleichen, Preisdruck nutzen, Vertragsverhandlungen mit Alternativen untermauern.
• Business Continuity sichern: Wenn Regionen oder Anbieter ausfallen – oder Compliance/Governance/Legal es erfordern –, muss ein Backup-Plan vorhanden sein. Dieses Thema verortet Gjurovski klar im FinOps-Kontext.

3) Es passiert sowieso: Schatten-IT

Wenn Teams Autonomie brauchen, aber die IT „nein“ sagt, suchen sie Wege. Schatten-IT entsteht – und mit ihr de-facto Multi-Cloud ohne Strategie. Gjurovski verweist auf Schätzungen, nach denen die Zahl der tatsächlich genutzten Cloud-Produkte um ein Vielfaches über der IT-Vermutung liegen kann (er nennt Größenordnungen von 15- bis 25-fach). Kernbotschaft: Wer die ersten beiden Gründe ignoriert, landet in Multi-Cloud – nur ohne einheitliche Architektur.

Wie Multi-Cloud gelingt: Vier technische Grundpfeiler

Der Vortrag strukturiert die Umsetzung in klaren Bausteinen. Für uns ist das die wertvollste Passage: ein anwendbares Gerüst, das in großen wie kleinen Organisationen trägt.

1) Das Basissetup: Organisation verstehen, Konventionen definieren, IaC durchziehen

Bevor irgendetwas deployed wird, steht die Bestandsaufnahme:

• Wie viele Abteilungen gibt es, wie arbeiten sie, wo existieren Querschnittsthemen?
• Welche Risikoneigung, Governance- und Sicherheitsanforderungen bestehen?
• Gibt es regulatorische Rahmenbedingungen?
• Wie sieht die bestehende Lösung im „alten“ Cloud-Setup aus?

Darauf folgen verbindliche Konventionen:

• Klare Benennungen, Labels und eine nachvollziehbare Ordner-/Projektstruktur.
• Zentrale Governance und Sicherheit – bei gleichzeitig dezentralen Entscheidungen für Teams, damit sie produktiv bleiben.
• Infrastruktur als Code (z. B. mit Terraform) für Reproduzierbarkeit und Disaster Recovery.
• Nachhaltigkeit berücksichtigen (Green-Cloud-Aspekte), um spätere FinOps- und Asset-Management-Prozesse zu unterstützen.

Wichtig: Dieses Basissetup liefert noch keinen fachlichen Mehrwert – ist aber der unverzichtbare Enabler für alles, was folgt.

2) Networking: Erst verbinden, dann trennen – IP-Planung ist Pflicht

Ohne Netz kein Verbund:

• Verbindungen von On-Prem ins Rechenzentrum,
• Peering bzw. Leitungen zwischen Cloud-Anbietern,
• VPNs für Entwickler- und Business-Arbeitsplätze,
• und eine sauber geplante IP-Adressierung.

Gjurovski warnt ausdrücklich: IP-Range-Konflikte sind ein Alptraum – und verhindern am Ende jede Verbindung. Saubere Adresskonzepte sind nicht nice-to-have, sondern existenziell.

Die Reihenfolge bleibt dabei pragmatisch:

3) Sicherheit und Identität: Least Privilege, kurzlebige Zugriffe, Lifecycle-Integration

Security folgt dem Prinzip „Least Privilege“ und etabliert Guardrails:

• Netzwerkzugriffe kontrollieren – zwischen Clouds und innerhalb einer Cloud.
• Langelebige Credentials vermeiden, keine herumliegenden Service-Account-Schlüssel.
• Idealziel: eine Zero-Trust-Umgebung, in der Geheimnisse nicht herausgetragen werden können.

Ein oft unterschätzter Aspekt ist für Gjurovski die Integration in den Benutzerlebenszyklus der Firma:

• Onboarding: Neue Mitarbeitende erhalten sofort Identitäten und die nötigen Zugriffe.
• Offboarding: Zugriffe werden automatisch und vollständig entzogen.
• Abteilungswechsel: Berechtigungen folgen der Person – Marketing-Sicht auf Leads weicht bei Wechsel in Accounting automatisch den Rechnungsdaten.

Entscheidend ist die geteilte Identität über Cloud-Grenzen hinweg: Wer in Cloud A onboardet wird, muss in Cloud B konsistent gemanagt werden – ohne manuelle Nacharbeiten.

4) Shared Services: Einheitliche Architektur, ein Eingang, goldener Pfad, einfache Migration

Multi-Cloud verlangt eine gemeinsame Plattformlogik:

• Ein Einstiegspunkt zur Plattform, auch wenn die Deployments in unterschiedlichen Clouds landen.
• Ein goldener Pfad für Entwicklerinnen und Entwickler: Wiederverwendbare Workflows und bekannte Konzepte, statt pro Cloud neu zu lernen und Fehler zu riskieren.
• Migrationen zwischen Clouds müssen einfach sein. Teams sollen eine App mit minimalem Aufwand verschieben können – „ohne dass die Nutzer es merken“.

Ein häufiger Fehler: „Wir richten die Deployments in beiden Clouds ein“ – aber vergessen den Wechselpfad. Genau dieser Wechsel macht den Multi-Cloud-Vorteil erst nutzbar.

Der kritische Zusatz: Multi-Cloud geht in beide Richtungen

Hier setzt Gjurovski einen wichtigen Kontrapunkt. Viele bauen die neue Cloud vorbildlich – Infrastructure as Code, moderne Security, Best Practices. Doch das alte Setup bleibt unberührt. Ergebnis: Zwei Welten, unterschiedliche Standards, wachsende technische Schulden.

Das heißt konkret:

• Best Practices aus der neuen Umgebung zurück ins alte Setup transferieren.
• Die Organisation gemeinsam weiterentwickeln – beide Clouds parallel.
• Ein einziges Cloud-Platform-Team etablieren, das beide Infrastrukturen verantwortet – um Silos und Politik („wer deployt wo?“) zu vermeiden.

Der Weg in Etappen: Von Single-Cloud zu Multi-Cloud

Zum Abschluss skizziert Gjurovski einen pragmatischen Pfad. Wir haben ihn als Roadmap gelesen, die sich ohne Zusatzfantasie direkt aus dem Talk ableitet:

1) Bestehendes Setup bewerten

• Risiken erkennen und senken.
• Teams befähigen und Entscheidungen dorthin schieben, wo das meiste Wissen sitzt.

2) Neue Cloud sauber aufsetzen

• Best Practices strikt umsetzen.
• Alles als Code (Terraform), keine Click-Ops-Schulden wiederholen.

3) Interoperabilität sicherstellen

• Was in Cloud A funktioniert, soll in Cloud B funktionieren – Ausnahmen bewusst.
• Migrationen und Deployments vereinheitlichen.
• Developer Experience auf beiden Seiten auf ein gleich hohes Niveau heben.

4) Kontinuierlich verbessern

• Beide Clouds ko-entwickeln.
• Wissen teilen.
• Ein belastbares, langlebiges Parallel-Setup erreichen.

Praktische Leitfragen für Engineering- und Plattform-Teams

Aus dem Talk lassen sich sofort umsetzbare Fragen ableiten:

• Organisationsaufnahme: Welche Abteilungen, Domänen und Querschnitte haben wir? Welche Compliance- und Regulatorik gilt?
• Konventionen: Wie benennen und labeln wir konsistent? Wie sieht unsere Ordner-/Projektstruktur aus? Welche Policies automatisieren wir?
• IaC: Was ist bereits als Code vorhanden? Wo gibt es Click-Ops, die wir ablösen müssen? Wie testen und versionieren wir Infrastrukturänderungen?
• Netz: Welche IP-Bereiche sind belegt? Wo drohen Konflikte? Welche Verbindungen brauchen wir On-Prem ↔ Cloud ↔ Cloud ↔ VPN?
• Sicherheit: Wie erzwingen wir Least Privilege? Wo existieren langlebige Secrets? Wie verhindern wir Service-Account-Schlüssel-Sprawl?
• Identität: Wie koppeln wir das Unternehmens-Identity-Management an beide Clouds? Wie automatisieren wir On-/Offboarding und Abteilungswechsel?
• Developer Experience: Wie sieht unser goldener Pfad aus? Wie abstrahieren wir Unterschiede der Anbieter, ohne Teams zu bevormunden?
• Migration: Wie verschieben wir Workloads zwischen Clouds, ohne Downtime für Nutzer? Wo fehlen uns standardisierte Laufzeit- und Delivery-Bausteine?
• Operative Verantwortung: Haben wir ein gemeinsames Platform-Team? Wie vermeiden wir Silos und widersprüchliche Standards?
• FinOps: Wie messen und vergleichen wir TCO zwischen Anbietern? Wie verankern wir Preis- und Vertragsoptionen in unseren Architekturentscheidungen?

Häufige Fallstricke – direkt aus den Warnungen im Talk

• IP-Adresskonflikte nicht frühzeitig adressiert: Verhindert Verbindungen und blockiert Integrationen.
• Langelebige Credentials und lose Service-Account-Schlüssel: Erhöhen Risiko und Wartungsaufwand.
• Fehlende Lifecycle-Integration: Berechtigungen laufen nach Offboarding oder Abteilungswechsel weiter – Compliance-Risiko.
• Doppelte Deployments ohne Migrationspfad: Teams sitzen fest, statt flexibel zu sein.
• Neues Setup top, altes Setup bleibt zurück: Wissens- und Tool-Gap wächst, echte Multi-Cloud bleibt Illusion.
• Governance „zentralisiert alles“: Teams verlieren Geschwindigkeit; die Strategie scheitert an der Realität.

Developer Experience als Hebel: Ein Eingang, ein Pfad, viele Ziele

Was uns besonders hängen blieb: Multi-Cloud verlangt einen gemeinsamen Einstiegspunkt und einen goldenen Pfad. Das ist keine Kosmetik, sondern Risikomanagement und Produktivitätsfaktor. Wer pro Anbieter alles neu lernt, produziert Fehler – und reduziert die Chance, den „Right tool for the job“-Vorteil wirklich zu heben. Der goldene Pfad standardisiert das „Wie“, während die Wahl des „Wo“ (Cloud A oder B) den Teams überlassen bleibt.

Zitat-Highlights, die das Denken schärfen

• „Right tool for the job“ – Teams entscheiden, womit sie ihre Domäne am besten lösen.
• „Schritt eins: verbinden. Schritt zwei: stoppen, was nicht verbunden sein soll.“ – Netzwerk- und Sicherheitsreihenfolge.
• „Multi-Cloud geht in beide Richtungen.“ – Best Practices zurück ins alte Setup tragen.
• „Der Name des Spiels ist Multi-Cloud – nicht Cloud-Ersatz.“ – Keine Einbahnstraße.

Konkrete nächste Schritte – inspiriert von der Session

• Eine Woche für die Inventur: Organisationslandschaft, bestehende Cloud-Topologie, IP-Pläne, Policies, Click-Ops-Landminen.
• Einen Monat für Basiskonventionen und IaC-Rahmen: Naming, Labels, Ordnerstruktur, Policy- und Identity-Integration als Code.
• Parallel: Netzwerkverbindungen planen, IP-Konflikte ausräumen, VPN-Pfade definieren.
• Sicherheitsleitplanken etablieren: Least Privilege, kurzlebige Credentials, Service-Account-Schlüssel eliminieren.
• Einen goldenen Pfad designen: Einheitlicher Entry Point, wiederverwendbare Delivery-Schritte, gleicher DX-Standard für beide Clouds.
• Früh eine Migration als „Walking Skeleton“ bauen: Kleine App zwischen A und B verschieben – Ende-zu-Ende, sichtbar für das Team.
• Backport-Plan fürs alte Setup aufsetzen: Lessons Learned direkt rückführen, Click-Ops systematisch abbauen.
• Ein Platform-Team beauftragen: Zuständig für beide Clouds, mit klarem Mandat gegen Silos.

Fazit: Multi-Cloud als Disziplin, nicht als Tool-Liste

„The Leap from Cloud to Multi-Cloud“ von Damjan Gjurovski (Posedio) ist weniger eine Vision und mehr ein Arbeitsauftrag: Multi-Cloud entsteht, wenn Organisation, Netzwerk, Sicherheit, Identität und Shared Services in einer gemeinsamen Strategie zusammenlaufen – und wenn dieselben Standards konsequent in alten wie neuen Setups gelten. Für uns war das zentrale Learning: Der technische Gewinn liegt nicht im „mehr Anbieter“, sondern im „eine Plattform, mehrere Ziele“. Wer diese Disziplin lebt, bekommt Autonomie für Teams, bessere Kostenkontrolle, Risikoreduktion – und eine belastbare Grundlage, die den Werkzeugkoffer jeder Domäne respektiert.

Am Ende steht eine einfache Prüffrage: Haben wir eine einheitliche Strategie, die den Wechsel zwischen Clouds banal macht? Wenn ja, sind wir in Multi-Cloud. Wenn nein, ist es nur ein Flickenteppich – und der nächste IP-Konflikt oder Credential-Leak erinnert uns daran.