‘API Management & Backends’ : intégration ‘as-is’ ou réurbanisation ? - 2ième partie

Auteurs :

Laurent Baumard

Directeur associé

Contactez

En collaboration avec Jérôme BESSON

3 minutes

L'approche 'API First' consiste à concevoir une API à partir de sa finalité d'usage. Cette API est désignée par "API Usage". Elle est la seule connue des consommateurs. Son invocation déclenche l'appelle à une ressource sous-jacente du système d'information dite "API Ressource". Lorsque l'API ressource est une ressource existante du système d'information, il existe de facto un désalignement fonctionnel, voire technique avec l'API Usage que l'on désire. Pour palier ce différentiel, il est commun d'utiliser des 'middlewares', qui servent de 'in-between' pour opérer les transformations nécessaires. Les ESB (Enterprise Services Bus) emblèmes de l'ère SOA et qui règnent en maître dans les systèmes d'information pour réaliser ces alignements ne sont pas adapté aux nouveaux patterns d'intégration micro-services et vont se muer en micro-médiateurs orchestrés au sein d'un service mesh. Découvrez les fondements de cette révolution.

# Alignement API Usage <> API Ressource

L’approche dite ‘API First’ par nature ‘top-down’ impose, sauf création d’une ressource ex-nihilo, l’adaptation technique et/ou fonctionnelle pour accoster l’API ainsi conçue (API Usage) avec le ‘backend' existant capable d’en porter l’exécution sous-jacente (API Ressource). Si l’adaptation est légère, elle peut se traiter via un 'ESB' en implémentant un service d’intégration.

Si elle est plus profonde, ce qui est souvent le cas, la micro-servicisation est la réponse idéale.

# La microservicisation à la rescousse

La micro-servicisation peut se faire à différents niveaux architecturaux :

Au niveau Backend via des micro-services dits 'Backend'

  • Il s'agit ici de restructurer les applications monolithiques en services de grains plus fins, fonctionnellement intégrés, autonomes, composables, minimalistes, évolutifs et résilients. Une rénovation souvent complexe et coûteuse et qui doit être conduite progressivement. L'idée étant de développer des micro-services ayant le minimum d'adhérence avec l'existant tout en le valorisant au mieux. Une équation qui peut ne pas avoir de solution nécessitant alors soit une réécriture complète soit une micro-servicisation au niveau intégration.

Au niveau Intégration via des micro-services dits d’intégration

  • Il s'agit ici d’utiliser des microservices d'intégration plutôt qu'un ESB, en s’appuyant par exemple sur des frameworks d'intégration (ex : Apache Camel) ou solution d’intégration (ex : Ballerina WSO2).

# Le ‘Service Mesh’ brique indispensable ?

La multiplication des microservices amène à gérer un réseau complexe de services qui induit des nouvelles exigences pour gérer les ressources, la sécurité, le trafic, le routage et les incidents dans les échanges entre services.

Le ‘Service Mesh’ est la réponse à ces exigences. Il est le moyen de contrôler comment les différents services communiquent les uns avec les autres.

Couche d'infrastructure intégrée directement dans les microservices, il fournit toutes les fonctionnalités pour cataloguer, sécuriser, contrôler et tracer l’activité des microservices. Il est orienté vers la communication de service à service « Est-Ouest » là où l’API Management se concentre sur les interactions « Nord-Sud ».

Plus précisément, un ‘Service Mesh’

  • décharge la logique de communication des microservices, en s'appuyant sur un réseau de proxy ('sidecars').
  • fournit des capacités pour acheminer les demandes entre les microservices déployés sur des conteneurs avec des fonctions de résilience (‘circuit breaking’, ‘retries and timeouts’, ‘fault injection’,’ load balancing’, ‘failover’) et des fonctions d'observabilité pour localiser les dysfonctionnements (mesures, surveillance, traçabilité).

# Vers un pattern de micro-intégration


Un’ Service Mesh’ n'est pas un ESB distribué. De fait, en l’absence d’un système de régulation des intermédiations entre services, il revient de faire porter la logique d’intégration (ex: ‘mapping’, ‘pub/sub’, ‘choregraphy’) par les microservices eux-même. Pour désigner cette intelligence d’intégration on parle de microservice ‘Smart endpoint’.

Cette intelligence légère doit être en mesure de supporter les communications de type ’Request-Reponse’ et ‘Observer’ (‘event-based’). Dans ce dernier cas, il faut utiliser un LMB (« Lightweight Message Bus ») qui réalise généralement une fonction basique de routage de message, donc sans grande intelligence embarquée. On parle d’ailleurs de ‘Dumb pipelines’


# ‘ESB, API Management & Service Mesh’…association éphémère ?

L’APisation et la micro-servicisation du système d’information impliquent de revoir les modèles d’intégration et d’intégrer des nouveaux ‘middlewares’, ‘API Management’ et ‘Service Mesh’ au côté des solutions historiques telles que les ESBs.

Cette cohabitation pourrait à termes ne plus être nécessaire et le pattern de gestion centralisée des échanges issues de la 'SOA' intégralement refondé en un modèle d’intégration microservice totalement distribué.


Retrouvez la première partie pour comprendre la nouvelle problématique d'intégration.

Découvrez également l'article sur le services mesh "Voyage au coeur d'un service mesh - 1ère partie"