Voxxed Microservices : Nicolas Frankel, "Battle of the Circuit Breakers Istio/Hystrix/Resilience4"

Voxxed Days Microservices est un événement centré exclusivement sur les Microservices. Durant cette seconde édition, deux jours de conférences et un jour d’atelier (en option) auront lieu à Paris du 21 au 23 octobre 2019.

Les lecteurs d'InfoQ peuvent profiter d'une promo de 20% avec le code VXDMS19_COM_INFOQFR lors de l'inscription.

InfoQ s'est entretenu avec Nicolas Frankel au sujet de sa session intitulée "Battle of the circuit breakers istio vs hystrix/resilience4j".

Bonjour Nicolas, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?

Bonjour. J'ai été développeur/architecte pendant la majeure partie de ma vie professionnelle, principalement dans l'écosystème Java/Spring. Même à cette époque, je m'intéressais à l'autre côté: exploitation, monitoring, etc., ce qui s'appellerait aujourd'hui DevOps. L'année dernière, j'ai orienté ma carrière dans une autre direction et suis devenu Developer Advocate.

Je travaille pour une entreprise nommée Exoscale . Nous sommes un fournisseur Cloud européen, offrant des ressources de type Infrastructure-as-a-Service. Il est indéniable que l'hébergement dans le Cloud gagne du terrain, et l'architecture de microservices est particulièrement bien adaptée à l'hébergement dans le cloud. Par conséquent, en utilisant mon expérience de développeur, j'ai beaucoup travaillé sur l'intégration de différents thèmes qui font sens ensemble : gestion de la configuration, résilience entre services, journalisation, monitoring, etc.

De quoi parles-tu à Voxxed Days Microservices ?

Mon talk porte sur la résilience : quand on passe d'un appel d'API standard à un appel de service, on peut facilement croire aux idées fausses de l'informatique distribuée. La principale de ces icées est «le réseau est fiable». Par conséquent, pour une raison quelconque, le service requis pourrait être indisponible. Heureusement, il y a le timeout ; Malheureusement, si l'appelant doit attendre le timeout, il est probable qu'il sera inondé de requêtes et ne sera pas disponible lui-même.

Dans ce type d'architecture, une défaillance peut rapidement se propager partout et mettre tout le système en panne. Pour cette raison, des personnes intelligentes ont proposé le modèle Circuit Breaker. Tout comme un disjoncteur domestique protège le système électrique des surtensions, le motif protège l'architecture. Cependant, il faut faire attention car "Circuit Breaker" est un terme assez général. Les bibliothèques l'implémentent, les réseaux de services l'implémentent. Ils ne sont pas interchangeables !

L'architecture microservices utilise de plus en plus les messages asynchrones et le streaming. Par conséquent, l'utilisation des circuit breakers ont tendance à diminuer. Vois-tu une tendance ici, qu'en est-il de l'avenir du modèle circuit breaker ?

Mon opinion personnelle est qu'il faut être très prudent face aux tendances. La plupart des entreprises utilisent des microservices. Pire encore, la plupart des entreprises sont même difficilement aptes à les utiliser. J'adore cette image du blog de Martin Fowler :

Les microservices offrent de nombreux avantages, mais ont également des exigences très strictes. La plupart des gens ne voient que les avantages et oublient commodément les exigences … jusqu'à ce qu'ils viennent appuyer là où ça fait mal. De même, l'asynchronicité complique la tâche de raisonner sur le code et augmente de manière non négligeable la charge de travail dans deux domaines liés au développement de logiciels : le débogage et les tests.

Je suis moi-même un grand partisan de l'amélioration continue et je crois qu'essayer de mettre en œuvre des microservices asynchrones dès le premier jour est une recette sûre pour aboutir à un désastre. Rappelez-vous que Twitter a commencé avec Ruby on Rails. Cette approche pragmatique et sensée devrait être la voie à suivre pour toutes les entreprises qui souhaitent réussir. Commencez par un monolithe, puis, si nécessaire, migrez vers des macro-services, puis affinez-les (si nécessaire) en microservices, puis introduisez l'asynchronicité là où cela a du sens, etc.

Bon, à bientôt alors

Twitter : https://twitter.com/nicolas_frankel

Blog : https://blog.frankel.ch/

GitHub : https://github.com/nfrankel