Avant de plonger dans le vif du sujet, faisons un petit rappel.

Derrière ce comparatif se cachent trois ingénieurs de Techsys : Jean-Yves, Alexandre et Audric. Tous trois ont travaillé plusieurs années sur les plateformes AWS et GCP. C’est pour cela que vous verrez parfois des comparaisons avec ces géants américains. Notre regard est naturellement teinté de cette expérience.

L’article est structuré en mode interview : nous y avons conservé l’architecture des questions posées lors de nos échanges, suivies d’une synthèse collective des réponses.

Ce qui suit reste notre ressenti personnel après environ deux semaines de tests. Ce n’est pas une vérité absolue. Les catalogues cloud évoluent très vite.

Et pour les outils ? On a demandé de l’aide à deux assistants intelligents : Leexi et Lumo. Pourquoi eux ? Parce qu’ils sont européens et souverains. Une relecture approfondie humaine avec quelques corrections a ensuite été faite.

Nous avons utilisé les icônes de Vectorslab pour illustrer cet article.

Bonne lecture.

Qu’est-ce que vous avez aimé dans l’interface OVHcloud ? À contrario, quels sont les irritants dans l’interface OVHcloud ?

L’interface OVHcloud conserve la notion de projet à l’intérieur d’OVHcloud Public Cloud. Cependant, nous avons constaté que la gestion de projet semble mélangée avec les notions de compte OVH legacy. Le principal irritant est le manque d’homogénéité et d’unicité globale. Il y a un manque de côté agnostique qui devrait exister dans tout cloud provider. Cela crée une sensation similaire à avoir accès à Amazon et AWS ou Google et GCP dans la même interface alors que ce sont des produits différents. Tout est mélangé, et cela devient difficile de savoir où trouver l’information même lorsque celle-ci est écrite.

Qu’est-ce que vous avez aimé dans l’interface Scaleway ? À contrario, quels sont les irritants dans l’interface Scaleway ?

Sur Scaleway, plusieurs aspects nous ont plu. La partie cost management est accessible rapidement, apparaissant parmi les menus principaux. Il est possible de mettre en place des alertes de budget ou de facturation dès le départ, ce qui est facile même sans connaissance préalable en FinOps. L’aspect organisation et projet est bien mis en valeur, avec une organisation en mode projet qui semble naturelle. Chaque projet contient ses propres ressources de manière claire.

Le seul irritant relevé est mineur : lors de la création d’un service, les détails s’affichent sur la partie droite de l’écran mais si on veut annuler la création, il faut cliquer sur le bouton close en haut à droite de cet écran pour que ces détails se ferment. C’est un détail mais c’est le seul point que nous ayons identifié comme pouvant être amélioré.

Sur la partie réseau, des éléments à noter ?

Côté OVHcloud, l’infrastructure réseau repose sur OpenStack avec la notion de vRack, de VLAN et de subnet. Le provider Terraform est fourni par OVH mais présente plusieurs ressources pour un même type de fonctionnalité sans indication claire de quelle version utiliser (bêta, dépréciée ou stable). La documentation reste en retard par rapport aux capacités réelles du provider, même si nous avons constaté des améliorations en cours.

Une notion particulièrement perturbante chez OVHcloud est celle des local zones. Ce sont des zones très spécifiques à activer avant utilisation, avec un catalogue de services réduit. Elles permettent d’être présent sur plusieurs continents (Amérique du Nord, Asie) alors que les principales régions restent en Europe et au Canada. Certaines régions proposent une configuration multi-AZ, d’autres sont mono-AZ.

Côté Scaleway, il existe la notion d’AZ mais pas de local zone, ce qui rend le modèle plus lisible et proche des standards connus. En revanche, nous avons noté que le nombre de régions reste limité : Paris, Amsterdam, Varsovie, et Milan qui monte progressivement. Scaleway intègre un IPAM qui est encouragé à l’usage, ce qui structure le réseau et évite les conflits d’adressage.

Un point commun structurant que nous avons relevé entre les deux providers : les IP publiques et privées restent rattachées à une seule zone de disponibilité. Cela contraste avec AWS ou GCP où un load balancer peut avoir une IP régionale couvrant plusieurs zones.

Pour le premier scénario (VM simple dans un VPC avec accès SSH, gestion de configuration, patch) : que dire sur OVHcloud ? Puis, pour le scénario suivant (instances derrière un load balancer, avec et sans autoscaling) : qu’avez-vous constaté sur OVHcloud ?

Pour le scénario de base (VM simple dans un VPC avec accès SSH), nous avons constaté que les deux providers permettent de créer des instances, de les tester manuellement et de les automatiser avec Terraform. Aucun ne propose de service de patch management ou de configuration management managé : tout reste du vanilla à gérer soi-même.

