APIs et Architecture Événementielle : Le Duo Gagnant

Introduction

À l’ère où les systèmes d’information doivent être performants dans la réception et le traitement des données, plusieurs approches sont développées pour répondre à ce besoin croissant de performance. Les avancées en matière de données, avec les technologies d’intelligence artificielle (IA) et d’apprentissage automatique, ont poussé les limites de nos architectures et de nos méthodologies.

Aujourd’hui, plus de 87 % du trafic Internet est axé sur les API (Interfaces de Programmation d’Applications) liées aux données. Les APIs jouent un rôle central dans cette transformation, mais elles présentent également certaines limites, notamment en ce qui concerne la communication asynchrone ou non bloquante.

Quelques rappels & Définitions

Un bref rappel sur les APIs : une API est une interface de programmation informatique permettant à des applications ou à des systèmes informatiques d’échanger des données. Parmi les types d’API, on trouve REST (Representational State Transfer), SOAP (Simple Object Access Protocol), gRPC, GraphQL, et bien d’autres. Actuellement, REST, basé sur le protocole HTTP, est le type d’API le plus couramment utilisé pour sa simplicité et sa compatibilité.

Les communications sont traditionnellement basées sur le modèle client-serveur, où le client émet une requête et attend que le serveur fournisse une réponse avant de poursuivre ses traitements. Cette approche présente des limites pour certains besoins, notamment la synchronisation de données dans une architecture orientée microservices.

C’est quoi l’Event Driven Architecture

C’est dans ce contexte que l’architecture orientée événements (Event-Driven Architecture, EDA) entre en jeu. L’EDA repose sur le principe de la diffusion d’événements et de la réaction des systèmes à ces événements. Il est important de noter que l’EDA n’est pas un type d’API, car elle sert à diffuser des événements et à permettre aux systèmes de réagir à ces derniers.

Un événement est défini comme tout changement d’état dans un système. Par exemple, la création d’un utilisateur constitue un événement (l’émetteur) qui déclenche un processus métier. D’autres systèmes peuvent souhaiter réagir à cet événement (les consommateurs). Dans une approche orientée événements, il incombe au serveur d’informer les clients qu’un événement a eu lieu, plutôt que de laisser les clients interroger le serveur pour savoir si un changement a été effectué.

L’architecture orientée événements repose sur trois acteurs principaux :

  • L’émetteur d’événements (Producer) : Il génère des événements en réponse à des actions ou des changements d’état. Ces événements sont ensuite diffusés à des consommateurs potentiels.
  • Le consommateur d’événements (Consumer) : Il écoute et réagit aux événements qui l’intéressent. Les consommateurs peuvent être des applications, des services ou des systèmes autonomes.
  • Le gestionnaire d’événements (Broker) : Il joue un rôle de médiateur entre les producteurs et les consommateurs. Il s’assure que les événements sont correctement acheminés aux consommateurs appropriés.

L’architecture orientée événements offre plusieurs avantages, notamment une meilleure réactivité, une évolutivité accrue, un découplage des composants et une gestion simplifiée des erreurs. Elle est particulièrement adaptée aux cas d’utilisation nécessitant une communication asynchrone et la diffusion en temps réel d’informations.

Plusieurs technologies existent pour mettre en place l’architecture Event Driven au sein d’un , les plus populaires sont RabbitMQ , ActieMQ , Kafka , Solace ,etc…

Apport de l’Event Driven Architecture

L’architecture orientée événements (Event-Driven Architecture, EDA) se révèle cruciale pour résoudre des problèmes de performance dans les systèmes informatiques. En effet, la performance d’un système peut être grandement impactée lorsqu’il doit réagir à des événements tels que l’ajout d’un utilisateur en attendant une action explicite du client. Cependant, l’EDA permet au système de réagir instantanément à ces événements ou d’informer d’autres serveurs nécessitant cette information. Un élément clé de l’EDA est la communication asynchrone, où chaque composant est libre de traiter un événement comme il le souhaite, sans attendre de manière synchrone, ce qui améliore considérablement la réactivité.

Il est essentiel de noter que l’Event-Driven Architecture n’est pas en soi un type d’API, mais elle peut parfaitement s’harmoniser avec les API pour renforcer les systèmes d’information. Comment l’EDA et les API peuvent-elles collaborer pour améliorer un système SI ?

Implication de APIs dans Event Driven Architecture

