Villamblard, le 31 mai 2021
En quelques années, le cloud est devenu un sujet incontournable pour les DSI des grandes entreprises. Comment se positionne Dalibo, spécialiste du SGBD PostgreSQL ? Étienne Bersac, l’un de nos développeurs, vous en parle.
Quels sont les enjeux actuels autour du cloud ?
Étienne : Le cloud est bien installé dans le paysage de l’IT, mais nous sommes toujours face à la question de la souveraineté. Depuis PRISM en 2014, la situation a certes évolué avec le décollage d’OVHCloud et la concurrence chinoise sur le cloud public. Néanmoins, le “tout public” a fait son temps.
L’IT est reconnue comme un actif stratégique des entreprises, qu’on ne doit pas abandonner aux mains des grands monopoles. Le cloud privé a donc retrouvé son importance dans le choix des DSI. Malheureusement l’offre est encore très immature ou monopolisée.
Le cloud est à un seuil similaire au web des années 2000. À l’époque, la technologie LAMP (Linux, Apache, PHP, MySQL) a ouvert une brèche dans un monde dominé par Java. Depuis, le web carbure au logiciel libre. Dans le même temps, la guerre des navigateurs a poussé l’émergence de standards du web, pour le plus grand soulagement des utilisateurs et des développeurs. Aujourd’hui, le cloud profite lui aussi du logiciel libre. En revanche, la jungle des API rappelle la guerre des navigateurs. De même, les monopoles des grands opérateurs rappelle le verrouillage des grands éditeurs logiciels.
Les entreprises veulent bien du cloud, mais pas d’une prison technologique avec une facturation arbitraire à la clef. C’est là l’enjeu du cloud privé : la technologie cloud est-elle assez mature pour être opérée en interne, avec un niveau de fonctionnalité suffisant pour concurrencer le confort du cloud public ?
Tu as présenté cet automne le projet cornac, explique-nous.
Étienne : C’est dans cet esprit de développer le cloud privé que Dalibo, fort de son expertise en industrialisation de PostgreSQL, a initié le projet cornac. Il s’agit d’une implémentation de l’API AWS RDS (Relationnal Database Service) et une console web administrant un parc de machines virtuelles exécutant PostgreSQL.
Plutôt que de s’isoler dans une niche technologique, nous avons parié sur la compatibilité. Considérons l’API RDS comme le standard de la consommation d’un service DBaaS (DataBase as a Service) et produisons une implémentation libre ! C’est déjà le cas pour S3 (Simple Storage Service, le stockage objet d’AWS) et EC2 (Elastic Compute, le service de machine virtuelle d’AWS). Pourquoi pas RDS ?
Le fait d’être rigoureusement compatible RDS nous ouvre l’accès à un écosystème mature pour l’intégration dans les catalogues de services, les solutions Infrastructure as Code et les outils DevOps en général.
Actuellement, cornac gère le provisionnement, les sauvegardes PITR, la supervision et la haute disponibilité. Le service cornac consomme l’API vSphere vCenter pour provisionner les VM et nous envisageons d’exploiter également OpenStack et pourquoi pas harvester, un orchestrateur de VM dans kubernetes.
Nous avons fait le choix de la VM plutôt que du conteneur pour travailler sur une technologie éprouvée, facile à diagnostiquer en cas de problème. D’ailleurs, AWS RDS fonctionne avec des VM. Ce qui est stratégique pour le projet n’est pas tant le choix VM ou conteneur, mais la compatibilité avec l’API RDS et l’interface. Le principe du cloud est justement d’ignorer le détails d’implémentation derrière un guichet API ou web.
Avec cornac, une entreprise peut monter un DBaaS PostgreSQL sur son infrastructure VMWare existante. Les équipes DBA sont soulagées de nombreuses tâches administratives, les équipes infrastructures et DBA ont une bonne répartition des tâches, les utilisateurs ont accès à un service de haut niveau en accès libre et la DSI a le contrôle sur les usages du service et ses coûts.
Quelles tendances envisages-tu autour des clouds dans un futur proche ?
Étienne : Kubernetes est bouillonnant et cherche encore son chemin. Les prochaines années devraient le voir émerger comme un outil générique d’orchestration de nombreuses ressources. On voit les prémices d’usages de Kubernetes découplés des conteneurs. Cela ouvre de grandes possibilités.
Ainsi, Kubernetes pourrait être le nouveau moteur des infrastructures privées comme vSphere l’est actuellement. À la différence près que Kubernetes a beaucoup plus d’intelligence pour gérer le cycle de vie des ressources.
Néanmoins, deux problèmes persistent : la complexité du déploiement - notamment la sécurisation des ressources - et la disponibilité d’API mature. Il reste encore du chemin au projet Kubernetes pour être stable et accessible sans investir énormément dans la formation d’une technologie très changeante. Docker a connu cette étape autour de 2015. Nous aurons toujours besoin d’implémentation d’API standards au-dessus de cette nouvelle infrastructure.
Liens utiles
- dépôt gitlab du projet cornac
- slides de la conférence d’Étienne à la PGSession 2020.
Des questions, des commentaires ? Écrivez-nous !