En ces temps d'informatique nuageuse ou de nuage informatique selon la perception que l'on peut avoir du phénomène "Cloud Computing", l'hébergement de plateforme prend de plus en plus l'option d'utiliser des plateformes virtuelles mutualisées.
Il apparait donc nécessaire d'être extrêmement prudent lors de la mise en place d'une plateforme mutualisée, et surtout lorsqu'elle inclut la mutualisation d'applications afin d'éviter que les phases de démutualisation ne tournent à la dés-imbrication.
Cette approche présente beaucoup d'avantages parmi lesquels on trouve notamment l'homogénéité des matériels déployés, la souplesse de fonctionnement, la flexibilité d'attribution des ressources au sein de la plateforme, la gestion simplifiée de licences etc.
Il existe toutefois des écueils à éviter ...
Parmi ceux-là on trouve l'imbrication. A l'instar de ce que l'on peut parfois trouver au sein d'une plateforme physique ou virtuelle traditionnelle d'entreprise, il peut arriver que l'on souhaite mutualiser l'utilisation d'un serveur de Bases de Données, d'applications, ou même d'antivirus.La mutualisation présente bien sur les avantages cités plus haut, mais elle doit être pratiquée en conservant un certain niveau de cloisonnement.
Imaginons un Datacenter hébergeant une plateforme mutualisée fournissant à un ensemble de clients, l'accès à en ensemble d'applications de façon centralisée et accessible de n'importe quel connexion internet ( du Cloud quoi ).
L'une des applications mise à disposition est un CRM dont les serveurs de bases de données sont mutualisés. Evidemment l'application permet de sécuriser et de cloisonner l'accès aux données au sein des interfaces personnalisées utilisées par chaque client. Mais il se trouve que d'un point de vue applicatif, certains modèles sont communs, des tables dédiées au sein d'une même base sont accédées par plusieurs clients ...
Que se passe-t-il le jour où l'un des clients souhaite changer d'hébergeur et faire transférer ses données ?
L'hébergeur possède alors trois alternatives :
- Il fournit une copie des bases en l'état au client souhaitant partir ... et fournit donc également l'ensemble des données appartenant aux autres clients utilisant la base ... pas glop.
- Il refuse de fournir une copie des bases en l'état au client souhaitant partir car il a à coeur de protéger la confidentialité des données de chaque client hébergé dans son Datacenter ... pas glop.
- Il va devoir "dés-imbriquer" les données du client souhaitant partir afin de pouvoir lui fournir une base ne contenant que ses données propres. Il devra également valider le bon fonctionnement de la base créée et procéder à une nouvelle recette de l'application dans son ensemble avant transfert vers le Datacenter cible ... pas très glop.
Il apparait donc nécessaire d'être extrêmement prudent lors de la mise en place d'une plateforme mutualisée, et surtout lorsqu'elle inclut la mutualisation d'applications afin d'éviter que les phases de démutualisation ne tournent à la dés-imbrication.
Ingénieur Avant-Ventes chez NEOCLES, ma mission consiste en du conseil en avant-ventes et études d'opportunités de projets de transformation d'infrastructures et/ou poste de travail.