La migration d'un système existant vers une architecture microservices est très différente de la construction d'un nouveau système, revendique Joris Kuipers dans une présentation décrivant le processus continu de refactoring d'une grande application monolithique vers une plus distribuée ou basée sur une architecture microservices.
Kuipers, architecte chez Trifork Amsterdam, décrit l'application comme un système de gestion de dossiers électroniques des patients pour les soins de santé, créé il y a six ans, et qui pour les deux premières années était une seule application monolithique avec quelques intégrations business-to-business (B2B). Dès le début, elle a été basée sur Command Query Responsibility Segregation (CQRS) en utilisant Axon, un framework open source développé par Trifork. Cela a fonctionné très bien, mais à mesure que le système et le nombre de clients croissaient, de nouvelles exigences se présentaient, notamment l'exigence des dépenses d'assurance qui devait être une application distincte mais qui exigeait toujours des données de l'application actuelle. Cela a été un changement important vu qu'ils ont maintenant dû se déplacer vers des applications multiples qui partagent les états.
Aujourd'hui, l'application de base reste encore relativement importante, entourée de trois applications distinctes pour les dépenses d'assurance, avec près de 40 intégrations tierces intégrées dans une douzaine d'applications déployables. Elle héberge environ 65 tenants et 12 000 utilisateurs.
Beaucoup d'intégrations ont un cycle de vie beaucoup plus court que l'application de base, de sorte que leur principale raison de passer aux microservices a été la nécessité d'étendre leur développement pour être en mesure de s'adapter à ces différents cycles de vie. La mise à l'échelle des équipes de développement et la mise à l'échelle du rythme de développement ont été les véritables moteurs de progression.
Puisqu'ils avaient une application basée sur CQRS et les événements, lors du démarrage du refactoring, ils ont décidé d'utiliser les événements comme un point d'intégration et de diffuser tous les événements par l'intermédiaire d'un message broker vers les autres applications intéressées. Ils ont extrait tous les codes B2B existants liés à l'intégration dans des applications distinctes et ils les ont connectés au broker pour obtenir tous les événements émis. Pour les applications extraites ayant besoin de communiquer à l'application principale, elles utilisent les commandes CQRS déjà présentes dans le noyau.
Un exemple typique du flux de données est lorsqu'un utilisateur utilise l'application principale pour modifier certaines données. Cette modification se traduira par des événements publiés que les applications d'intégration lisent en lecture asynchrone, et basé sur la logique cela peut déclencher une notification envoyée à un partenaire externe. Kuipers voit cela comme une architecture “hub and spoke” avec leur application principale étant le hub, entouré par plusieurs petites applications. Il note que ce type de décomposition, par les consommateurs, est un moyen de se rapprocher des microservices qui leur convient très bien.
Pour Kuipers, les événements constituent une aide énorme dans la division d'un système parce qu'ils sont asynchrones par nature, décrivent quelque chose qui s'est déjà produit, et est quelque chose que les autres systèmes peuvent écouter et réagir. Il note que l'utilisation des événements introduit également quelques défis, particulièrement il est important de réfléchir quand les événements deviennent l'épine dorsale pour l'intégration :
- Ils peuvent créer un couplage car ils forment une structure de données partagée.
- Certains événements peuvent avoir besoin d'être privés dans une application ou un service.
- La granularité des types et la quantité de données nécessaires pour empêcher un gestionnaire d'événements d'avoir à demander plus de données.
- L'évolution des événements au fil du temps sans rupture des clients.
En conclusion, Kuipers note qu'ils sont maintenant en mesure de développer rapidement et de déployer de nouvelles intégrations à l'écart de l'application de base, ce qui signifie également un risque réduit puisque les systèmes de base peuvent être laissés intacts. Selon Kuipers, tous ces éléments leur ont donné un avantage important et compétitif.