Article #5 – Quelques éléments de conclusion

Après avoir fait le tour de tous les composants de notre architecture orientée microservices, c’est le moment de mettre les choses au point et de faire le bilan sur ce que cette architecture peut nous apporter. Maintenant que nous avons présenté chaque composant un par un, nous allons pouvoir discuter de ce qu’ils peuvent nous apporter par leur combinaison, et s’ils répondent bien au principe même de microservice.

Rappel : Cet article s’inscrit dans une série d’articles formant un retour d’expérience sur la création d’une architecture orientée microservices.

• Article #1 – Contexte et définition de l’application
• Article #2 – Eureka, registre de services au coeur de l’architecture
• Article #3 – Zuul, gatekeeper et filter loader depuis Cassandra
• Article #4 – Hystrix, son dashboard et la stack ELK
• Article #5 – Quelques éléments de conclusion

Mise au point

Si l’on devait refaire la liste des composants présents dans notre architecture, elle ressemblerait à cela :

• Eureka : registre de services
• Zuul : point d’entrée et « filter loader »
• Cassandra : Base de données NoSQL
• Hystrix : Gestion des échecs et tableau de bord
• Elasticsearch : Moteur de recherche
• Logstash : Collecteur et transmetteur de logs
• Kibana : Visualiseur de données

Chacun de ces composants permet à nos services Product, Pricing et Details de communiquer entre eux dans un environnement encadré, régit et contrôlé par ces outils OpenSource. En soit, ces composants ne sont pas des services mais des applications qui permettent la vie de services qui concentrent la partie métier de l’application. C’est en les combinant que l’on obtient notre architecture. Afin de pouvoir la mettre en place, il va falloir lancer toutes ces applications afin qu’elles puissent se reconnaître entre elles et se préparer à recevoir les premières requêtes, et les traiter.

Maintenant que nous avons mis les choses aux points, nous allons pouvoir conclure cette série d’articles sur des éléments supplémentaires qui encensent cette architecture et dégagent ses limites.

Concepts autour de l’architecture

Diviser pour mieux régner

Avant tout, il faut savoir qu’il existe plusieurs stratégies de déploiement. Netflix, en étroit partenariat avec Amazon Web Services, a décidé d’organiser son architecture autour de « régions » définies par AWS. De cette façon, l’architecture est répliquée dans plusieurs zones différentes d’un pays ou continent. Il s’agit là, peut-être, de la méthode la plus « scalable » pour pouvoir répartir l’emprise de Netflix dans le monde, d’une part, et surtout répartir la charge parmi les différents endroits de la planète. Cette méthode permet ainsi, notamment aux USA, d’éviter des temps de latence importants entre, par exemple, une personne habitant à Seattle, au nord-ouest, et une autre personne habitant à Miami, au sud-est. Aussi, cette stratégie permet d’éviter de faire tomber les services de Netflix dans un pays ou continent en entier. Les espaces sont ainsi découpés en plusieurs sous-espaces, ayant chacun leur propre architecture, et par conséquent, leur propre quantité d’opérations. Dans le cas de notre application, nous n’avons pas choisi de suivre cet exemple, ne s’agissant ici que d’un POC.

L’enjeu de la scalabilité

L’objectif premier d’une telle architecture est de rendre une application apte à pouvoir s’étendre à grande échelle. Répartir cette application sur plusieurs zones géographiques dans le Cloud amplifie ce phénomène, et devient une nouvelle dimension à prendre en compte, s’agissant de microservices et de haute scalabilité. En effet, cette répartition permet, par exemple, d’assurer un service de secours, si jamais la zone dans laquelle vous vous trouvez tombe en panne. Il suffira aux techniciens de l’application de faire router les requêtes vers la zone la plus proche.

En 2012, Netflix a essuyé une panne importante aux Etats-Unis, privant ses utilisateurs de son service pendant plus de douze heures. A cette époque, il n’y avait qu’une seule zone de définie dans le pays, à l’est. Depuis cet incident, Netflix a rajouté une zone aux Etats-Unis, cette fois-ci à l’ouest, et dans l’optique de permettre de faire perdurer leurs services si une panne venait affecter l’une ou l’autre zone. Cet article expose plusieurs éléments au sujet de cette infrastructure de régions chez Netflix. Cet exemple amplifie l’importance de la scalabilité pour ce genre d’application.

Identification du besoin

Cependant, d’autres applications ne répondent pas à ce genre de besoin, et ne nécessitent pas une telle architecture, relativement complexe à mettre en place, pour leurs services. Ce genre d’architecture est assez nouveau dans le monde de l’informatique et, à part plusieurs outils OpenSource et quelques indications permettant de les mettre en place de façon simpliste, il existe peu d’informations sur lesquelles se baser pour construire votre application. Aussi, il n’y a pas forcément d’outils de référence sur lesquels s’appuyer de façon obligatoire : Netflix propose une quantité importante d’outils éprouvés par eux-même, mais ils ont été créés afin de répondre à leurs besoins particuliers. De ce fait, si vous décidez de les utiliser, il faudra s’attendre à devoir se conformer à certains fonctionnements ou à étendre certaines fonctionnalités. Faire usage de Cassandra pour pouvoir profiter de la capacité de Zuul à charger des filtres dans votre application de façon dynamique est un exemple.