Déclenchement d’événements via les API : Les API peuvent être utilisées pour initier des événements. Par exemple, un composant peut exposer une API pour créer une ressource, et lorsqu’une nouvelle ressource est créée, un événement est automatiquement déclenché pour informer d’autres composants. Cette méthode garantit la systématisation des événements et permet une réaction cohérente du système.

Abonnement aux événements via les API : Les API peuvent également être utilisées pour décrire comment d’autres composants peuvent s’abonner à des événements spécifiques. Par exemple, un composant peut fournir une API permettant aux autres composants de s’abonner à des notifications en cas de modification d’une ressource particulière. Cette approche simplifie la création de flux d’informations réactifs au sein du système.

Définition du traitement des événements via les API : Les API peuvent servir à spécifier comment les composants réagissent après avoir émis ou reçu un événement. Par exemple, une API peut déterminer comment une autre application doit réagir à un événement donné en effectuant une action précise. Cela facilite l’orchestration des actions entre différents composants du système. En combinant l’EDA avec les API, les systèmes informatiques deviennent plus agiles, réactifs, robustes, évolutifs et résilients. Cette combinaison améliore la gestion des événements, la réduction des goulots d’étranglement potentiels et l’optimisation des performances, ce qui est essentiel dans un environnement numérique en constante évolution.

Conclusion

Dans les configurations globales de nos SI , plusieurs technologies concepts se heurtent pour pouvoir pallier aux problématiques de scalabilité et de fiabilité de données .
Les APIs sont une part très importantes des infrastructures informatiques ,cependant elles sont souvent couplées à d’autre concept tel que l’Event Driven Architecture qui offre une flexibilité avec les communications asynchrones .

Architecture Microservices

Introduction

Aujourd’hui, la majorité des géants du numérique (Google, Amazon, Facebook, Netflix, Uber, Paypal,…) ont adopté une architecture de type microservices pour leurs applications. Dans un monde en constante évolution technologique, cela leur a permis de tirer profit du Cloud et de faire face à la compétition avec les succès et les innovations qu’on leur connaît.  

On peut donc se demander dans quel contexte ce type d’architecture est-il profitable ? Mais surtout, quels sont les bienfaits et les problématiques induits par ce paradigme ?

Les monolithes

On oppose souvent l’architecture microservices à l’architecture dite monolithique. Une application monolithe est composée d’une seule unité applicative qui comprend généralement:

  • Une partie client (pages HTML et code javascript qui s’exécute dans le browser)
  • Une partie serveur (cœur de l’application, le monolithe)
  • Une base de données
Architecture monolithique

Eric Raymond a introduit la notion de « monolithe » dans son célèbre ouvrage « The Art of Unix Programming », voyons ses caractéristiques.

Avantages :

  • Bonne performance car tous les modules sont interconnectés au sein de l’application
  • Facilité de déploiement car on déploie une seule entité

Inconvénients :

  • Couplage fort entre les composants :
    • Si un composant est défaillant, c’est toute l’application qui ne répond plus.
    • La mise à jour d’un composant impacte fortement celles des autres.
  • Plus l’application grandit plus elle devient complexe à appréhender…surtout pour les nouveaux développeurs
  • Dès lors que l’on souhaite apporter une évolution, il faut re-tester et déployer l’intégralité de l’application
  • La parallélisation de nouvelles évolutions est compliquée, voire impossible…
  • Une seule stack technique pour toute l’application
  • Les effets de bord sont moins prévisibles

Comme on pouvait s’y attendre, ce type d’application n’est pas prévu pour absorber des changements fréquents, ce qui est un frein à l’innovation. De plus, une telle application est difficilement scalable pour répondre à des montées de charges, car il faudrait pour cela déployer plusieurs instances de cette même application. Une application monolithique n’est pas résiliente car le dysfonctionnement d’un composant entraine inévitablement son indisponibilité.

Les microservices

L’architecture microservices quant à elle, permet de répondre à ces problématiques avec une approche basée sur le principe « Divide and Rule ». L’architecture microservices consiste à découper une application en petits composants qui vont interagir entre eux, l’application devient donc distribuée.

Un microservice est :

  • Autonome
  • Indépendant
  • Stateless
  • Possède un périmètre fonctionnel précis
  • Possède sa propre base de données
  • « Fait une seule chose et la fait bien » (philosophie Unix)
  • Possède son propre langage

Un microservice doit être vu comme un produit en constante évolution qui répond à des besoins métier. Il est sous la responsabilité d’une seule équipe pendant toute sa durée de vie.

