API et Microservices, l’agilisation d’un système d’information

Share this post:

L’IT agile est le fruit d’un cheminement intellectuel reprenant les principes clés de l’Agilité et de certaines avancées technologiques, et ayant pour champ d’application tous les aspects de la construction et de la maintenance d’un système d’information : design, code, donnée et infrastructure. Une composante essentielle de cette IT agile est le micro-service et l’ensemble des patterns dont il se nourrit.

Le besoin d’accélérer l’apport de valeur au sein d’un SI complexe

Nous connaissons tous ces SI rendus complexes par une somme d’applications Web, généralement des monolithes, enrichis au fil des années par des besoins d’intégration forte avec d’autres systèmes. Les premières tentatives de découplage, d’abord au niveau applicatif avec les patterns MVC, pour séparer les données de leur représentation, puis au niveau du SI avec l’avènement du SOA n’ont pas réussi à agiliser ces systèmes.

En parallèle, nous avons vu l’émergence des techniques de développements de type agiles. Ces méthodes, répondant aux besoins des métiers de délivrer plus de valeur plus vite, nous ont amené à raisonner en cycle plus réduits.

Ainsi, nous avons dû repenser la façon de travailler et surtout de concevoir nos systèmes.

Les microservices, un outil d’agilisation du système d’information

Aujourd’hui, nous constatons l’opposition entre le besoin accru de « time to market » et de digitalisation, entrainés par les nouveaux parcours orientés utilisateur, et la nécessité de s’appuyer sur des processus existants et entrepôts de données liés au legacy.

Le micro-service, et les API qu’il expose, devient le composant essentiel permettant de gérer les différences de vélocité entre la mise à jour, plus fréquente, des parcours et celle des processus. Mais quelle méthode utiliser pour définir et fabriquer ces micro-services ? Les principes du Domain Driven Design (DDD), introduit par Eric Evans, vont nous permettre de nous concentrer sur le modèle d’exposition de l’API mais également d’identifier les pierres angulaires de notre SI que sont les micro-services via la notion de Bounded Context.

Ce composant répond à plusieurs catégories d’enjeux :

Enjeux métier :

• Disposer d’un catalogue de fonctionnalités réutilisables apportant de l’agilité à la construction de parcours multi canaux / multi utilisateurs (collaborateurs / clients / Partenaires).
• Et offrant des interfaces d’échange avec le SI exprimées selon des concepts connus du métier.

Enjeux IT :

Disposer de composants d’architecture plus autonomes :

• Centralisant la traduction métier des besoins de digitalisation.
• Portant les règles métiers d’utilisation.
• Apportant un découplage et une agilité de mise en œuvre entre des IHM multi canaux rapidement modifiables et des systèmes Legacy plus stables dans le temps.

Enjeux de plateforme :

Disposer des composants d’infrastructure :

• Facilement administrables.
• Rapidement mis en service.
• Adaptable de façon ciblée, à la qualité de service attendue et notamment à la volumétrie des échanges et aux évolutions du trafic d’utilisation.

Un système d’information agilisé par le micro-service mais quid des pratiques de construction ?

Nous pouvons classer les éléments de construction en 3 grandes catégories détaillées ci-dessous :

Principes, méthodes et patterns de construction du micro-service

Domain Driven Design et Architecture Hexagonale

Les bonnes pratiques de construction du micro-service commencent dès la conception avec l’introduction de 2 principes fondamentaux : Le DDD et l’architecture hexagonale. Le DDD va nous permettre de travailler de concert avec le métier pour définir le langage ubiquitaire associé à notre microservice là où l’architecture hexagonale va nous permettre de structurer son architecture logicielle. L’alliance des 2 nous permet d’avoir un cadre de conception fonctionnel (DDD) et applicatif (Architecture hexagonale) facilitant l’amélioration continue si nécessaire dans l’agilité.

Design for Failure

Ce principe de conception, centrée sur la tolérance aux pannes, a le double intérêt d’améliorer l’expérience utilisateur et de réduire le stress des équipes de production. Cela nécessite de penser nos cas d’utilisation, avec le métier, en prenant très tôt en compte les pannes possibles et proposer une expérience dégradée mais toujours fonctionnelle [i].

Une architecture micro-services augmente les liaisons entre ses multiples composants rendant l’évolution de l’ensemble complexe. En effet, si 2 micro-services sont en dépendance et qu’une fonctionnalité est prête sur l’un des deux et pas l’autre, l’activation de la fonctionnalité ne pourra s’effectuer en production qu’une fois tous les développements terminés. C’est là qu’intervient le Feature Flipping, autorisant l’activation retardée d’une fonctionnalité sans attendre la disponibilité des autres composants.

Mode de communication

Publish-subscribe

C’est un des éléments centraux dans le découplage entre les composants d’une architecture orientée micro-service. L’idée est de passer d’un modèle synchrone où un composant interroge un autre en attendant sa réponse à un modèle asynchrone où chaque composant publie des messages représentant des événements fonctionnels du contexte borné. Charge aux autres composant de réagir ou non à ces événements.

Communication synchrone

La communication synchrone reste néanmoins importante dans cette architecture mais elle suit une approche favorisant des protocoles d’échange standards plus simple et moins verbeux (http, REST) et une intelligence portée par les composants aux extrémités [i]. La notion de transaction s’en retrouve modifiée : dans un système distribué, la notion d’atomicité n’existe plus (notamment en cas de panne). On parle maintenant de cohérence à terme. Certains patterns existent pour gérer cette cohérence : chorégraphie et orchestration [ii].

Bonnes pratiques d’assemblage et de tests

Test Driven Development (TDD)- Behaviour Driven Development

En termes d’assemblage et de construction par étape, l’apport des concepts de Test first est important dans l’agilité. Il permet essentiellement pour le métier de s’assurer de la bonne compréhension par l’équipe des règles puisque c’est le métier qui va écrire, en langage naturel, le comportement attendu. Notons ici l’importance du langage ubiquitaire pour assurer la cohérence des échanges.

Canary-Chaos testing

Des nouvelles techniques de tests vont aussi simplifier et sécuriser le déploiement. Le canary testing nous assure que de nouvelles fonctionnalités mises en place sur un petit volume de trafic se comportent correctement avant leur généralisation. Le chaos testing vérifie que le système ne s’écroule pas en cas de défaillance (en lien avec le design for failure décrit plus haut).

Conclusions

Les différents principes et méthodes que nous avons parcourus nous permettent de délivrer plus vite et avec plus d’assurance des systèmes en constante évolution.

Du langage ubiquitaire, permettant de spécifier les résultats attendus par le métier, aux composants d’architecture agiles et des interfaces de communications facilitant le couplage lâche en passant par un mode de construction agile porté par une infrastructure agile basée sur le Cloud. Tout ceci est la recette pour la transformation technique d’un système d’information en cours d’agilisation.

Il nous restera à parler de la data, qui a encore quelques marches à franchir avec le sujet prometteur du datamesh, pour ainsi avoir toutes les cartes en mains pour accompagner la transformation vers une culture Cloud et DevOps essentielle au cycle de vie de nos SI.

Pour continuer cette discussion, n’hésitez pas à nous contacter :

• Olivier Planson : Executive Architect | LinkedIn  | Twitter : @oplanson
• Benoit Blancard : Lead Architect Cloud | LinkedIn

Benoit Blancard

Lead Architect Cloud