Côté OVHcloud, nous avons noté que le catalogue d’images est restreint avec seulement quatre options sur la marketplace (cPanel, Plex, Docker et une autre application). Les images OS incluent AlmaLinux, Rocky, Debian et Ubuntu, mais pas RHEL ni SUSE. Aucune information n’est fournie sur le type de processeur. L’empreinte carbone n’est pas affichée. Par contre, un accès VNC est disponible depuis la console. La gestion des clés SSH crée de la confusion avec deux ressources différentes dont la dépréciation n’est pas clairement indiquée.

Et sur Scaleway ?

Côté Scaleway, le catalogue d’images est plus fourni avec RHEL disponible entre autres. L’empreinte carbone est affichée pour chaque service et région. La configuration se base sur la solution opensource « cloud-init » qui permet une grande souplesse de paramétrage. Les images sont gérées par zone, ce qui nécessite une gymnastique pour les déplacer (snapshot vers bucket régional puis réimport dans l’autre zone).

Pour le scénario avancé (instances derrière un load balancer avec autoscaling), Scaleway propose un autoscaling group, même si nous avons remarqué que la partie Terraform n’est pas entièrement à jour et qu’il y a un problème de version d’API à creuser. Chez OVHcloud, ce service n’existe pas : aucune notion d’autoscaling n’apparaît ni dans la documentation ni dans le provider Terraform. Pour le load balancer, OVHcloud utilise une IP flottante régionale, et les frontends peuvent être répartis sur les zones du subnet sans problème majeur.

Qu’avez-vous noté pour la partie bases de données (PostgreSQL et NoSQL) côté OVHcloud ? Puis sur Scaleway ?

Pour les bases de données relationnelles, nous avons trouvé que Scaleway propose PostgreSQL (versions 14, 15, 16, 17) et MySQL 8. En NoSQL, on trouve MongoDB, Redis, OpenSearch et RabbitMQ en bêta. Un service serverless SQL existe mais n’a pas été testé. Le cluster PostgreSQL inclut hot standby et réplicas en lecture seule, avec des ACL pour restreindre les accès IP.

Côté OVHcloud, le service de bases de données s’appuie sur un partenariat avec Aiven. Le catalogue est riche : PostgreSQL avec master et slave accessible en lecture, MySQL, MongoDB, Kafka, ClickHouse et OpenSearch. Ces services sont disponibles via la console OVHcloud. Cependant, nous n’avons pas trouvé de moyen de sélectionner des extensions PostgreSQL depuis la console.

Y a-t-il côté OVHcloud des outils orientés Big Data ? Et du côté de Scaleway ?

Côté Scaleway, un bloc Data séparé inclut ClickHouse, Apache Spark, Apache Kafka et NATS. Cette partie n’a pas été étudiée en détail car elle nécessite des compétences dédiées en data.

Chez OVHcloud, ces services apparaissent dans la partie analytics avec Kafka Connect et Kafka Notebook Maker. Nous avons également repéré un dashboard qui semble être Grafana.

Sur la partie registry (Harbor côté OVHcloud, container registry côté Scaleway), qu’avons-nous noté ?

Nous avons observé qu’OVHcloud propose Harbor avec trois tailles fixes. Le scan de vulnérabilités des images n’est activé que sur les deux plus grandes tailles. Sur la plus petite registry, le scan n’est pas activable et il faut gérer Trivy soi-même si nécessaire. Scaleway offre une container registry avec gestion par namespace mais sans scan de vulnérabilités intégré : cela doit être géré en CI. Les deux services ne gèrent que le format OCI, sans support des registries Maven, npm ou génériques.

Pour le Kubernetes managé, qu’est-ce qu’on peut dire de l’offre côté OVHcloud ? Et du côté de chez Scaleway ?

Côté OVHcloud, l’offre reste du Kubernetes vanilla avec très peu de surcouche personnalisée. Cilium est imposé comme CNI avec Hubble inclus par défaut. La mise à jour des versions met à jour simultanément le control plane et les nœuds, sans possibilité d’étaler l’opération. L’autoscaling des nœuds est opaque : pas d’accès aux logs ni aux métriques, pas de configuration fine des paramètres. Les images tournent sur Ubuntu 22.04. Nous n’avons pas trouvé d’authentification entre le registry et le cluster. Une option Managed Rancher permet de gérer plusieurs clusters en un endroit. Il existe deux offres à travers le plan « free » et « standard » avec une différence de coût et de disponibilité au sens SLA/SLO. A noter qu’il faut impérativement passer par l’offre standard pour être en multi-AZ au niveau kubernetes.

Côté Scaleway, deux offres existent : Kapsule (gestion simplifiée) et Kosmos (multi-cloud). Le control plane peut être gratuit. Les versions disponibles sont plus récentes. L’autoscaling des node pools est beaucoup plus configurable avec des paramètres fins sur les délais de rafraichissement et les stratégies de création. Les feature gates et admission plugins sont exposés. Cependant, le multi-AZ doit être configuré manuellement via les node pools. Une incohérence a été notée par nous : le provider Terraform indique CRI-O comme runtime possible alors que seul containerd existe en réalité.