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 Grace Jansen au sujet de sa session intitulée "Reacting to the future of application architecture".
Bonjour Grace, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?
Bonjour, je m'appelle Grace Jansen et je suis Developer Advocate et Senior Inventor chez IBM. Diplômé il y a quelques années, j'ai rejoint l'industrie du logiciel au plus fort des organisations qui migraient leurs applications monolithiques vers des microservices.
En tant que diplômé en biologie, au niveau conceptuel, les microservices ont beaucoup de sens pour moi. Ayant étudié des organismes vivant dans des sociétés / communautés, je pouvais voir les similitudes et les avantages de la décomposition de ces immenses applications en plus petites morceaux.
Cependant, après un examen plus minutieux de la manière dont les microservices sont mis en œuvre, il est rapidement apparu que, dans la pratique, de nombreux problèmes ne sont toujours pas résolus par les microservices. Mais…. C'est précisément ce qui rend le travail dans ce domaine si amusant et intéressant et me motive à venir travailler. Comment pouvons-nous résoudre ces problèmes ? Comment pouvons-nous faire évoluer et développer davantage l'architecture des applications microservices et rendre nos applications encore plus résilientes et réactives ?
De quoi parles-tu à Voxxed Days Microservices ?
Les microservices ont souvent du mal à gérer les charges variables du système, les défaillances inattendues et l'élasticité de l'allocation des ressources. Dans mon exposé, nous verrons comment l'architecture applicative Reactive peut s'appuyer sur l'architecture microservice pour aider à résoudre ces problèmes et, par conséquent, pourquoi le Reactive représente l'avenir de l'architecture d'application.
Cependant, l'architecture applicative peut être un concept assez abstrait et est souvent difficile à visualiser. Pour aborder ce sujet, j'utilise un thème inhabituel dans mes talks… J'utilise des sociétés d'abeilles et des comportements pour aider à créer des analogies comparables avec l'architecture réactive, des comportements qui permet aux applications de mieux expliquer pourquoi vous voulez que votre application soit réactive.
Les systèmes réactifs sont complexes à gérer, mais si l'on examine tous les frameworks (akka, RxJava, Vert.x, etc.), il semble qu'ils se répandent partout. Une architecture Microservice doit-elle être entièrement réactive ou seulement dans certains cas?
La réponse simple est, de préférence oui, une architecture de microservice serait idéalement entièrement réactive.
Les systèmes réactifs sont définis à travers les principes fondamentaux du manifeste Reactive. Ces principes sont la réactivité, la résilience, l'élasticité et le message-driven. Pour qu'une application soit vraiment réactive et capable de gérer des charges et des défaillances variées, chaque section d'une application doit permettre de respecter ces principes. Certains des frameworks énumérés ci-dessus (par exemple, RxJava) permettent la mise en œuvre d'outils réactifs, tels que la programmation réactive, mais pas une solution de bout en bout entièrement réactive. Comme l'explique Jonas Bonér, bien que des outils tels que la programmation réactive soient d'excellentes techniques pour gérer les exécutions asynchrones et non bloquantes de la logique interne et de la transformation de flux de données, cela ne permet pas à l'application d'être résiliente à la défaillance ou élastique dans sa réponse aux changements de charge. Le couplage faible entre les étapes de traitements dans les applications qui mettent en œuvre la programmation réactive de manière isolée signifie qu'elles gèrent généralement le succès ou l'échec directement sans le signaler au monde extérieur. Ce manque d'adressabilité rend la récupération d'étapes individuelles plus difficile à réaliser car il est généralement difficile de savoir où les exceptions doivent être propagées. En outre, le manque de transparence de l'emplacement lorsque vous utilisez uniquement la programmation réactive pour l'isolation, rend difficile la mise à l'échelle d'un programme uniquement basé sur les techniques de programmation réactive de manière élastique et nécessite donc la superposition d'outils supplémentaires tels qu'un bus de message, Data Grid ou de protocoles réseau adaptés.
Cependant, lorsque la programmation réactive est utilisée avec d'autres outils tels que des circuit breakers, des bulkheads, etc., au niveau du système, l'application devient ainsi un système réactif complet. Cela permet à l'application de devenir élastique, résiliente et réactive non seulement lorsque les choses fonctionnent comme prévu, mais également en cas de défaillance et sous une charge imprévisible.
Bon, à bientôt alors
Mes coordonnées
Twitter : @gracejansen27
LinkedIn : https://www.linkedin.com/in/grace-jansen/