Externalisation Cloud : adapter son approche technologique

L’accent est mis principalement sur le changement du business plan. C’est l’un des problèmes fréquemment rencontré dans les projets d’externalisation dans le Cloud où l’on pointe la consommation à la demande, la flexibilité, l’évolutivité ou encore le paiement à l’usage mais on ne met pas assez en avant le fait que changer la façon dont on « consomme » de l’IT implique forcément de modifier la façon dont on « architecture » celui-ci.

L’approche technologique doit être adaptée si l’on veut retirer tout le bénéfice souhaité d’une migration vers le Cloud. On caractérise le Cloud par des éléments comme l’accès ubiquitaires, le self-service, la multi-tenancy, l’élasticité et la mesure mais pour bénéficier de ces avantages, il faut considérer et envisager les architectures de façon différente.
Prenons le cas d’une DB traditionnelle. Pour en garantir la disponibilité, les ingénieurs système ont l’habitude de s’appuyer sur des mécanismes comme le HA de la couche de virtualisation ou la réplication au niveau du stockage. Une architecture « Cloud » sera pensée de façon radicalement différente, elle privilégiera la multiplication de nœuds identiques, chacun répliquant les données afin de garantir un haut niveau de résilience.

 

Approches Scale Out & Content Delivery

L’élasticité est une composante importante d’un service Cloud. Il faut pouvoir répondre à des variations de charge via une approche Scale Up ou Scale Out. Les deux types de réponse sont possibles dans le Cloud mais le Scale Up est plus adapté aux besoins des applications traditionnelles. Typiquement dans ce dernier cas, on fait appel à un serveur unique. En cas de pic, on lui ajoute des processeurs et de la RAM. Quand la demande baisse, on diminue le nombre de CPU alloués. L’avantage : on ne touche pas à l’application mais en contrepartie, on doit arrêter le service pour ajouter du CPU puis redémarrer le système, d’où des phases de downtime. Avec l’approche Scale Out, on va dupliquer le nombre de serveurs. Si par exemple on fait appel en temps normal à 2 machines, on va en ajouter 2 supplémentaires en cas d’augmentation de la consommation, puis les retirer lorsque la charge diminuera. Le client pourra alors bénéficier de la souplesse du mode technique et des avantages business de consommation à la demande et du paiement à l’utilisation. Le Content Delivery Network est une autre approche typiquement Cloud. Ici, il s’agit de faire en sorte que les requêtes soient géographiquement redirigées vers le point de fourniture le plus proche du consommateur. La chose est très facilement réalisable en mode Cloud et beaucoup moins facile avec une application traditionnelle.

 

Combiner les éléments Cloud Enablers

Cette élasticité doit pouvoir être mesurée pour que l’opérateur Cloud puisse tuner son architecture et que le client puisse avoir un rapport détaillé de sa consommation. En phase élastique, le fournisseur calibre son infrastructure en la partageant entre différentes applications et processus en exploitation dans plusieurs entreprises. Il met en place cet environnement multi-tenancy en déployant un pool de ressources qu’il va allouer de façon dynamique à plusieurs clients en s’arrangeant pour que statistiquement, un client qui a plus de demande soit en phase avec un client qui en a moins. Adapter son approche technologique signifie ainsi combiner et cumuler tous ces éléments Cloud Enablers pour constituer un service Cloud dont on pourra tirer pleinement les bénéfices sur le plan business. Cela passe nécessairement pour les DSI par une analyse de leur couche applicative.

 

Laisser un commentaire

Optimization WordPress Plugins & Solutions by W3 EDGE