Petit flashback, à la fin des années 90, la SOA (Service Oriented Architecture) est conceptualisée. Sa mise en œuvre facilite l’intégration entre les applications avec une approche de services faiblement couplés et réutilisables. Ces services communiquent entre eux via un protocole commun (souvent SOAP) par l’intermédiaire d’un ESB (Entreprise Service Bus).

Hélas, un des gros points noirs de cette approche est l’ESB qui devient la colonne vertébrale de l’application. Il grossit à mesure que l’application évolue, il devient en quelque sorte le monolithe. Il suffit qu’il tombe en panne et toute l’application est hors-service. De plus, la SOA est plutôt utilisée au niveau du SI de l’entreprise pour faire communiquer des applications entre elles ou avec des services externes. Pour certains, l’approche microservices est une continuité de la SOA alors que d’autres y voient un changement complet. Ce qui est clair, c’est qu’on retrouve des concepts issus la SOA dans l’approche microservices.

En réalité, l’approche microservices va plus loin dans le sens où elle se définit au niveau d’une application qui est éclatée en petits composants fonctionnels. Les microservices vont communiquer entre eux via des protocoles légers (souvent via REST API ou par messages asynchrones).

Architecture microservices

Parmi les nombreux avantages d’une architecture microservices, on peut citer :

  • Les microservices sont indépendants les uns des autres : chaque composant possède son propre cycle de vie
  • L’application est plus résiliente : ce n’est pas parce que un service est KO que l’application entière est KO
  • Développement en parallèle de microservices
  • Découpage fonctionnel de l’application
  • Monitoring plus fin de l’application : ce qui permet d’identifier les microservices les plus sollicités
  • La maintenance est beaucoup plus facile : on fait évoluer uniquement les composants nécessaires
  • Les microservices peuvent utiliser des langages différents
  • Propice à l’innovation technologique dans le sens où on peut faire évoluer seulement un microservice dans un premier temps pour tester un langage ou un framework par exemple
  • La notion d’évolution progressive : différentes versions d’un microservice peuvent cohabiter
  • Application scalable : on déploie davantage d’instances pour les microservices plus utilisés

Une architecture aussi complexe entraîne de nouvelles problématiques telles que :

  • Latence due aux communication réseaux
  • Complexité de l’application déportée dans l’interaction entre les différents microservices
  • Nécessité de maintenir une cartographie des composants
  • Difficulté à packager l’application avec les microservices (chacun possédant sa propre version)
  • Difficulté à définir la granularité d’un microservice

Une application microservices est donc propice à absorber le changement rapidement, est scalable et plus tolérante aux pannes. Elle est parfaitement compatible avec une gestion de projets en mode Agile. En effet, elle facilite la gestion en parallèle de travaux menés par plusieurs équipes. Cela permet d’avoir des cycles de développement plus courts et donc un « time to market » plus court.

Cette approche s’accompagne également d’un changement d’état d’esprit, notamment par la mise en place de pratiques issues du DevOps. Cela peut être couteux au début, surtout s’il faut acquérir ces compétences au sein de l’équipe. Les développeurs peuvent ainsi se focaliser sur les fonctionnalités métiers de l’application grâce à l’automatisation des tâches récurrentes (passages de tests, couverture de code, détection de failles, déploiement,…).

Heureusement, l’architecture microservices a acquis une certaine maturité et une multitude d’outils permettent de faciliter sa mise en œuvre. En voici quelques exemples :

  • Container : Docker
  • Orchestrateur de container : Kubernetes
  • Package manager pour Kubernetes : Helm
  • Service Mesh : Istio, Traefik Mesh, Linkerd
  • Reverse-proxy : Traefik proxy, Istio ingress, NGINX
  • Outils de CI/CD : Gitlab CI/CD, Jenkins
  • Outils de monitoring : Kibana, Grafana, Zipkin, Jaeger
  • Système de cache distribué : Redis

L’architecture microservices et les containers ont permis l’émergence de ce que l’on appelle les applications « Cloud native ». En effet une telle architecture permet de tirer parti de l’élasticité du cloud pour ainsi répondre aux nouveaux besoins.

Conclusion

En résumé, l’architecture microservices permet de construire des applications qui s’adaptent très rapidement :

  • Au changement : les évolutions sont plus fréquentes et moins impactantes
  • A la charge : les instances de microservices peuvent être déployées en fonction de la demande
  • A la panne : l’application continue de fonctionner si un microservice n’est plus opérationnel

Références