Cet article s’insère dans la série “microservices” écrite par François Berthault dans le cadre de la participation de Talan Labs à Devoxx 2017, du 5 au 7 avril prochains au Palais des Congrès de Paris.
Dans la littérature, les microservices sont représentés la plupart du temps par de petits hexagones. C’est une référence à un modèle d’architecture appelé architecture hexagonale, introduit par Alistair Cockburn pendant les années 2000.
Alistair Cockburn définit ce modèle aujourd’hui appelé Ports & Adapters comme suit :
“[The Ports & Adapters pattern] a_llows an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases._”
Hexagonal Architecture and Microservices © Geeks With Blogs
Attention cependant, il se pourrait que vous arriviez à une solution qui ressemble à ceci :
Attention à la complexité ! © Ploeh Blog
Dans les architectures microservices, la tolérance aux pannes est un pré-requis et non une singularité. La conséquence directe d’utiliser des services comme composants est que l’application doit être pensée pour accepter les appels de service pouvant échouer.
Les problèmes sont classiques :
Mais une erreur dans un service ne doit pas impacter l’expérience utilisateur. Les applications doivent automatiquement prendre des actions correctives quand une de leurs dépendances est défaillante. C’est ce que l’on appelle la résilience.
Un service en échec ne doit en aucun cas dégrader les services le consommant. Compte tenu de ce besoin architectural, les solutions à utiliser sont des combinaisons de :
Le but ici est d’échouer rapidement afin de garantir la santé du reste de votre application. Une erreur n’est jamais plaisante en termes d’expérience utilisateur mais permettre à son système de se rétablir par lui-même rapidement est une option non négligeable.
Netflix Hystrix est certainement la librairie la plus célèbre pour la gestion de latence et de tolérance aux pannes. Elle a été conçue par Netflix en 2011 pour isoler les points d’accès à un système distant, un service ou à une librairie tierce.
En conclusion, le modèle en microservices doit donc faire évoluer le point de vue des développeurs dans la création des applications. Au-delà, c’est aussi l’organisation des projets qui s’en trouve profondément modifiée. C’est le sujet abordé dans le volet numéro 3 de cette série [lien du billet n°3].
Vous avez aimé cet article ? Découvrez ou redécouvrez les autres épisodes de la série « Les microservices pour une architecture orientée web » :
Partie 1 Les microservices pour une architecture orientée web n°1 : Définitions et caractéristiques
