L’architecture en microservices est une approche intéressante dans la construction de systèmes d’informations, en particulier sur des infrastructures cloud où ce type d’architecture s’adapte naturellement. Cependant, cela reste un choix d’architecture, dans la filiation du SOA, avec des cas d’usage plus ou moins adaptés1.
En premier lieu, construire une architecture en microservices implique de choisir un niveau de granularité (de finesse) des services, qui n’obéit à aucune règle prédéfinie : on propose généralement d’avoir un service par fonctionnalité, mais plus le service est gros, plus on se rapproche d’une application monolithique, et à l’inverse plus le service est fin, plus la complexité induite peut être importante. Il faut donc que le service (ou la fonctionnalité) soit suffisamment indépendante du reste mais pas trop complexe non plus.
La transition entre l’architecture monolithique des applications des années 90 et les applications à base de microservices actuelles. © PWC via JDN
Ensuite on les fait communiquer et interagir, soit par des API REST, soit par des échanges asynchrones. Ces derniers sont peu évoluées, mais robustes : leur but n’est pas d’ajouter des fonctionnalités mais uniquement d’assurer un échange fiable de messages et d’informations entre plusieurs services, justement en n’ayant que peu ou pas de couplage ou de friction.
Enfin, on orchestre ces services, en les déployant, en les monitorant, etc. Souvent, l’organisation DevOps est adaptée à cette architecture, en institutionnalisant l’indépendance des équipes et donc des services composants le système final. L’équipe DevOps doit en théorie être responsable de son service, y compris de son suivi en production, mais certains éléments comme la sécurité du service et la sécurité globale du système sont difficiles à positionner dans ce contexte.
Le passage à une architecture en microservices est l’occasion d’adopter une organisation de type DevOps. Ca manque toutefois un peu de sécurité, non ? © Adrian Cockcroft / Slideshare via JDN