Industrie Mag - Le journal de l'industrie.

Toutes les 11 secondes, Amazon déploie une nouvelle mise à jour de son site d’E-commerce. Une coupure, même très courte, provoquée par ces mises en production, serait très pénalisante pour ce géant du web qui a tout misé sur l’extrême rapidité du cycle d’achat de ses clients.

Pour proposer un service sans discontinuité, tout en mettant à jour les composants qui le constituent, Amazon utilise une architecture distribuée : les services sont éclatés, répartis sur un ensemble de serveurs et découplés les uns des autres. Les composants se retrouvent ainsi isolés, et le crash ou la mise à jour de l’un d’entre eux n’a d’impact que sur lui-même.

Grâce à cette architecture distribuée, Amazon peut se permettre des mises à jour fréquentes et proposer rapidement de nouvelles fonctionnalités. D’autres acteurs, comme Netflix, ont aussi opté pour ce type d’architecture. Netflix n’hésite d’ailleurs pas à mettre à rude épreuve ses services, en simulant constamment des pannes, allant jusqu’à arrêter ses services sur un continent complet. Tout ceci dans une transparence totale pour l’utilisateur grâce à une distribution des applicatifs et des données dans le monde entier.

Un peu d’histoire

Cette notion de distribution de services n’est pourtant pas nouvelle. Java EE proposait des composants distribuables (EJB pour Entreprise Java Beans) dès les années 2000, tout comme la spécification SOAP (Simple Object Access Protocol) qui, à la même époque, permettait de décrire un protocole de communication entre systèmes hétérogènes, pour faciliter le dialogue entre eux (ces systèmes pouvant être distants et reposer sur des technologies différentes).

Mais on est encore loin du concept de distribution massive des services, qui n’est apparue que très récemment.. Il y a quinze ans en effet, l’utilisation des systèmes informatiques était beaucoup moins omniprésente et la pression exercée sur eux, moins forte.

Internet n’était pas disponible partout, tout le temps, pour tout le monde, et la technologie elle-même n’était pas adaptée à la distribution des services. Aujourd’hui, de nouveaux paradigmes ont émergé qui eux, sont idéaux pour une utilisation de services distribués.

Reste qu’aucune des technologies de l’époque n’est aujourd’hui un critère de choix pour concevoir ce type d’architecture. Leurs premières utilisations restent axées sur une communication synchrone, une gestion des erreurs complexes et occasionnent des coûts d’utilisation supplémentaires. Développer une application distribuée en se basant sur ces technologies, est contraignant, compliqué et plus couteux.

No Pain No Gain : Changement de paradigme

Mettre en place une architecture distribuée, c’est avant tout savoir faire des compromis. Vous vous connectez à un service distant qui doit toujours être disponible ? Un message ne doit être consommé qu’une seule et unique fois ? Votre service doit répondre dans un temps constant ? Il faut avoir conscience que dans un contexte distribué, c’est impossible. Vous dire le contraire serait vous mentir. Les services peuvent tomber, les messages se perdre ou votre service dépendre d’autres services subissant des lenteurs contre lesquelles vous ne pourrez rien faire.

Des solutions néanmoins existent : il faut accepter qu’un service ne soit plus disponible et y pallier par des temporisations ou des coupes circuits. La duplication de messages peut être gérée avec de l’idempotence et il est possible d’isoler vos services, en rendant vos appels asynchrones.

La mise en œuvre de ces concepts n’est pas triviale. Il faut revoir les modes de communication, la structures des messages et gérer de nouveaux cas d’erreurs. Ces notions sont complexes à saisir, tout comme les changements qu’elles imposent. Il sera donc nécessaire de réaliser des prototypes pour le découvrir par soi-même ou se faire accompagner pour gagner un temps précieux.

Une architecture distribuée, c’est aussi de nouveaux services qui vont communiquer entre eux. Comment s’assurer de la compatibilité des APIs entre elles ? Comment réaliser la mise en production régulière, non plus d’un, mais d’une multitude de services ?

Votre outil de supervision est-il adapté à cette nouvelle distribution applicative ? Si ces problématiques ne sont pas nouvelles, leur mise à l’échelle peut, elle, se révéler problématique.

Impact Business des architectures distribuées :

L’investissement peut sembler important, mais le gain l’est tout autant. Votre dépendance technique se réduira puisque vous pourrez mélanger des services utilisant des technologies hétérogènes. Vous ne serez plus contraint à utiliser la technologie historique qui est trop souvent le choix par défaut, car votre prochain service pourra faire des arbitrages techniques correspondant mieux à un contexte précis. Sa mise à disposition s’effectuera plus vite, avec un coût réduit et sa maintenance simplifiée n’aura aucun impact sur les briques existantes.

Une architecture distribuée garantit par ailleurs la qualité et la disponibilité des services : si l’une de vos dépendances tombe, votre service lui, isolé de cette dépendance, continuera à répondre. Cette réponse se fera en mode dégradé certes, mais sera toujours plus pertinente qu’aucune réponse. Vous gagnerez également en performance puisque vous pourrez profiter du temps d’attente de vos appels asynchrones pour traiter plus de données.

Avoir des applicatifs distribués, isolés entre eux et résilients, c’est la possibilité de changer à tout moment de composants sans impacter directement vos utilisateurs. Plus besoin de réserver un créneau, à l’heure où la fréquentation sur votre site est la plus faible, pour mettre en production. Le temps de mise à disposition de nouvelles fonctionnalités s’en trouve drastiquement réduit, une fois validées, elles sont effectives et opérationnelles.

Pour finir sur une métaphore qui parlera à tous ; passer à une architecture distribuée, c’est se donner les moyens de changer les roues de sa F1 tout en continuant à rouler, quand les autres écuries s’efforcent de diminuer leurs temps au pit-stop.

http://www.soat.fr/