La simplicité des SGBD dans le cloud encourage les entreprises à migrer leurs bases vers des bases open source dans le cloud tels PostgreSQL. Mais ce cloud peut très bien être privé et offrir tous les bénéfices attendus sans verrous masqués ni facturation arbitraire.
La facilité d’opérer des bases de données dans le cloud, s’épargnant au passage les contraintes du provisioning, de la maintenance et des mises à jour, incite beaucoup d’entreprises à transférer les données de leurs bases traditionnelles vers des bases open source dans le cloud.
La tendance n’a pas échappé aux principaux fournisseurs de services cloud tels que Microsoft, Google et Amazon Web Services (AWS), qui proposent des services de base de données prenant notamment en charge PostgreSQL.
Pourquoi PostgreSQL ?
Peut-être moins pour sa nature open source (et tous les avantages qui y sont liés) que pour la raison que l’API PostgreSQL a su s’imposer comme un standard de facto. La flexibilité de la solution, l’innovation continue rendue possible par sa communauté de développement ont permis d’accélérer son adoption, la facilité de prise en main et l’interopérabilité contribuent à son succès dans les infrastructures privées et les clouds publics.
La plupart des fournisseurs cloud proposent PostgreSQL car les entreprises souhaitent une plateforme de gestion de données mixte couvrant à la fois les données structurées (PostgreSQL) et non structurées. La proposition par ces fournisseurs d’un SGDBR leur permet en effet d’offrir à leurs clients des capacités et des outils de gestion unifiée des données dans le cloud.
Tandis que la pénurie de développeurs continue de sévir, ces offres peuvent faire l’effet du chant des sirènes pour les entreprises souhaitant faire une commodité de leur SGBDR. L’idée est d’autant plus attrayante que pour la mise en œuvre de projets spécifiques, et puisqu’il n’est pas nécessaire de se familiariser avec un nouvel outil, le temps de mise en service est réduit, la prise en main, facilitée.
Or, les entreprises veulent bien du cloud, mais pas d’une prison technologique assortie d’une facturation arbitraire. Après avoir longtemps lutté contre les pratiques d’audit et de licences d’Oracle, elles prennent désormais le risque d’avoir à se défaire de nouveaux verrous, cette fois situés dans le nuage.
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.
Mais l’enjeu est le suivant : la technologie est-elle assez mature pour être opérée en interne, avec un niveau de fonctionnalités suffisant pour concurrencer le confort du cloud public ?
Force est de reconnaître que l’offre est encore très immature ou monopolisée.
Du DBaaS sur cloud privé
Tandis que le niveau d’automatisation du cloud privé augmente, il semble important d’appliquer les méthodes qui ont fait leurs preuves et de parier sur la compatibilité, plutôt que de s’isoler dans une niche technologique,
Pour l’implémentation de PostgreSQl dans des clouds privés, si l’on considère l’API RDS comme le standard de la consommation d’un service DBaaS (DataBase as a Service), une approche possible consiste donc à implémenter l’API AWS RDS (Relational Database Service) et une console web administrant un parc de machines virtuelles exécutant PostgreSQL, produisant ainsi une implémentation libre de RDS.
Le succès d’usage de S3 (Simple Storage Service, le stockage objet d’AWS) et de EC2 (Elastic Compute, le service de machine virtuelle d’AWS) en a fait des standards industriels.
L’idée est donc d’adopter une approche similaire avec RDS. Une compatibilité rigoureuse avec l’API RDS et son interface 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.
En attendant que Kubernetes, fort de son intelligence pour gérer le cycle de vie des ressources, devienne le nouveau moteur des infrastructures privées comme vSphere l’est actuellement, faire le choix de la machine virtuelle, une technologie éprouvée, dont les problèmes sont faciles à diagnostiquer lorsqu’ils se présentent, plutôt que du conteneur est sans doute une bonne pratique à court terme.
D’autant que le choix VM ou conteneur n’est pas nécessairement stratégique puisque le principe du cloud est justement d’ignorer les détails d’implémentation derrière un guichet API ou web.
Monter un DBaaS PostgreSQL sur son infrastructure VMWare existante permet au DSI de conserver le contrôle sur les usages du service et ses coûts. Cette approche a par ailleurs le potentiel de soulager les équipes DBA de nombreuses tâches administratives, d’améliorer la répartition des tâches entre les équipes infrastructures et les DBA tout en fournissant aux utilisateurs un service de haut niveau en accès libre.
____________________________
Par Étienne Bersac, associé chez Dalibo, le spécialiste français de PostgreSQL