La récente mise en place d’une solution en mode SAAS, si elle s’est révélée être un succès, nous a aussi appris un écueil à éviter: partir du principe que le fait de confier à un fournisseur, via le mode SAAS, la gestion de l’infrastructure et du logiciel peut nous dispenser de monitorer par nous-mêmes la solution.

La qualité constatée du monitoring opéré par le fournisseur et le projet impliquant par ailleurs de nombreux intervenants, et nécessitant des intégrations avec d’autres systèmes, la dilution des responsabilités résultante nous a obligé à reprendre en mains, en tant que maître d’œuvre, la construction de la solution de monitoring ainsi que son exploitation.

Nous avions initialement mis en place une solution commerciale indépendante, elle-même en mode SAAS, pour monitorer les urls de base, mais l’expérience nous a montré (si besoin était) que ceci est largement insuffisant. Ainsi, pour donner deux exemples parmi d’autres, un problème sur la base de données et un autre relatif à un tiers n’ont pu être mis en évidence … autrement que par les utilisateurs.

Une solution de monitoring a donc finalement dû être développée et opérée en interne pour être à même de détecter (tous ?) les problèmes potentiels vus du point de vue de l’utilisateur final.

Bref, en synthèse, il s’est agi d’éviter un manque de couverture en termes de monitoring par le fournisseur SAAS, qui aura naturellement tendance à limiter son intervention en la matière au seul bon fonctionnement de sa plate-forme vu du point de vue trop exclusif de l’infrastructure sous-jacente (saturation du processeur, capacité disque, opérations de lecture /écriture…), sans se préoccuper suffisamment de tout l’ensemble des problèmes pouvant affecter l’utilisateur final et du bon fonctionnement avec les applications partenaires.

Notre conclusion: en mode SAAS, il faut redoubler de vigilance non seulement sur la sécurité, mais aussi sur le monitoring, point d’attention sans doute trop peu abordé dans le discours ambiant.

C’est en particulier vrai en cas d’intégration avec d’autres systèmes, sujet particulièrement brûlant en cas de changement de version (la bonne gestion des dépendances est alors un enjeu majeur).

Ce sujet du cloud monitoring nous amène aussi sur tout ce qui touche, dans une vue plus large, à l’importance des activités dites de cloud brokering (ou cloud brokerage).

Le cloud brokering couvre les activités qui vont permettre de faire interagir entre eux différents clouds et d’aider à la gestion de l’ensemble.

Il s’agit, sur un ensemble de solutions IaaS, PaaS et SaaS, distribuées dans des clouds privés ou publics, de mettre en place une solution unifiée permettant, par exemple, des fonctionnalités de :

• Service catalog
• Integration (entre solutions cloud et/ou avec le backend)
• Provisioning
• Security
• Single sign on
• Administration
• Monitoring
• Reporting
• Support
• Billing
• …

Ces activités sont  souvent prises en charge par un fournisseur externe qui s’est spécialisé dans le cloud brokerage – un Cloud Service Broker (CSB).

Vous l’aurez compris, il s’agit ici de porter dans le cloud des activités autrefois confinées intramuros.

Toute organisation ayant compris que :

• les TICs constituent aujourd’hui un levier indispensable à leur développement, sinon même à leur survie ;
• que le cloud peut leur permettre de réduire leurs coûts, se doivent : 
  • soit de développer des compétences dans le domaine du cloud brokering ;
  • soit de s’assurer les services d’un prestataire extérieur soigneusement choisi (pour rappel, un Cloud Service Broker – CSB), eu égard aux enjeux dont il est question ici (seulement mentionner la sécurité devrait suffire à vous convaincre).

Ceci m’amène également à la prévision suivante : il est à craindre que les silos intramuros finissent sur le long terme par trouver leurs équivalents dans le cloud.

Cela me semble d’autant plus vraisemblable que, légitimement, les activités métier voudront exploiter, si la décision est prise d’externaliser, les meilleurs solutions en mode SaaS, la solution 1  étant dans le cloud A et la solution 2 dans le cloud B. Le cloud A pouvant être privé parce que la solution 1 aura peut-être fait l’objet d’une acquisition par voie de licence alors que la solution B reste louée.

Un conseil à partir de cette dernière remarque : prévoyer dans vos futurs cahiers des charges, chaque fois que possible, les deux modes d’acquisition location (SaaS) et acquisition (licence) . C’est en particulier vrai lorsque le nombre d’utilisateurs croît dans le temps. Au-delà d’un certain seuil il peut devenir plus intéressant de basculer vers le mode acquisition. A ce moment vous pourrez déplacer l’application vers votre cloud privé.

Ce risque sur les silos dans le cloud est une raison supplémentaire de s’intéresser aux solutions de cloud brokering, en vue d’éviter les îlots fonctionnels du passé, les sous optimisations globales résultantes au niveau du métier , et les coûts de maintenance et d’exploitation extravagants au niveau de l’IT.

Indiscutablement, les enterprise architects doivent investir sur ce sujet.