Im zweiten Teil unserer Serie “EU Sovereign Cloud“ haben wir theoretisch analysiert, wo europäische Cloud-Provider im Featurevergleich zu Azure stehen – doch wie sieht die Realität aus? Wir haben den ultimativen Praxistest gewagt: Eine vollständige Migration einer cloud-nativen Anwendung von Microsoft Azure zur IONOS Cloud. Container, Secrets, KI-Services – alles was eine moderne Architektur ausmacht, musste portiert werden. Das Ergebnis? Überraschende Hürden, kreative Workarounds und einige unerwartete Erkenntnisse. In diesem dritten Teil zeigen wir, was direkt abbildbar war, wo es Lücken gab und wie mit Re-Architect darauf reagiert werden kann. Ein ehrlicher Erfahrungsbericht mit konkreten Lessons Learned für alle, die den Sprung zur EU Sovereign Cloud wagen wollen.
Inhalt
Wir haben eine AI-Assistant-Anwendung zur Unterstützung von Faktura gewählt, die repräsentativ für moderne cloud-native Workloads ist. Die Anwendung besteht aus drei Komponenten: Chat-UI, MCP-Server für Docuware-Integration und Backend-Job-Processor für asynchrone Dokumentenverarbeitung. Nutzer interagieren via Chat mit einem KI-Assistenten, der aus Zeiterfassungen und anderen Unterlagen weiterführende Dokumente generiert. User-Aktionen triggern asynchrone Jobs für die Dokumentenerstellung im Hintergrund. Technisch läuft alles auf Azure Container Apps, Azure Table Storage dient als Repository für asynchrone Jobs, Images werden in der Azure Container Registry gepflegt, Provisionierung erfolgt via Terraform in GitLab CI. Nutzer loggen sich via SSO über Microsoft Entra ID ein. Dazu kommen Standard-Azure-Services für Logging, Secret Management und Storage.
Eine typische Azure-native Architektur, die das komplette Service-Ökosystem nutzt – ideal, um die Migrationskomplexität zu testen!
Abb. 1: Anwendungsinfrastruktur in Azure mit CI/CD Stack und externen Komponenten.
Wenn man Azure gewohnt ist, muss man sich bei IONOS auf ein paar Änderungen gefasst machen. Neben dem Look-And-Feel des UIs unterscheiden sich auch grundlegende Konzepte – Lücken in IAM & Governance (keine klassischen technischen Nutzer oder fine-grained RBAC), bedingte Gruppierung von Cloud-Ressourcen und gänzlich nicht verfügbare Services. Die beiden folgenden Screenshots zeigen das IONOS Datacenter Web-UI.
Abb. 2: IONOS Data Center Designer Web-UI.
Nachdem mit wenigen Klicks und Hinterlegen einer Kreditkarte der Account angelegt wurde, gelangt man direkt in das zentrale UI, den IONOS Data Center Designer (s. Abb. 2).
Abb. 3: IONOS Data Center Details Web-UI.
Wie bei Azure Resource Groups können Cloud-Ressourcen in “Data Centers” gruppiert werden. Die einzelnen Infrastrukturkomponenten werden via Drag&Drop zusammengeklickt (s. Abb. 3).
Die folgenden Tabelle zeigt die Abbildbarkeit der verwendeten Azure Services in IONOS:
|
|
Azure |
IONOS |
Bemerkung |
|---|---|---|---|
|
Infrastructure-as-Code |
Azure Terraform Provider |
|
Nicht alle Resources provisionierbar (z.B. AI-Model-Hub) |
|
IaC-Pipeline Authentication |
Microsoft Entra ID Service Principal |
|
Muss manuell in IONOS-UI angelegt werden |
|
Resource Organization |
Azure Resource Group |
|
Gruppierung nur in geringerem Umfang möglich (z.B. Storage ausgeschlossen) |
|
Container Runtime |
Azure Container Apps |
|
Provisionierung via Terraform |
|
Log Collection |
Azure Log Analytics Workspace |
|
|
|
Container Registry |
Azure Container Registry |
|
incl. CVE-Image-Scanning und Retention-Policies |
|
Blob Storage |
Azure Storage Account - Container |
|
Zugriff aus CI/CD erfolgt via Access-Key |
|
Persistent Volume Claims |
Azure Storage Account - Azure File |
|
Provisionierung in K8s erfolgt automatisch über Storage-Classes |
|
AI-Model Service (LLM) |
Azure OpenAI |
|
|
|
Secret Management |
Azure Key Vault |
|
Keine IONOS-native Lösung verfügbar → Re-Architect nötig |
|
Job Repository |
Azure Storage Account - Azure Table |
|
Keine IONOS-native Lösung verfügbar → Re-Architect nötig |
|
Identity Provider (SSO) |
Microsoft Entra ID App Registration |
|
kein typischer Identity Provider, IONOS-IAM vorwiegend zur Zugriffssteuerung auf Cloud-Ressourcen, nicht für tatsächliches End-User-Management |
|
Service-Level RBAC |
Azure Managed Identity |
|
kein Service-Level RBAC, stattdessen Token-Auth gegen Cloud-Services (Container Registry, Loki, Storage) |
IONOS bietet kein natives Secret Management – ein kritischer Gap für unsere Anwendung und ein Fall für Re-Architect. Als zentralen Secret-Store haben wir uns für OpenBao, ein Open-Source-Fork von HashiCorp Vault, als StatefulSet in Kubernetes entschieden. OpenBao implementiert das Hashicorp-Vault-API und lässt sich somit als regulärer SecretStore mit dem External Secrets Operator nahtlos in Kubernetes integrieren. IaC-Provisioniering von Secrets via Terraform ist ebenfalls mit dem Vault-Terraform-Provider möglich.
Table Storage existiert bei IONOS nicht – somit musste für das Job Repository ebenfalls eine Alternative her. Wir haben uns für Redis als simplen Key-Value-Store entschieden, ebenfalls deployt in Kubernetes mit PVC. Dieser Schritt erforderte leider eine Anpassung des Applikationscodes in mehreren Komponenten, der Entwicklungsaufwand hielt sich jedoch in Grenzen.
IONOS-IAM ist primär zur Zugriffssteuerung auf Cloud-Ressourcen ausgelegt, nicht für echtes Enduser-Management analog eines regulären Identity Providers. Eine mögliche Lösung wäre gewesen, ein eigenes Keycloak-Deployment in Kubernetes als eigenen Identity Provider aufzusetzen. Jedoch haben wir diese Option nicht weiter verfolgt, da unsere Anwendung auf existierende Nutzer in Microsoft Entra ID angewiesen ist und eine Federation mit Azure somit trotzdem notwendig wäre. Daher bleiben wir bei Microsoft Entra ID für SSO – ein pragmatischer Ansatz, der zeigt, dass nicht jeder Service zwangsläufig migriert werden muss.
Die Zielarchitektur zeigt einen Mix aus direkten Service-Mappings und notwendigem Re-Architect. Während Standard-Services wie Managed Kubernetes, Container Registry und Object Storage direkt verfügbar sind, musste OpenBao das fehlende Secret Management ersetzen und Redis die Job-Repository-Funktion übernehmen. Für SSO bleibt Microsoft Entra ID erhalten – die finale Lösung ist somit Hybrid.
Abb. 4: Anwendungsinfrastruktur in IONOS mit CI/CD Stack und externen Komponenten.
Kubernetes ist der ultimative Gap-Filler – und Hybrid-Architekturen sind oft die strategisch klügere Realität. Unsere wichtigsten Erkenntnisse aus der Migration:
Object Storage, Container Registry und Managed Kubernetes bilden den kleinsten gemeinsamen Nenner zwischen Cloud-Providern
Service-Gaps sind überbrückbar, erfordern aber deutlich mehr Engineering-Aufwand
Native Cloud-Services reduzieren Komplexität erheblich – deren Fehlen macht sich sofort bemerkbar
Infrastructure-as-Code via Terraform funktioniert, hat aber provider-spezifische Limitierungen
Kubernetes-native Lösungen bieten oft mehr Flexibilität als Managed Services, verschieben jedoch auch die Betriebsverantwortung ins Team
UI/UX-Qualität des IONOS-Portals bietet Raum für Optimierungen
Dokumentation und Guides sind entscheidend für erfolgreiche Implementierungen
Mehrkosten entstehen durch den höheren Preis der EU-Cloud-Infrastruktur selbst und durch zusätzliche Entwicklungs- und Betriebskosten für die eigenen Gap-Filler
Nicht alles muss migriert werden – strategische Hybrid-Ansätze sind oft praktikabler
Haben Sie Fragen oder benötigen Unterstützung?
Stehen Sie aktuell vor der Herausforderung, den für Ihr Unternehmen optimalen Weg zu definieren und Ihre digitale Souveränität zu sichern? Als erfahrener Partner unterstützen wir Sie dabei, diese Komplexität zu durchdringen, die richtigen Entscheidungen zu treffen und Ihre individuelle Cloud-Strategie erfolgreich umzusetzen. Kontaktieren Sie uns oder finden Sie mehr zu Cloud Transformation auf unserer Website.