samedi 31 août 2013

Résistance dans les nuages

English: Diagram showing overview of cloud com...
Diagram showing overview of cloud computing including Google, Salesforce, Amazon, Axios Systems, Microsoft, Yahoo & Zoho (Photo credit: Wikipedia)

Résistances au changement rencontrés sur des solutions à base de "cloud computing"

Taxonomie du "cloud computing"

On distingue à ce jour trois principales typologies dans le paradigme "cloud computing" allant de la partie la plus basse d'une architecture (IaaS - Infrastructure as a service) en passant par la notion de plateforme technique (PaaS - Platform as a service) et jusqu'à la partie la plus haute (SaaS - Software as a service). Quelque soit le niveau considéré, j'observe de fortes résistances au changement dans l'adoption de ces nouveaux concepts d'architecture que j'attribue à plusieurs facteurs décrits succinctement ci-dessous.

Confidentialité des données

Parmi les différentes réticences que je rencontre vis-a-vis d'une architecture basée sur du "cloud computing", la question de la confidentialité des données se trouve fréquemment au centre du débat.
Il est bien compréhensible que l'éventualité d'héberger chez un fournisseur externe à l'entreprise les données stratégiques (portefeuille client, documents de toutes sorte - de la présentation en clientèle en passant par les contrats ou les documents juridiques) puisse constituer un sujet de préoccupation majeure des décideurs de l'entreprise auquel les acteurs du "cloud computing" tentent de répondre par différentes certifications toutes plus "ISO" les unes que les autres.

Pour ce qui me concerne, j'observe que de nombreuses entreprises ont hébergé depuis des années leurs données sensibles dans des centres d'hébergement externes sans pour autant s'inquiéter de l'accessibilité à ces données par les équipes de production, par nature externes à l'entreprise cliente.

Dans le cas du modèle SaaS, si la confidentialité s'avère être un pré-requis fort, je suggèrerai alors de traiter ce sujet à l'aide de systèmes de cryptage des données stockées au niveau des applications clientes de manière a assurer l'accès aux informations au seuls utilisateurs ayant les habilitations nécessaires et suffisantes.
Ce modèle peut fonctionner des lors que l'intranet de l'entreprise est à l'origine des données sensibles. Celles-ci sont alors générées, puis cryptées localement puis transmises ensuite a la plateforme "cloud computing".

A l'inverse, à l'extraction des données, celles-ci sont récupérées localement puis décryptées.
On comprend des lors tout l'intérêt d'une solution SaaS proposant une interface de service riche permettant une personnalisation des services d'accès au données et par là-même la mise en oeuvre de cette mécanique de façon transparente pour l'utilisateur.

Dépendance envers le fournisseur

L'utilisation d'un mode "cloud computing" induit par essence une dépendance envers le fournisseur de service.
Cette dépendance n'est en aucun cas un facteur propre au "cloud computing" et à ce titre doit être gouvernée de la même manière que pour tout autre fournisseur de service. En conséquence, celui-ci doit être scrupuleusement sélectionné suivant des critères:
  • Techniques (pertinence de la solution)
  • Économiques (pérennité de l'entreprise)
  • Contractuels (SLA, pénalités, conditions de retrait)
On comprend bien entendu que le troisième point est essentiel dans le cadre d'une architecture utilisant des services "cloud computing", et il convient de prendre en compte dès l'origine l'ensemble du cycle de vie de la solution conçue:
  1. La mise en oeuvre de la solution, en spécifiant les responsabilités de chacun, en particulier en ce qui concerne la qualité de service attendues, qui induira directement le SLA mis en oeuvre dans le cadre de la solution.
  2. Le fonctionnement courant de la solution avec les rapports attendus en regard du SLA établi et les pénalités induites en cas de non respect de la qualité de service contractualisée.
  3. Les conditions de mise en oeuvre du décommissionement de la solution, prenant en compte la reprise des données sous un format utilisable par le client (donc potentiellement plus fonctionnel que technique en terme de normalisation).

Changement d'un modèle "build" en modèle "buy"

Ce troisième point est vraisemblablement l'un des facteurs de résistance majeur que j'ai eu l'occasion de rencontrer.
Face à des équipes constituées incluant des techniciens aguerris ayant produit et maintenu dans le passé des systèmes ayant fait leur preuve, il est délicat de convaincre que la plus-value de ces équipes dans le futur sera mesurée sur la capacité, non plus à construire et à maintenir, mais sélectionner, contractualiser, mesurer et dans une plus large optique gouverner la relation à leur fournisseur.
Pour autant, il ne faut pas y voir à mon sens la mort de la compétence technique mais plutôt sa transformation, celle-ci restant essentielle à l'achèvement des taches cites plus haut.

De la même façon que l'imprimeur n'a pas besoin de connaitre en détail le processus de fabrication du papier pour gérer ses fournisseurs, son métier requiert de lui qu'il connaisse les différents types de papier ainsi que le celui qui convient à son besoin.
La difficulté qui apparait dès lors que l'on essaie de mettre en oeuvre une architecture basée sur des solutions de type "cloud computing" est de pouvoir répondre à des questions du type:
  • Pourquoi acheter chez quelqu'un d'autre ce que l'on peut faire en quelques jours en interne?
  • Pourquoi donner un revenu récurrent à une société externe plutôt que construire une solution interne?
A la première question je répondrai principalement que l'objectif est:
  1. De s'appuyer sur une expérience externe dans des domaines qui ne sont pas le coeur de métier de l'entreprise.
  2. De s'assurer d'une capacité de maintenance et d'évolution des services achetés en dehors des capacités d'investissement de l'entreprise.
A la seconde, qu'il convient de prendre en compte l'ensemble des coûts d'une solution construite en interne, c'est à dire en particulier:
  1. Les coûts de construction;
  2. Les coûts de maintenance;
  3. Les couts d'hébergement;
  4. Les coûts de décommissionnement de la solution.

Conclusion

Je ne sais pas dire à ce jour si le "cloud computing" est la panacée en matière d'architecture de système. J'observe simplement que bon nombre de réticences rencontrées habituellement ne me paraissent pas réellement fondées des lors que l'on accepte les transformations inhérentes à ce modèle.
Pour ma part, j'utilise des services de ce type depuis bien longtemps à titre personnel. Google Doc, Cavus vinifera (pour les oenophiles), Flickr et autres dropbox ne sont finalement que des appendices virtuels de mon ordinateur / réseau personnel.

Related articles

Publié par à
Libellés : , , , ,

Aucun commentaire:

Enregistrer un commentaire

Inscription à : Publier les commentaires (Atom)