Bases de données cloud : ce qui les différencie des bases sur site
Gestion de l’infrastructure, dimensionnement automatique, séparation du compute et du stockage, résilience et disponibilité, paiement à l’usage, serverless ou PaaS, les bases de données dans le cloud constituent le moteur premier des infrastructures de données modernes. Mais qu’est-ce qui les caractérise particulièrement ? Les experts d’Umanis répondent à cette question.
Il est aujourd’hui une évidence : le cloud, et ses capacités intrinsèques, comme l’élasticité, sa puissance de calcul jusqu’alors inégalée et sa consommation à l’usage, est le moteur premier de la transformation des entreprises. Avec leur positionnement au cœur des infrastructures de données, clé de cette transformation, les bases de données suivent inévitablement la même tendance. Leur migration vers le cloud, que ce soit une forme managée ou As-a-Service constitue une évolution naturelle de cette très ancienne technologie centrale de l’IT.
Gartner, qui voit plus de la moitié des workloads liées à des bases de données dans le cloud, pense que le segment des bases de données, dans leur format PaaS (dbPaas donc) constitue aujourd’hui le sous-segment le plus dynamique du PaaS. En 2021, il devrait être assis sur un marché de quelques 10 milliards de dollars. Si les entreprises considèrent les données comme le moteur de leur transformation, les bases qui les serviront seront bien hébergées dans le cloud.
La base de données que l’on place dans une VM sur un Iaas (Infrastructure-As-A-Service). « En ce qui concerne l’installation et l’administration, on est très proche, voire à l’identique, d’un fonctionnement d’une base on-premise », explique Christophe Heng, Cloud Data Practice Manager chez Umanis. En gros, la base que l’on dispose sur site, est placée dans une ou plusieurs VM sur une infrastructure cloud. Son hébergement est seul externalisé.
La base de données managée. Le niveau d’abstraction est supérieur à la précédente. « La création d’une instance est très simple et se fait juste en renseignant différentes options dans un formulaire », affirme encore le responsable. « Il convient donc de démarrer une base pour l’utiliser et de l’éteindre lorsqu’on n’en a plus besoin. » On paie généralement le temps d’allumage de l’instance – cela varie en fonction de la puissance (RAM et CPU) et de la capacité de stockage, complète-t-il. La facture n’est pas calculée à partir du nombre de requêtes.
La base de données serverless. Il s’agit du niveau d’abstraction le plus élevé. « La base est déjà installée et toujours disponible. On paie en général peu pour le stockage, mais on paie en plus le requêtage à l’usage », assure-t-il.
Gestion de l’infrastructure et dimensionnement
Logiquement, ce qui caractérise les bases de données natives dans le cloud (Paas et serverless donc), c'est qu'elles exploitent les spécificités inhérentes du modèle ; à savoir ses capacités de dimensionnement élastique, sa disponibilité et sa résilience, ainsi que son paiement à l’usage, rappelle Fabrice Macarty en charge des activités Cloud Architecture Practice chez Umanis. La sécurité est également un élément clé puisqu’on bénéficie des investissements consentis par les fournisseurs de cloud en la matière.
Cette scalabilité permet donc aux bases de répondre « aux variations de charges de travail grâce à des mécanismes automatiques de provisionnement et de dé-provisionnement de ressources de stockage et de calcul ». La solution est donc toujours dimensionnée pour répondre à l’activité qui lui est soumise, que ce soit via une scalabilité verticale (scale-in) ou horizontale (scale-out).
« Les bases de données cloud en PaaS et serverless bénéficient largement de ces mécanismes qui garantissent à la fois des coûts d’usages optimaux et des niveaux de performances techniques stables. »
Fabrice MacartyEn charge des activités Cloud Architecture Practice, Umanis
« Les bases de données cloud en PaaS et serverless bénéficient très largement de ces mécanismes qui garantissent à la fois des coûts d’usages optimaux et des niveaux de performances techniques stables », souligne encore Fabrice Macarty.
Comparé aux bases traditionnelles sur site, ces mécanismes libèrent aussi l’administrateur des douloureuses tâches de gestion des ressources. « Une base traditionnelle sur site nécessite la réalisation d’opérations de provisionnement et de gestion de l’infrastructure et des ressources (serveur, disques, réseau, …). Des tâches « coûteuses à réaliser ».
Autre point, outre le fait de garantir un forme adaptée de la base aux workloads, les niveaux de disponibilité et de résilience sont également assurés. « En plus d’être redondées par défaut sur une ou plusieurs régions ou datacenters dès la phase initiale du provisionnement de l’architecture, les DBaaS présentent des mécanismes robustes et automatiques de distribution des données, de failover et de continuité d’activité, rendant ainsi le service de base de données hautement disponible », indique encore le spécialiste.
Compute n’est pas stockage
Ces possibilités de dimensionnement se retrouvent également dans le modèle architectural d’une base de données purement cloud. Dans celle-ci, la séparation des fonctions constitue en effet une particularité. Avec une base traditionnelle, en effet, l’ajout de capacité de compute ne peut pas se faire sans l’ajout de capacités de stockage associé. Impossible également de dimensionner à la volée une partie sans affecter l’autre. En revanche, une base cloud, dans une architecture PaaS et serverless, hérite des capacités de dimensionnement inhérentes au modèle. On ajoute du compute indépendamment du stockage par exemple. « Ceci présente un double avantage », résume Fabrice Macarty, en charge des activités Cloud Architecture Practice chez Umanis : « une disponibilité accrue pour les utilisateurs lors de l'ajout ou la suppression de capacités et de ressources car aucune interruption de service n'est observée ; et une maîtrise des coûts au plus juste grâce à une allocation fine des moyens nécessaires aux bases de données. »
Cette approche a donc un effet sur la consommation des ressources et constitue donc un point clé pour la gestion des coûts qui, théoriquement, est ajustée au niveau d’utilisation des composants. Il est important de s’interroger en amont sur le niveau de dépenses, d’abord existant, puis celui à considérer. « Combien dépensez-vous actuellement pour le stockage et le requêtage de données ? » est une question à se poser, lance Christophe Heng, Cloud Data Practice Manager chez Umanis. Pour lui, cette séparation du compute et du stockage peut « amener des réductions de coûts drastiques ».
Snowflake, qui développe une solution d’entrepôt de données 100 % cloud, fait partie de ces éditeurs qui exploitent toutes les spécificités du cloud pour motoriser sa plateforme - notamment cette séparation des couches compute et stockage. Snowflake y adosse même son concept de « data-sharing » qui permet à des entreprises d’autoriser l’accès - global ou partiel - aux données, à des partenaires via un modèle de licencing dédié. En dissociant le compute du stockage, Snowflake peut appliquer différents flux de traitement sur les données, en parallèle.
Reste que côté pricing justement, les tarifs des fournisseurs de services cloud ne se ressemblent que très peu. « Là où Microsoft préférera établir la grille de pricing de SQL Data Warehouse sur des DWU (pour Data Warehouse Units) qui correspondent à des blocs de puissance de calcul pour un coût de stockage fixe, Google aura une approche par coûts de stockage selon les usages et le temps, combinés au volume de données manipulées par les appels API et les lectures / insertions », évalue encore Fabrice Macarty. De quoi en effet s’y perdre, même si toutefois, des optimisations financières sont possibles, constate-t-il. Pour lui, la réservation de ressources peut dans ce cas s’avérer payante.
Ce qu’apporte le serverless aux bases de données
Mais aujourd’hui, c’est bien vers le serverless que tous les regards se tournent lorsqu’il est question de bases de données dans le cloud. Qu’elles soient relationnelles ou non, les services de bases de données se multiplient, avec pour objectif de les passer à une architecture serverless, capables de satisfaire les très tendance équipes DevOps.
« Le serverless offre énormément de facilité d’usage, notamment pour les Ops », souligne Christophe Heng. Tout comme les bases managées, les installations, les déploiements et la configuration (sauf pour certaines bases managées) n’ont pas à être effectuées. L’architecture sous-jacente - et donc le fournisseur - s’en charge. Le fournisseur a aussi la pleine charge des possibilités de provisionnement et de dimensionnement des ressources. « Plus besoin d’ajouter de puissance et de capacité de stockage ou des VM supplémentaires, on peut ajouter des données sans se soucier des performances ou de la capacité de stockage », reprend encore le spécialiste d’Umanis, qui met en avant l’approche centrée sur les niveaux d’usages.
Les performances sont ainsi garanties sans autre configuration, ni ajustements, voire même sans avoir le besoin de les monitorer. Cela est accompagné d’une « fiabilité et disponibilité, avec des SLA souvent proches, voire au-delà des 99,99 %, comme pour une base managées », rappelle-t-il.
Même son de cloche pour les développeurs : ils sont soutenus par cette scalabilité automatique et la garantie de performances, sans autre contrainte, lance-t-il encore.
Pourtant, les forces des bases serverless sont aussi leurs défauts. « Elles offrent peu voire pas de possibilités de tuning de performance », constate Christophe Heng. Ce qui peut constituer un vrai point négatif si justement, les performances ne sont pas conformes aux attentes.
Mais le point noir du serverless est celui de la gestion des coûts, souvent qualifiée d’imprévisible. « Les coûts sont difficiles à prévoir car la facturation se fait à l’usage et il y a souvent des surprises en fin de mois. Ce modèle de pricing, s’il est très économique pour un usage modéré, peut également être un frein pour une utilisation à grande échelle », prévient-il. Et cela pourrait pousser l’entreprise à en minimiser les usages, « ce qui entre alors en contradiction avec les stratégies data-driven », très chères aux entreprises.
