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 Clement Escoffier au sujet de sa session intitulée "Subatomic, Supersonic, Reactive".
Bonjour Clément, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?
Dans le passé, je faisais beaucoup de développement OSGi. OSGi apportait deux excellentes caractéristiques : la modularité et le dynamisme. Chaque partie du système a été développée en tant que groupe de bundles regroupant des services évoluant indépendamment au moment de l’exécution. Cependant, il n'y avait rien de gratuit, ces deux caractéristiques ne venaient pas sans coût, et il était souvent nécessaire de comprendre le mécanisme de chargement des classes de chaque bibliothèque, être sûr de ne pas avoir de conflits de dépendances … Donc, sans une discipline spartiate, cela peut dérailler rapidement.
À cette époque, l’utilisation de systèmes distribués pour obtenir la modularité, le dynamisme et l'indépendance était trop coûteux. Même avoir plusieurs JVM sur le même hôte était considéré comme coûteux.
Le temps a passé. Les appareils sont devenus plus puissants. L'infrastructure cloud privé et publique facilitait l'obtention de nouvelles machines. Ce qui était considéré comme trop cher est devenu abordable. Nous y voilà donc, pour obtenir la modularité, le dynamisme et l'indépendance, nous avons échangé la complexité d'OSGi contre… des systèmes distribués.
C'est comme ça que je suis arrivé aux microservices. La vue de 10 000 pieds ressemble à un paradis. Chaque partie du système est maintenant développée en tant que processus complètement indépendant, exposé au reste du système à l'aide d'un protocole léger. Chaque partie peut évoluer à son rythme.
Cependant, si l'on y regarde de plus près, les choses s’assombrissent. C'est pourquoi les microservices m'intéressent, car si cela fonctionnait bien, ce ne serait plus amusant.
De quoi parles-tu à Voxxed Days Microservices ?
Je parle de réactif et d’où il vient. Cela provient des parties les plus sombres des systèmes de microservices et des systèmes distribués, des marchés de dupes qui ont été conclues pour simplifier le fonctionnement des choses. La session explique pourquoi le blocage et la communication synchrone sont une mauvaise habitude pour les microservices et comment, en adoptant le transfert de messages asynchrone, vous pouvez construire de meilleurs systèmes. Mais ne nous arrêtons pas là, la session le montre également. Quarkus et Apache Kafka montrent comment vous pouvez construire un système élastique, résilient et réactif sans effort.
Il y a quelques années, les Microservices étaient simplement synchrones avec la découverte de service et les circuit breakers. Aujourd'hui, il semble que la nouvelle approche réside dans les microservices réactifs. Comment vois-tu ces deux modèles évoluer ?
Les microservices sont, par nature, des systèmes distribués. Pendant des années, les développeurs ont construit des monolithes où tout fonctionnait dans le même processus. Il semblait donc correct d’appliquer les mêmes modèles dans les microservices. Sauf que… ça nous mène à un monde de cauchemars.
Les systèmes distribués sont très différents d'un monolithe et les patterns que nous utilisions avec succès dans un monolithe peuvent être nocifs dans un système distribué. L'erreur la plus commune repose sur la communication synchrone, généralement basée sur HTTP. L'utilisation d'I/O bloquant ne limite pas seulement la simultanéité du microservice, il rend également le système globalement plus fragile. Bien sûr, vous pouvez essayer d’utiliser des correctifs, mais ce sont des solutions à court terme. Heureusement, il existe des solutions, et non des nouvelles, qui existent depuis 25 ans qui se sont révélées très efficaces avec des microservices tels que les technologies de messaging.
HTTP ne va pas disparaître de si tôt, et il est pratique pour interagir avec systèmes différents. Cependant, à l'intérieur de votre système, cela peut devenir un goulot d'étranglement important.
Dans peu de temps, nous allons voir de nombreuses améliorations dans les domaines du messaging et des communications à distance. L'utilisation de protocoles binaires (comme protobuf), la généralisation de protocoles non bloquants, HTTP / 3 vont à nouveau changer la face des microservices. Alors non, on ne va pas s'ennuyer pendant un moment …
…
Bon, à bientôt alors
Twitter : @clementplop
LinkedIn : https://www.linkedin.com/in/clementescoffier
GitHub : https://github.com/cescoffier