Même si l'IA est privilégiée, il faut toujours partir de la stratégie et des problèmes à résoudre, prévient la HBR, dont l'approche 3P fait écho au Tech, Orga, Culture de WEnvision.
"The Software Architect Elevator" est une de feuille de route pour les architectes. En embrassant le changement, en comprenant les systèmes organisationnels et en favorisant une communication efficace, les architectes peuvent jouer un rôle central en conduisant les organisations vers le succès.
L'IA générative était (surprise !) la vedette du keynote de l'AWS Summit Paris, ce 3 avril au Palais des Congrès. C'est LE sujet qui tire le Cloud et la Data.
La programmation réactive est idéale pour gérer la logique interne et la transformation du flux de données, mais les systèmes réactifs sont la clé de la résilience et de l'élasticité des systèmes distribués.
< Les 3 avantages d'une architecture orientée événements pour une plateforme IT
Vous êtes-vous déjà demandés en quoi la programmation réactive et les systèmes réactifs diffèrent ?
L'un des problèmes courants liés à l'utilisation exclusive de la programmation réactive est que son couplage étroit entre les étapes de calcul, dans un programme déclaratif ou basé sur des callbacks événementiels, rend la résilience plus difficile à atteindre. En effet, ces chaînes de transformation sont souvent éphémères et les étapes - callbacks ou combinateurs - sont anonymes, c'est-à-dire non adressables. Cela signifie que les systèmes traitent généralement le succès ou l'échec directement sans le signaler au monde extérieur. Par conséquent, les échecs sont liés aux demandes des clients éphémères plutôt qu'à la santé globale du composant, ce qui n'est pas idéal.
Un autre contraste avec l'approche des systèmes réactifs est que la programmation réactive pure permet le découplage dans le temps, mais pas dans l'espace (à moins de tirer parti du passage de messages pour distribuer le graphe de flux de données à travers le réseau, comme discuté précédemment). Comme nous l'avons mentionné, le découplage dans le temps permet la concurrence, mais c'est le découplage dans l'espace qui permet la distribution et la mobilité - permettant des topologies non seulement statiques mais aussi dynamiques - ce qui est essentiel pour l'élasticité.
En raison du manque de transparence de l'emplacement, il est difficile de faire évoluer un programme purement basé sur des techniques de programmation réactive de manière adaptative et élastique ; ce qui implique la mise en place d'outils supplémentaires, tels qu'un bus de messages, une grille de données ou des protocoles de réseau sur mesure. C'est là qu'intervient la programmation par messages des systèmes réactifs, puisqu'il s'agit d'une abstraction de communication qui conserve son modèle de programmation et sa sémantique dans toutes les dimensions de l'échelle, et qui réduit donc la complexité du système et les frais généraux cognitifs.
Un problème communément cité de la programmation basée sur les callbacks est que, bien que l'écriture de tels programmes puisse être comparativement facile, elle peut avoir des conséquences réelles à long terme. Par exemple, les systèmes basés sur des callbacks anonymes fournissent très peu d'informations lorsqu'il s'agit de raisonner à leur sujet, de les maintenir ou, plus important encore, de déterminer ce qui se passe, où et pourquoi les pannes de production et les mauvais comportements se produisent. Les bibliothèques et les plates-formes conçues pour les systèmes réactifs (comme le projet Akka et la plate-forme Erlang) ont appris cette leçon depuis longtemps et s'appuient sur des composants adressables à longue durée de vie qui sont plus faciles à conceptualiser sur le long terme.
Ainsi, le choix d'un bon paradigme de programmation, qui impose des éléments tels que l'adressabilité et la gestion des défaillances, s'est avéré inestimable en production, car il est conçu en tenant compte de la dureté de la réalité, pour s'attendre à l'échec et savoir l'accepter, plutôt que d'essayer de l'éviter.
La programmation réactive est une technique de mise en œuvre très utile, qui peut être utilisée dans une architecture réactive. Cependant, pour construire un système réactif, il ne suffit pas de faire abstraction des ressources spécifiques au système d'exploitation et de saupoudrer des API asynchrones et des coupe-circuits sur une pile logicielle existante et héritée. Il s'agit plutôt d'accepter le fait que vous construisiez un système distribué comprenant de multiples services. Ils doivent travailler de concert et fournir une expérience cohérente et réactive ; non seulement lorsque les choses fonctionnent comme prévu, mais aussi en cas de défaillance et sous une charge imprévisible.
