Sécurité et « soft power », les deux piliers de la stratégie DbaaS de Microsoft
Lors de Build 2021, Microsoft a consacré plusieurs annonces à ses bases de données qu’il cherche à sécuriser, à améliorer, mais aussi à imposer face à certains DbaaS du marché.
Lors de l’événement virtuel, Microsoft a mis l’accent sur Cosmos DB. La base de données NoSQL a le droit à sept annonces. La disponibilité générale d’un mode serverless (pour les API Core, MongoDB, Gremlin, Cassandra et Table) est sans doute le point clé de la communication du fournisseur qui y associe un modèle tarifaire à la consommation.
« Avec la technologie serverless, les développeurs n’ont plus à se préoccuper de la provision des ressources et à déterminer quand les augmenter ou les diminuer ; cet aspect est géré “automagiquement” (automagically en VO-sic) pour eux », s’enthousiasme Rohan Kumar, corporate vice-président, Azure Data chez Microsoft. « Il vous reste à déterminer combien vous souhaitez dépenser dans le service », ajoute-t-il.
« Avec la technologie serverless, les développeurs n’ont plus à se préoccuper de la provision des ressources, [...] cet aspect est géré “automagiquement” (sic) pour eux ».
Rohan KumarCorporate vice-président, Azure Data, Microsoft.
Azure Cosmos DB, de plus en plus proche de MongoDB
Interrogé par SearchDatabaseManagement [Propriété de Techtarget, également propriétaire du Magit], Jeffrey Hammond, analyste chez Forrester Research considère l’offre Cosmos DB Serverless intéressante. Selon lui, les développeurs qui utilisent déjà les fonctions au sein de leurs applications peuvent rapidement atteindre les limites du SGBD ou à l’inverse surprovisionner la base de données pour supporter la charge.
« Selon moi, la meilleure illustration c’est la possibilité de faire correspondre les Azure App Services, par exemple Azure Functions, les static web apps et un Cosmos DB dans sa version serverless, sans se poser la question de dimensionner à l’avance les capacités d’infrastructure nécessaires », déclare Xavier Perret, Directeur Azure chez Microsoft France auprès du MagIT.
Pour autant, le géant du cloud se veut plus prudent dans son « book of news » en sous-entendant que le mode à la consommation n’est pas idéal pour tous les cas d’usage.
« Il convient parfaitement aux applications ayant des exigences de performance modérées et des périodes fréquentes avec peu ou pas de trafic », peut-on lire.
Encore une fois en préversion, Azure Cosmos DB a le droit à une fonction de cache intégré afin d’accélérer les lectures. Cette capacité associée à l’API Core dépend en réalité d’un nœud sur une passerelle dédiée. La latence moyenne pour les lectures de points de données mis en cache varierait entre 2 et 4 millisecondes. Microsoft considère que cette fonctionnalité est intéressante pour diminuer la latence des lectures « des éléments volumineux (>16 Ko) » et pour les « requêtes à RU élevées ou complexes ».
« L’objectif principal du cache intégré est de réduire les coûts liés aux charges de travail lourdes en lecture. Une faible latence, bien qu’utile, n’est pas l’avantage principal du cache intégré, car Azure Cosmos DB est déjà rapide sans mise en cache », peut-on lire dans la documentation.
Quant à la capacité « Partial Document Update », présentée en préversion privée pour l’API Core et les SDK .NET et Java, elle doit faciliter la modification d’un champ spécifique ou d’une propriété au sein d’un document, sans le changer entièrement. Cela réduirait les coûts supplémentaires de lecture, diminuerait la latence, la taille des payloads et la consommation CPU.
Microsoft cherche à prouver la pertinence de sa base de données pour toutes les équipes. À l’argument serverless, le géant du cloud ajoute l’extension du tiers gratuit de Cosmos DB avec un débit de 1 000 unités de requête (RU/s) et 25 Go d’espace de stockage gratuit par mois « pendant toute la durée de vie d’un compte Azure Cosmos DB par abonnement Azure ». Microsoft présente aussi un émulateur Linux pour tester localement la base de données sur une machine Linux ou macOS.
Xavier Perret considère qu’il s’agit de répondre « aux besoins de flexibilité des entreprises », peu importe leur taille. Pour les usages critiques, le dirigeant français se rapporte aux autres annonces dédiées à Cosmos DB et à sa sécurité.
Plus de sécurité dans les DBaaS Azure
En l’occurrence, Microsoft greffe une fonctionnalité RBAC en disponibilité générale afin de gérer les accès (des personnes ou des équipements autorisés) via Azure Active Directory. Pour l’instant, l’AAD est intégré avec l’API Core (SQL). En préversion, la fonction « Always Encrypted » de Cosmos DB permet de chiffrer les données au sein de la base de données quand elle est associée avec l’API SQL. Dans ce mode, des clés DEK cryptant les données sont stockées dans des conteneurs Azure Cosmos DB, encapsulées par des clés CMK placées dans une instance Azure Key Vault.
La majeure partie de ces fonctionnalités sont déjà disponibles pour les clients de MongoDB Atlas. Est-ce à dire que Microsoft veut supplanter la DBaaS concurrente ? À cette question, Xavier Perret ne répond pas directement, mais laisse entendre les échos d’une stratégie globale.
« Nous voulons faire de Cosmos DB la destination NoSQL de référence des applications modernes ».
Xavier PerretDirecteur Azure, Microsoft France
« Nous voulons faire de Cosmos DB la destination NoSQL de référence des applications modernes », affirme le directeur français.
Pour les projets requérant des bases de données SQL, Microsoft dispose d’Azure Database pour PostgreSQL et pour MySQL. Là encore, le géant du cloud annonce la disponibilité le 15 juin prochain d’une offre gratuite pendant 12 mois pour Flexible Server afin « d’exécuter de petits workloads gratuitement » sur Azure Database for PostgreSQL avec 750 heures d’utilisation et 32 Go de stockage par mois.
Aussi, l’offre managée PostgreSQL d’Azure dispose en préversion d’un niveau de base (sans SLA) pour activer la fonction « Hyperscale » (issue du projet Citus), c’est-à-dire une capacité de sharding pour paralléliser/distribuer les requêtes SQL et les données entrantes sur plusieurs machines. Cette option est avant tout mise en avant pour tester Hyperscale, car le projet s’adresse aux entreprises qui administrent de déploiements importants de bases de données PostgreSQL multitenant, ou qui veulent pratiquer des méthodes analytiques en temps réel sur de gros jeux de données.
Parmi les mises à jour des services MySQL et PostgreSQL de Microsoft, figure la disponibilité générale d’Azure Defender pour ces deux SGBD. Azure Defender doit renforcer la protection des données des applications et détecter les tentatives d’accès inhabituelles.
Azure SQL Database Ledger, la réponse à Oracle Blockchain Table et Amazon QLDB
Toujours dans cette volonté de protéger les informations contenues dans les bases de données relationnelles, Microsoft a mis l’accent sur la préversion de la capacité Ledger d’Azure SQL Database. Il s’agit d’offrir un registre de type blockchain pour certifier l’immutabilité des transactions. Le géant du cloud est clair : il ne s’agit pas d’une blockchain, mais d’un ledger (registre) qui assure une forme d’intégrité nommée « Forward Integrity » en introduisant une structure décentralisée dans un environnement centralisé, ici une base de données.
En ce sens, Microsoft ne fait pas l’erreur d’Oracle, dont la fonctionnalité équivalente se nomme « Blockchain Table », un nom qui peut porter à confusion. SQL Ledger hache chaque transaction par chiffrement (SHA-256, a contrario Oracle emploie SHA-512) en partant de la valeur d’entrée de la traction ainsi que le hash de la transaction précédente, comme dans une blockchain distribuée (et à l’instar de Blockchain Table).
Sauf que contrairement à Oracle, Microsoft ne fait pas confiance à la base de données et stocke les hachages chiffrés nommés « synthèses de bases de données », qui représentent l’état de la base de données, dans un espace de stockage dit inviolable (des blobs immuables d’Azure Blob Storage ou dans les enclaves matérielles des instances Azure Confidential Ledger). C’est l’approche également choisie par AWS pour QLDB sur un SBGD orienté documents.
Avec SQL Ledger, les utilisateurs peuvent utiliser deux types de tables : des tables pouvant être mises à jour, prenant en charge les opérations de suppression et d’insertion, et des tables ne permettant que l’ajout de donnée uniquement. Dans les deux cas, la création d’une table entraîne automatiquement la génération d’une vue de registre (Ledger View). Pour une table supportant les opérations Update et Delete, la vue est une jointure entre ladite table et une table d’historique associée retraçant toutes les opérations. Quand la table ne peut être modifiée, la vue de registre enregistre toutes les insertions.
En clair, cela permet de comparer les données présentes dans une base et la vérité attendue, et ainsi valider des processus critiques ou des transactions financières. Néanmoins, l’impact sur la vélocité du système se fait sentir. Le débit de SQL Ledger par rapport à une instance SQL Server traditionnelle baisse de 6,9 % dans un scénario « Insert Only » et de 30,6 % dans un cas d’usage OLTP. La latence est aussi en hausse, mais de manière générale, les performances seraient 20 fois supérieures à celles proposées par Hyperledger Fabric (une vraie blockchain, distribuée), selon les chercheurs de Microsoft.