C’est en fonction du besoin et du public autour de l’application qu’il convient de bien choisir son architecture. Certains services, ayant historiquement une architecture sous la forme d’un monolithe, n’ont eu d’autre choix que de passer à une architecture orientée microservices : Amazon, Riot Games, SoundCloud, Cloud Foundry, etc. Ces applications ont vu leur importance sur le marché devenir très importante, rendant une panne de service, ne serait-ce que de quelques minutes, très coûteuse. L’obligation de qualité de service devient donc un enjeu du côté du business de ces entreprises, et la scalabilité, une opportunité d’étendre leurs marchés et d’ouvrir la porte à plus de position dans leurs domaines respectifs. Et c’est en mettant en exergue ce besoin qu’ils ont transformé leur architecture pour y intégrer des microservices, favorisant la capacité à monter en charge.

Pour conclure…

La séparation des services en fonction de « régions », les enjeux importants autour de la scalabilité des applications, et l’identification d’un tel besoin sont autant de concepts importants qui tournent autour de cette architecture orientée microservices. Mettre en place cette architecture ne suffit pas (forcément) à rendre une application plus performante d’un coup d’un seul. C’est pourquoi il est important, tout d’abord, de savoir quel type de public sera atteint, et son nombre approximatif. Cette architecture peut ne pas convenir à certaines applications pour plusieurs raisons comme la complexité de sa mise en place, par exemple. Cependant, ce type d’architecture, par essence, est ouvert à une importante scalabilité, mais aussi, et surtout, à une haute disponibilité des services.

Cependant, il convient de rappeler à notre audience qu’il ne s’agit pas là d’une solution magique à tous les maux. L’architecture ici présentée est composée d’outils adaptés et maitrisés par Netflix, qui ont fait leur preuve dans le domaine spécifique qui est celui de la vidéo à la demande à grande échelle. Bien sûr, il peut être répliqué à souhait pour des besoins similaires (site d’e-commerce, banques, etc.), et vous n’êtes pas obligés d’utiliser tous les outils ici présentés pour mener à bien votre tâche.

Il faut aussi savoir qu’il est difficile, donc coûteux, de mettre en place une telle architecture, ne serait-ce que par la documentation sur le sujet étant assez pauvre, et l’absence de solutions annexes à celles proposées par Netflix. En effet, mis à part quelques indications sur une mise en place rapide et simple de certains outils de la stack Netflix OSS, il existe peu, voire aucun exemple réel d’utilisation de ces applications, rendant ainsi leur apprentissage plus compliqué, et rendant les développements plus longs, donc plus coûteux. Certains diront certainement que ces outils ont une vocation à s’appliquer à des cas originaux, et que toute la configuration est spécifique aux infrastructures, à la taille de l’application, etc. A ce titre, nous pouvons vous donner un exemple concret : la récupération des filtres depuis Cassandra, en utilisant Zuul, a été mise en place dans les premières version de Zuul par Netflix, puis supprimée, avec la documentation qui allait avec. Et ce fut à base de lecture du code source de Zuul, et à coups de tests que nous avons pu mettre en place cette fonctionnalité. Cet exemple s’inscrit parmi d’autres, comme l’utilisation d’objets HystrixCommand avec Hystrix (dont nous avons parlé dans l’article n°4), alors que la documentation de Netflix préconisait une autre façon de faire.

Mais que serait une nouvelle technologie sans sa propre dose de challenge ? Car malgré une documentation technique plutôt pauvre, et une mise en place assez compliquée, cette nouvelle façon de dessiner une application est assez novatrice dans son domaine. Certaines entreprises commencent à les utiliser, mais dans un certain degré de confidentialité. Peu d’informations transpirent de leurs utilisations dans d’autres domaines comme le commerce électronique par exemple (hello Amazon !), et il n’existe pas à ce jour de retour d’expérience sur le sujet, dans un contexte à taille réelle. Ce qui est compréhensible, car cette taille réelle représente ici une application à grande échelle que seuls les géants du commerce peuvent prétendre utiliser. Ayant, pour la plupart, fait évoluer leur ancienne architecture ayant atteint une certaine limite, en termes de scalabilité notamment, ils sont les seuls organismes à pouvoir faire des retours d’expérience précis sur leur utilisation, leur mise en place, et leur entretien. Aucune de ces entreprises n’a envie de révéler leur recette magique pour une qualité de service robuste, scalable, résilient et à capacité d’évolution très importante. C’est pourquoi, en attendant (peut-être) un retour d’expérience d’une entreprise digne de ce nom, cette série d’articles vous propose d’utiliser les solutions créées par Netflix et la stack Netflix OSS.

Enfin, ce type d’architecture est amené à évoluer dans le temps, avec certainement de nouvelles applications qui viendront garnir les premières, notamment celles développées par Netflix, mais il y a fort à parier que d’autres améliorations seront apportées sur les infrastructures autour de ce type d’architecture : après le découpage en zones, quelles autres évolutions permettront d’asseoir encore plus l’emprise des microservices ?