Cloud Computing @ Microsoft France

Le système d'informationset les nuages

Persister dans les nuages pour les éditeurs de logiciels

Persister dans les nuages pour les éditeurs de logiciels

  • Comments 1

Voici une série de billets qui expliquent comment intégrer une couche de persistance dans les nuages (SQL Server Data Services) à une application multi-tenant. L'architecture présentée est illustrée au travers de l'application de référence LitWareHR.

Eugenio présente son retour d'expérience en terme d'architecture, d'implémentation, gestion de cache, gestion du mode déconnecté pour des besoins de tests...

Nothing valuable is free, isn't it? SSDS gives you unlimited storage, tremendous flexibility, geo-aware location. You don't have to worry about backups, operations, disk failures, power, air conditioning, machines, etc. You just use it.

But all this goodness comes at a cost: you don't "own" the database any more, you can't assume the database is "close" to you (too chatty interactions with it, will lead into latency issues) and the programming model you were used to is different: there are no tables, stored procedures, views, joins, etc.

You will have to decide whether these cons, out-weight the benefits in your particular scenario, and hopefully some of the lessons learnt in Litware, although impossible to extrapolate to every scenario, will help you make that decision.

Principes d'une couche de persistance multi-tenant

Pour rappel, une couche de persistance multi-tenant doit être extensible pour permettre de créer des spécialisations sur mesure pour tel ou tel client. D'un point de vue technique, il s'agit d'apporter la capacité à son framework de persistance d'ajouter des attributs à des entités pour certains scénarios. Il est donc nécessaire de stocker 3 niveaux de données pour chaque type :

  • les données communes à tous les types (ID, Version, Type voir des propriétés génériques tels qu'un nom court, un nom long, une description)
  • les données racines au type (Adresse, Téléphone, Age par exemple dans le cas d'un type Personne)
  • les données étendues du type, spécialisée par scénario (Numéro de sécurité sociale si l'application traite doit traiter un dossier patient par exemple)

Au niveau technologique, il est possible d'implémenter cette extensibilité au travers de 3 patterns : types XML, colonnes pré-définies ou encore via des tables d'extension. Ce document analyse ce choix en terme de performances.