Wir haben die OVHCloud ausführlich getestet. Danach hatten unsere Cloud-Architekten Fragen. OVH antwortete ... und wir glauben, das könnte euch auch interessieren.
Referenzarchitektur: Ist das, was wir aufgebaut haben, eine typische Kundensituation bei euch?
OVH: Ja, das ist eine sehr typische Kundensituation. Die Architektur entspricht dem, was viele Kunden heute aufbauen, insbesondere mittelständische Unternehmen, die sich an gängigen Landing-Zone-Konzepten orientieren. IAM, Security, Automatisierung mit Terraform sowie Logging und Observability sind dabei Standardanforderungen. Genau solche Setups sieht OVHcloud regelmäßig bei Kunden und richtet die Weiterentwicklung der Public Cloud auch darauf aus.
Landing Zone & Grundkonzepte
Umgebungen: Wie trennt ihr produktive und nicht-produktive Umgebungen bei OVHcloud?
OVH: Produktiv und nicht-produktiv werden bei OVHcloud in getrennte Projekte aufgeteilt. Wenn man die Umgebungen untereinander oder mit On-Prem/anderen Clouds verbinden will, wird dafür häufig ein zusätzliches, separates Projekt genutzt, das nur für Netzwerk-/Verbindungssteuerung dient (z. B. mit Firewall-Cluster o. ä.). Welche Variante man wählt, hängt auch von Compliance-/Regulatorik-Anforderungen ab.
Projekte: Ist ein Projekt bei OVHcloud eine Umgebung oder eher eine Landing Zone?
OVH: Ein Projekt bei OVHcloud entspricht in der Praxis eher einer Umgebung (z. B. prod, non-prod) als einer vollständigen Landing Zone. Eine klassische Landing-Zone-Struktur entsteht erst durch mehrere Projekte, ergänzt um zentrale Governance-, Netzwerk- und Security-Komponenten (z. B. ein separates Netzwerk-/Steuerungsprojekt). Die Landing Zone ist damit kein einzelnes Produkt, sondern eine zusammengesetzte Architektur.
Governance: Wie werden projektübergreifende Setups und Netzwerke gelöst?
OVH: Projektübergreifende Setups werden über zusätzliche, dedizierte Projekte gelöst, die ausschließlich der Netzwerk- und Verbindungssteuerung dienen. Dort laufen z. B. Firewall-Cluster, Routing und VPN-Komponenten, über die mehrere Projekte miteinander, mit On-Premises oder mit anderen Clouds verbunden werden. Je nach Sicherheits- und Compliance-Anforderungen kommen Layer-2- oder Layer-3-Konzepte zum Einsatz.
Fehlende Komponenten & Eigenleistung
Fehlende Services: Welche zentralen Bausteine fehlen aktuell noch?
OVH: Es fehlen aktuell noch einige zentrale Netzwerk- und Security-Bausteine, vor allem Managed Firewall-, VPN- und erweiterte Routing-Komponenten. Viele dieser Funktionen lassen sich zwar umsetzen, erfordern aber noch hohe Eigenleistung (z. B. eigene Firewall-Appliances). OVHcloud ist sich dieser Lücken bewusst; mehrere dieser Komponenten sind bereits auf der öffentlichen Roadmap, teils in Entwicklung, Beta oder Planung, und sollen schrittweise ergänzt werden.
Netzwerk & Firewall: Wo ist heute noch viel Eigenbau nötig?
OVH: Vor allem im Netzwerk- und Security-Bereich ist aktuell noch viel Eigenbau nötig. Funktionen wie Firewall-Regelsätze, IDS/IPS, Zero-Trust-Gateways oder VPNs sind nicht durchgängig als Managed Services verfügbar und müssen meist über eigene Appliances (z. B. als VM oder Bare Metal) umgesetzt werden. Die technischen Grundlagen sind vorhanden, der Komfort und Automatisierungsgrad entsprechen aber noch nicht dem von Hyperscalern.
Managed VPN: Gibt es einen Managed-VPN-Service oder zumindest eine Roadmap?
OVH: Einen vollwertigen Managed-VPN-Service gibt es aktuell noch nicht, er ist aber auf der Roadmap. Ein solcher Service ist ausdrücklich vorgesehen, vor allem für PoC-, Migrations- und Einstiegsszenarien, um den Start zu erleichtern. Bis dahin nutzt OVHcloud Übergangslösungen über eigene VPN-Appliances (z. B. via Terraform-Templates oder NSX-basierte Lösungen in der Private Cloud), die jedoch mehr Eigenaufwand bedeuten.
Wechsel von Hyperscalern
Hyperscaler-Wechsel: Wo müssen sich AWS-, Azure- oder GCP-Nutzer umgewöhnen?
OVH: Nutzer müssen sich vor allem bei Netzwerk-, Logging- und Kostenkonzepten umgewöhnen. OVHcloud funktioniert nicht wie ein „VPC-zentrisches“ Hyperscaler-Modell, sondern stärker projekt- und komponentenbasiert. Viele Funktionen, die bei Hyperscalern als integrierte Managed Services verfügbar sind, erfordern bei OVHcloud mehr Eigenkonfiguration oder zusätzliche Architekturentscheidungen. Außerdem sind Kostenübersicht und Governance weniger zentralisiert, was zu Beginn erklärungsbedürftig ist.
Lernkurve: Wo habt ihr bei Migrationen den größten Erklärbedarf?
OVH: Der größte Erklärbedarf entsteht bei Netzwerk- und Konnektivitätskonzepten, insbesondere bei VPC-Vergleichen, vRack(virtuelles Rack), Layer-2/Layer-3-Unterschieden und bei der Anbindung externer Netze. Zusätzlich gibt es häufig Fragen zur Kostenübersicht, zum Logging/Auditing sowie dazu, welche Services managed sind und welche nicht. Diese Themen erfordern bei Migrationen meist die meiste Begleitung durch Professional Services.
Terraform, APIs & OpenStack
Terraform Provider: Reicht der OVH-Provider aus oder braucht man OpenStack zusätzlich?
OVH: Der OVHcloud-Terraform-Provider reicht in den meisten Fällen aus und deckt den Großteil der Public-Cloud-Funktionen ab. In einzelnen Szenarien, insbesondere bei Netzwerk-Details oder älteren/unterliegenden OpenStack-Funktionen, kann der OpenStack-Provider weiterhin notwendig sein. Ziel von OVHcloud ist es, den eigenen Provider API-first und möglichst vollständig zu halten; neue Features kommen zuerst per API und werden kurz darauf im Terraform-Provider ergänzt.
Automatisierung & CI/CD: Wie integriert sich OVHcloud in bestehende CI/CD-Pipelines – und gibt es dabei noch manuelle Brüche?
OVH: Die Public Cloud ist API-first aufgebaut und über Terraform automatisierbar. Infrastruktur lässt sich in CI/CD-Pipelines wie GitHub Actions oder GitLab integrieren und versioniert ausrollen. In einzelnen Bereichen – etwa beim Umgang mit Credentials oder bestimmten Netzwerkdetails – sind jedoch noch zusätzliche Schritte oder Workarounds erforderlich.
Dritt-Anbieter-Tools: Wie gut integriert sich OVHcloud in bestehende DevOps-Toolchains (z. B. GitHub, GitLab) – insbesondere im Zusammenspiel von Versionskontrolle, CI/CD und Cloud-API?
OVH: OVHcloud setzt auf offene APIs und Terraform als primäre Integrationsschnittstelle. Eine direkte, tief integrierte Toolchain-Strategie (z. B. native GitHub- oder GitLab-Features) steht weniger im Vordergrund. Die Integration erfolgt primär über Standard-Schnittstellen und IaC.
OpenStack Abhängigkeit: In welchen Fällen kommt man aktuell nicht drum herum?
OVH: Man kommt aktuell vor allem bei bestimmten Netzwerk- und Infrastruktur-Details nicht ganz um OpenStack herum, etwa bei Ports, Subnetzen, Netzwerk-Anbindungen oder speziellen Compute-Einstellungen, wenn diese über den OVH-Terraform-Provider noch nicht vollständig oder stabil abgebildet sind. Auch wenn Ressourcen-IDs oder Konfigurationsparameter benötigt werden, die in der OVH-UI oder Dokumentation schwer auffindbar sind, wird OpenStack häufig als praktischer Workaround genutzt. Wichtig ist dabei: VREG vRack ist keine OpenStack-Komponente, sondern wird über OVH-eigene APIs gesteuert.
API First: Gibt es Features, die es zuerst nur per API gibt?
Ja. OVHcloud arbeitet API-first. Neue Funktionen stehen zuerst über die API zur Verfügung und werden kurz danach im OVH-Terraform-Provider ergänzt. Dadurch kann es zeitweise Features geben, die per API nutzbar sind, aber noch nicht als Terraform-Ressource existieren. Ziel ist, diese Lücke möglichst klein zu halten und neue Funktionen schnell vollständig automatisierbar zu machen.
IAM & Policies
IAM Policies: Sind Policies projektübergreifend nutzbar?
OVH: Ja. IAM-Policies sind projektübergreifend nutzbar und gelten nicht nur für einzelne Projekte, sondern übergreifend für mehrere Projekte und Services. Der Ansatz ist, organisationsweite Governance zu ermöglichen, sodass Zugriffe zentral gesteuert und konsistent über verschiedene Umgebungen hinweg durchgesetzt werden können.
Enterprise Policies: Können organisationsweite Policies definiert werden?
OVH: Ja. OVHcloud unterstützt organisations- bzw. unternehmensweite Policies, die zentral definiert und über mehrere Projekte und Services hinweg angewendet werden können. Ziel ist es, Enterprise-Governance (z. B. einheitliche Zugriffsregeln, Rollen und Sicherheitsvorgaben) cloudweit umzusetzen und nicht projektweise neu zu definieren.
IaC Policies: Lassen sich Policies vollständig per Terraform steuern?
OVH: Ja, IAM-Policies sind im OVHcloud-Terraform-Provider enthalten und können grundsätzlich als Infrastructure as Code verwaltet werden. Einzelne Funktionen wurden schrittweise ergänzt, aber der Ansatz ist klar: Policies sollen versionierbar, auditierbar und automatisiert über Terraform steuerbar sein, nicht nur über die UI.
Kosten & Transparenz
Kostenübersicht: Wie bekommen Kunden laufende Kostentransparenz?
OVH: Eine zentrale, integrierte Kostenübersicht wie bei Hyperscalern gibt es aktuell noch nicht. Kunden sehen Kosten primär über die Monatsrechnung sowie projektbezogene Übersichten. Laufende Transparenz, Forecasts oder Dashboards lassen sich über die API realisieren, müssen aber selbst gebaut werden. OVHcloud unterstützt dabei teilweise über Professional Services; eine bessere native Kostenübersicht ist als Bedarf erkannt.
Forecasting: Gibt es Forecasts oder zentrale Dashboards?
OVH: Es gibt keine voll integrierten, zentralen Forecast- oder Kosten-Dashboards über alle Projekte hinweg. Teilweise sind projektbezogene Übersichten vorhanden, und über die API lassen sich Forecasts und Dashboards selbst aufbauen, z. B. mit der Log-Data-Plattform. Für solche Lösungen unterstützt OVHcloud bei Bedarf über Professional Services; native, umfassende Forecast-Funktionen sind bislang begrenzt.
Managed Databases & Automatisierung
Managed Databases: Warum sind DB-User teilweise so stark eingeschränkt?
OVH: Die Einschränkungen kommen daher, dass die Managed-Datenbanken teilweise von externen Backend-Partnern betrieben werden. Um die Stabilität, Automatisierung und Wiederherstellbarkeit der Services sicherzustellen, sind die vergebenen Standard-User-Rechte bewusst limitiert. Dadurch wird verhindert, dass Nutzer Änderungen vornehmen, die interne Betriebsprozesse oder das Lifecycle-Management der Datenbank beeinträchtigen könnten – auch wenn das in einzelnen Anwendungsfällen als zu restriktiv empfunden wird.
Automatisierung: Wie lassen sich Credentials sauber automatisiert weiterreichen?
OVH: Im aktuellen Stand ist das nicht durchgängig „out of the box“ gelöst. Teilweise muss man Credentials oder Secrets nach dem Provisioning manuell auslesen bzw. weiterreichen, was die Vollautomatisierung stört. OVHclouds Zielbild ist, das stärker über IAM/Policies und IaC sauber steuerbar zu machen, damit Zugriffe und Berechtigungen granularer und automatisierbar werden und man weniger manuelle Schritte braucht.
Logging & Observability
Observability: Wie umfangreich gibt es hierzu Features in der Public Cloud umgesetzt?
OVH: Die meisten Public-Cloud-Services sind an die Log-Data-Plattform angebunden, insbesondere Kubernetes und Managed Databases. Neue Services werden standardmäßig mit Observability-Integration entwickelt. Eine vollständige Abdeckung – insbesondere im Netzwerk – ist jedoch noch nicht erreicht.
Logging: Welche Services sind bereits an die Log-Data-Plattform angebunden?
OVH: Kubernetes-Cluster, Managed Databases und neuere Cloud-Produkte liefern ihre Logs an die Log-Data-Plattform. Ältere Produkte werden schrittweise integriert.
Auditing: Wo fehlen noch Audit-Logs?
OVH: Audit-Logs fehlen aktuell vor allem im Netzwerkbereich (Routing, Firewall, Konnektivität). Compute- und Datenbankaktionen sind weitgehend nachvollziehbar, Netzwerkänderungen jedoch noch nicht vollständig.
Marketplace & Ökosystem
Marketplace: Gibt es einen Marketplace für Drittanbieter?
OVH: Ja, es gibt einen Marketplace für Drittanbieter, dieser ist aber regional unterschiedlich ausgebaut. In Frankreich existiert bereits ein Marketplace, während er in anderen Ländern (z. B. Deutschland) noch im Aufbau bzw. weniger sichtbar ist. Der Marketplace wird als wichtiger Bestandteil des Ökosystems gesehen, befindet sich aber noch in einer frühen Ausbaustufe.
Partnerrolle: Welche Rolle spielen Partner bei fehlenden Managed Services?
OVH: Partner spielen eine zentrale Rolle, wenn Managed Services fehlen. Sie übernehmen vor allem Design, Aufbau und Betrieb von Komponenten wie Firewalls, VPNs oder Spezial-Services, die OVHcloud selbst (noch) nicht managed anbietet. OVHcloud setzt bewusst auf ein Partner-Ökosystem, um Lücken zu schließen, insbesondere bei komplexen oder kundenspezifischen Anforderungen, während eigene Professional Services primär beim Initialaufbau, nicht beim dauerhaften Betrieb unterstützen.
