Bien qu’elles ne soient pas foncièrement nouvelles, les architectures orientées événements sont de retour en vogue. Très tendance à l’époque SOA, elles reviennent en force portées par le serverless, l’IoT; et les microservices.

Par David Mooter, Senior Analyst, Forrester

Les clients me demandent parfois : « Pourquoi l’architecture pilotée par les événements (EDA) fait-elle tant parler d’elle ? Ce n’est pas une idée nouvelle ». En effet, elle n’est pas nouvelle ! Du traitement d’événements complexes (CEP) aux interruptions matérielles de l’UNIVAC (UNIVersal Automatic Compute), les ordinateurs répondent à des événements de toutes sortes depuis les années 1950.

Mais les progrès de la technologie et de l’architecture ont élevé la valeur des événements au-delà de ce que nous avons vu dans les générations précédentes. Ces tendances font de l’architecture événementielle un modèle important qui ne disparaîtra pas de sitôt.

LES LIMITES DE REST PEUVENT RESTREINDRE VOTRE STRATÉGIE COMMERCIALE

Les plateformes numériques sont construites en exposant les compétences numériques par le biais d’API. Si votre stratégie commerciale est numérique et que la stratégie numérique se résume à REST (Representational state transfer), les limites de REST deviennent les limites de votre stratégie commerciale.
Une stratégie commerciale numérique doit aller au-delà de REST, et l’architecture événementielle en est un élément important. Il existe certains cas d’utilisation où REST est mal adapté, mais le streaming d’événements fait merveille.

Je m’attends à ce que de plus en plus d’organisations appliquent les principes de la gestion des API à l’architecture pilotée par les événements. Les portails d’API se transformeront en portails d’intégration générale incluant des flux d’événements.
Aujourd’hui, les API sont utilisées comme éléments de base pour assembler des produits numériques ; les flux d’événements seront également utilisés comme éléments de base pour ces produits.

VOS DONNÉES DOIVENT ÊTRE FLUIDES ET EN TEMPS RÉEL

La valeur des données est plus élevée que jamais. Alors que, par le passé, les événements étaient davantage considérés comme la logique de programmation à l’intérieur du monolithe ou comme un tissu conjonctif entre deux applications, les organisations trouvent désormais une valeur énorme dans les données transmises par les flux d’événements.

L’intégration de l’architecture événementielle dans une stratégie de données d’entreprise rend les données plus fluides et disponibles en temps réel, ce qui accélère l’agilité en termes de delivery et améliore sa connaissance de l’entreprise.

LES MICROSERVICES ET LE SERVERLESS ONT BESOIN DE L’EDA

Une mise en œuvre réussie des microservices nécessite une architecture pilotée par les événements pour deux raisons :

Premièrement, les appels de service échouent. Ce n’était pas un problème lorsque votre pile d’appels se trouvait dans la mémoire d’un seul processus. Mais avec les microservices, on échange la fiabilité de la pile d’appels contre le chaos du réseau. Si vous vous fiez uniquement aux appels de service synchrones, la défaillance d’un seul service peut avoir un effet important sur vos systèmes informatiques. La livraison asynchrone des événements protège un service contre les pannes de ses cibles en aval. Sans cela, votre réseau d’appels aux microservices deviendra trop fragile pour constituer un système viable.

Deuxièmement, bon nombre de vos applications monolithiques ont toujours été axées sur les événements, et cela doit se poursuivre dans vos applications distribuées. Pensez au mot-clé event en C#, aux paires de classes event / listener en Java ou aux callbacks de fonction en C. Tous ces langages vous permettent d’enregistrer des event listeners (celui qui consomme), à condition que le code soit compilé dans le même monolithe que l’event producer (celui qui produit). Les monolithes étant divisés en microservices, le producteur et le consommateur d’événements peuvent se trouver dans des microservices différents. La capacité d’un microservice à publier des événements vers d’autres est une nécessité si nous voulons maintenir notre logique de base dans une architecture informatique distribuée.

Mis à part les microservices, le code déployé via la fonction serverless as a service (FaaS) ne peut s’exécuter qu’en réponse à des événements. La valeur du FaaS ne peut être récoltée que si vos applications sont axées sur les événements.