Le moteur des données dans le Cloud (2/2)

Qu’en est-il du frontal ? Concernant ce modèle de données équilibré entre la facilité de l’abord et la flexibilité, comment séparons-nous l’administration logique et l’administration physique des données ? Quel niveau de puissance allons-nous mettre dedans tout en étant encore en mesure de l’exécuter de manière automatisée, puisque nous n’avons pas de requêtes incontrôlables ni ce type d’éléments ? Ou établissons-nous la limite ?
Cette limite évoluera au fil du temps à mesure que nous gagnerons en maturité avec ce service. Nous avons un niveau de puissance incroyable au niveau du back-end. Nous n’en montrons qu’une toute petite partie pour le moment. Ainsi, lorsque nous saurons que nous pouvons le faire les yeux fermés et déployer, nous exposerons plus de cette puissance latente avec le temps.

Le frontal sera-t-il une interface Web?
Il s’agit d’un service de base de données. Il correspond à des protocoles REST et compatibles avec Internet, et nous avons également une interface SOAP. Nous retournons les résultats sous une forme exploitable compatible avec Internet, à savoir une extension du protocole de publication ATOM utilisée par Live Mesh, employée par d’autres Live Services et proposée au comité de normalisation. Par conséquent, il est conçu pour être très facile d’abord, notamment en termes de compatibilité avec Internet. Nous avons annoncé la prise en charge d’un kit Ruby et nous gérerons PHP, de sorte que vous pouvez commencer dès aujourd’hui à écrire extrêmement facilement quelque chose en PHP ou en Perl, ou dans votre autre langage de prédilection.

Pensez-vous que cela cible des applications spécifiques ou cela sera-t-il destiné à des applications de base de données traditionnelles ?
C’est une bonne question et, franchement, mon point de vue actuel diffère sensiblement de celui que j’avais il y a 9 à 12 mois. Depuis notre annonce, nous avons appris énormément de choses.

Que pensiez-vous au départ ?
Initialement, je pensais que c’était plus une situation dans laquelle je commence par construire l’application, puis je décide de la déployer sur Internet ou de la déployer sur site. Beaucoup de personnes en sont encore à ce stade. La différence que je perçois est que l’entreprise peut se concentrer exclusivement sur la logique métier et sur l’application. Aujourd’hui, si vous deviez vendre une application ASP.NET plus ou moins partagée, vous devriez assumer une partie du fardeau suivant : Comment vais-je procéder pour la faire évoluer et, si celle-ci évolue, vais-je rencontrer des problèmes ? Si j’ai surdimensionné, jusqu’à quel point cela va-t-il m’affecter ? Vous éliminez complètement ces aspects de l’équation. Concernant les solutions sur site existantes, nous constatons que beaucoup de personnes procèdent à leur extension.

Avec les services Internet, quel sera le rôle du DBA ou en aura-t-il encore un ?
Il est parfaitement clair qu’il a un rôle à jouer. Je demanderais au DBA de faire un retour en arrière et de se poser la question suivante : « Quelles sont les tâches pénibles que j’effectue encore et encore, et qui n’apportent pas réellement de valeur ajoutée à l’entreprise ? »

Mais ce sera aux architectes de données de traiter ce type de décision ?
C’est exact. Néanmoins, je pense que certaines entreprises ont de véritables architectes de données, autrement dit quelqu’un qui en a le rôle et le titre, et que dans de nombreuses autres situations, le développeur et le DBA assument la fonction pour cette solution particulière. Je crois qu’ils rehausseront tout naturellement leur niveau afin d’apporter plus de valeur à l’entreprise.

Pourquoi SQL Data Services a-t-il été renommé en SQL Services ?
Nous avons utilisé initialement le nom SQL Data Services et nous étions focalisés sur ce premier aspect. Depuis, nous sommes parvenus au nom général SQL Services car ce à quoi nous assistons ici, et nous l’appelons la mission de notre équipe en interne, est une extension de la plate-forme de données au Cloud. Ainsi, nous allons déplacer le reporting vers le Cloud : nous allons effectuer l’analyse, nous aurons peut-être des services de données de référence à notre disposition et il y aussi le SQL Services Labs que nous avons annoncé. Ainsi, si vous allez sur Azure.com, puis sur SQL, vous verrez une liste de projets d’incubation et nous allons montrer notre connecteur de services de reporting qui sera déployé sur SQL Data Services. Au fil du temps, nombre des possibilités qu’il serait pertinent de projeter sur Internet seront englobées par SQL Services. Nous allons avoir quelques nouveaux aspects pour lesquels il n’existe pas d’équivalent aujourd’hui dans SQL Server.

Pour les responsables de l’équipe de développement d’entreprise qui examinent les différentes options, quelles sont certaines des questions qu’ils doivent se poser ?
Je les encouragerais à réfléchir aux nouveaux scénarios. Quelles sont les situations pour lesquelles il est possible d’avoir un point d’extrémité de base de données sur Internet, accessible à tout le monde et autorisant un contrôle des accès ? Quels types de nouveaux scénarios peuvent-ils développer ?

La prise en compte des services Cloud concerne-t-elle des volumes importants de données ?
Pas nécessairement. Il peut s’agir d’un petit volume de données, mais il est important pour moi que ce soit disponible à un emplacement accessible à toutes les personnes disposant d’une connexion Internet. L’autre élément sur lequel nous mettons réellement l’accent est la synchronisation, afin de tout relier ensemble. Si l’accès au Cloud pour effectuer la synchronisation est meilleur marché pour chacune des parties que l’instauration de l’infrastructure en mode point à point, c’est un coup gagnant. Je vois l’évolution de la manière suivante : l’activité B-to-B est pénible à configurer sur les VPN et il est nettement plus facile de se rencontrer à un point de rendezvous accessible aux deux parties. Cette approche est nettement plus facile que d’avoir des périphériques qui ne se connecteront peut-être jamais.

Autrement dit, il n’est pas nécessaire que ce soit une application qui, à mon avis, va évoluer au-delà de mon infrastructure ?
Non. Nous considérons les choses comme des situations comportant des millions de petits éléments que nous souhaitons déplacer et certains éléments qui en eux-mêmes sont extrêmement volumineux.

De quelle manière envisagez-vous l’interfaçage de SQL Services avec Windows Azure et le projet Velocity ?
Velocity est actuellement créé par la même équipe. Une grande partie de l’infrastructure sous-jacente est identique, de sorte qu’ils devraient s’emboîter de manière tout à fait naturelle. En fait, lorsque nous avons démarré Velocity il y a un certain temps, nous savions que la mise en cache serait importante.

SQL Services sera-t-il le référentiel pour nombre de services Azure, peu importe qu’ils soient ou non destinés à être vos applications de base de données traditionnelles ?
Beaucoup de services Azure et .NET auront leur stockage dans SQL Servi – ces. Certains utiliseront le stockage sous-jacent qui fait partie intégrante du système d’exploitation de base. C’est exactement comme à l’heure actuelle : les gens construisent des solutions et ils placent des éléments aux endroits appropriés du système de fichiers et de la base de données.

Merci pour toutes ces précieuses informations.
Si je pouvais insister sur un point, je dirais « regardez, c’est quelque chose de grandiose et je pense que ce sera aussi important que le passage à l’informatique client-serveur. » J’encourage rais les gens à faire un retour en arrière et à dire « Je ne vais pas tant construire la même chose et prendre une décision de la mettre ici ou là. Il s’agit de permettre de nouveaux scénarios et les cinq ou dix prochaines années vont être passionnantes. »