Sql Data Services c’est le service de base de données “on the cloud” de la plateforme Azure. A l’origine il s’appelait d’ailleurs “Sql Server Data Services”.

L’objectif des Sql Data Services est d’offrir un service de base de données relationnelle hautement disponible et permettant la montée en charge, les données sont sauvegardées et répliqués dans des datacenters localisés à différents endroits. L’avantage d’utiliser un tel service “on the cloud” est de s’exonérer de toutes les taches liées à l’infrastructure : Installation, configuration et maintenance, on ne paye qu’a la consommation et au besoin.

Pour Sql Data Services Microsoft avait mis en place une nouvelle couche d’abstraction au dessus de Sql Server, le paradigme ACE pour Authority, Container, Entity:

• Authority : Associé à un nom DNS elle contient des Containers (l’équivalent de l’instance Sql server)
• Container : Elle contient des entités (L’équivalent d’une base de données)
• Entity : L’unité de stockage

Ce paradigme permettait un schéma flexible, un Container pouvait contenir des entités de types différents, par exemple pour le stockage d’un blog :) dans un container, il était possible d’y mettre des entités de type Post et de type Comment. Ou encore d’y mettre plusieurs versions d’une même entité.

Les opérations sur les données se faisaient via une interface standard REST ou SOAP, et il était possible via ces mêmes interfaces de faire des requêtes LINQ avec des jointures.

On aurait pu les appeler les Linq Data Services, puisqu’on était assez loin d’un Sql Server classique finalement. Mais j’avais assez apprécié cette nouvelle approche mêlant flexibilité et avec “un peu” de relationnel, notamment requêter en Linq via Soap ou Rest. Même si j’avais été un peu dérouté au tout début pensant tomber sur un Sql Server Online, à cause du nom originel.

Suite aux retours de preview l’équipe de développement des Sql Data Services au lieu de rechanger le nom du produit encore une fois :) ont décidé de changer d’approche.

Finalement exit le paradigme ACE et l’accès via REST et SOAP, pour plus de relationnel une interface Sql Over Http (TDS pour Tabular Data Stream) exposera une base de données Sql Server plus traditionnelle avec tables, procédures stockées, déclencheurs, index et vues. Pour les questions de sécurités ce sera de l’authentification Sql Server crypté via SSL. Les Sql Data Services seront maintenant beaucoup plus proches d’un Sql Server Online, puisqu’ils annoncent que “si ça marche avec Sql Server ça fonctionnera en grande partie avec Sql Data Services”.

Le paradigme ACE disparait de SDS aussi parce qu’il était assez proche du modèle de l’Azure Storage, les deux offres de stockage (SDS en ACE et Azure Storage) étaient assez proches et ce n’était pas évident d’appréhender les différences entre les deux, et donc commercialement pas de grande valeur ajouté pour les SDS.

A présent les deux offres seront plus claires si vous avez besoin d’un stockage flexible “sans schéma” privilégiez l’Azure Storage et si vous avez besoin d’une base de données relationnel privilégiez Sql Data Services. L’analogie que m’avait dite Régis Mauger lors de la conférence “Optimiser et exploiter Windows Azure” aux Techdays est que l’Azure Storage c’est le système de fichiers proche de l’application et Sql Data Services c’est la base de données relationnelles.

Malheureusement on perd en interopérabilité, plus d’interface REST ou SOAP native. Il faudra se développer son propre service Web REST mais cette tâche sera simplifiée par la compatibilité avec les ADO .Net Data Services. Et d’après l’équipe SDS avec cette même compatibilité on pourra  développer sur son Sql Server local puis déployer son application et sa base de données dans le “cloud”  juste en changeant la chaine de connexion.

Cette révolution devrait apporter une expérience très proche d’un Sql Server en Local,  ainsi le portage d’applications devraient s’en trouver grandement facilité, plus besoin de redévelopper l’intégralité de sa couche données pour une application utilisant Sql Server.

Un des freins à l’adoption d’Azure par bien des développeurs et des entreprises disparaitra ainsi. Et en architecturant correctement ses applications, elles ne seront pas liés à leur hébergement “Azure” et pourront êtres déménagés au besoin sur sa propre infrastructure.

Tout les détails sur les nouveaux Sql Data Services  au “Mix” demain.