Microservices – The One with Polyglot Portfolio

Lors de cette présentation James Lewis, consultant chez ThoughtWorks et auteur de plusieurs articles sur les microservices, nous partage un retour d’expérience sur la mise en place de ces derniers.

James commence par nous présenter le contexte :

• Une grande compagnie d’assurance américaine (gestion des assurances habitations, automobiles et vies)
• Manque de communication entre les équipes techniques et business
• Des cycles de releases de 3 à 6 mois
• Base de code énorme (des millions de lignes)
• Langage VB.Net
• Des règles métiers éparpillées et « oubliées »

Il poursuit en nous présentant les travaux réalisés sur deux principaux axes.

Organisationnel

James évoque la mise en place d’équipes cross-fonctionnelles, colocalisées : un Product Owner/ Business analyste, des développeurs, des testeurs et des opérationnels dans chaque équipe.

Cela n’est pas sans nous rappeler l’organisation en feature team.

Autre point, gagner la confiance du client. Son conseil est de commencer petit en attaquant des points avec de faibles risques.

Technique

James nous présente ensuite la nouvelle architecture. L’idée est de séparer fonctionnellement l’application. En résumé nous nous retrouvons avec trois services :

• Assurance habitation
• Assurance automobile
• Assurance vie

De cette manière, ces derniers gèrent leurs propres règles métiers, leur cycle de vie et leurs technologies (i.e base de données, langage). James souligne avoir appliqué le Single Responsibility Principle à ces services. D’ailleurs il cite « as we chunk up domains, each domains should be small enough to fit in my head ».

James poursuit en nous expliquant que ces services sont basés sur la notion d’Event Sourcing et plus particulièrement CQRS. Il nous met en garde sur le fait que cette approche offre beaucoup de souplesse et devient rapidement difficile à gérer. En effet CQRS prône un modèle en écriture et un en lecture. Assurer de la consistance entre ces modèles demande beaucoup de rigueur.

Un autre avantage de ce découpage en microservices est le monitoring. James explique que l’approche évènementielle permet de collecter plus efficacement et de manière plus pertinente des données techniques et business. Cela a notamment permis de mettre en place des métriques sous forme de dashboards avec Graphites.

James nous présente ensuite la notion de RCA (Replaceable Component Architecture). L’idée est de prendre indépendamment chaque service et de faire évoluer les sous-composants.

Par exemple, concernant le service d’Assurance vie, ils se sont rendus compte qu’une base de données NoSql orientée document était plus pertinente qu’une base Sql classique.

James poursuit en expliquant que l’approche microservice renforce le concept de « the right tool to do the job ». En effet, au départ, l’application était composée uniquement du langage VB.Net et d’une base Sql Server. Au final, chaque application se retrouve avec son type de base de données, son ou ses langages (VB.Net, NodeJs, Erlang). Ces outils adressent des besoins spécifiques et permettent de résoudre des problématiques plus efficacement.

James termine sa présentation sur des feedbacks personnels :

• L’approche Event Sourcing permet de résoudre beaucoup de problématiques
• La mise en place de l’Event Sourcing peut devenir un cauchemar (With great power comes great responsibility)
• Pouvoir utiliser plusieurs langages de programmation pour résoudre des problématiques spécifiques est efficace
• Etre rigoureux dans le design d’API entre les microservices

A noter que que ce projet a pris du temps : 4 années ont été nécessaires pour mettre en place l’organisation et la migration. James a bien insisté sur le fait que des efforts considérables ont été effectués au début du projet. En effet, faire changer les mentalités sur l’organisation des équipes et la manière de concevoir les services a été un préambule nécessaire pour travailler efficacement.