Cet article s’insère dans la série « microservices » écrite par François Berthault dans le cadre de la participation de Talan Labs à Devoxx 2017, du 5 au 7 avril prochains au Palais des Congrès de Paris.
À l’heure de la digitalisation et du tout agile, les applications monolithiques semblent inéluctablement vouées à disparaître au profit d’architectures logicielles en microservices. Plus souples, elles répondent aux besoins d’évolution rapides. Mais la philosophie et l’organisation des projets doivent s’accorder. Quelques astuces pour bien démarrer avec les microservices.
Depuis des années, pour ne pas dire des décennies, développer une application se faisait dans la très grande majorité des cas avec une plateforme logicielle unique. On parle alors de monolithes.
Simples par certains côtés (une seule technologie à maîtriser), ces monolithes sont forcément plus complexes à faire évoluer, tant leurs fonctionnalités sont interdépendantes. Parfois même la correction d’une simple faute d’orthographe peut prendre une journée entière !
Au contraire, plus souple et plus agile, l’**architecture en microservices **offre toute latitude aux développeurs pour ajouter ou modifier des fonctionnalités, faire évoluer l’application pour améliorer l’expérience utilisateur, etc. Le tout très rapidement et sans risque pour le reste des fonctionnalités. En outre, chaque microservice va pouvoir être développé avec le langage qui correspond le mieux à ses fonctions.
En bref, l’architecture logicielle en microservices, c’est l’assurance de disposer en permanence d’une application à jour et en phase avec les attentes des utilisateurs.
Faire du microservices pour du microservices ne sert à rien. Encore faut-il adhérer aux objectifs inhérents à ce type d’architecture. À savoir tout d’abord et comme on l’a vu, gagner en agilité. En termes de développement comme en termes de maintenance fonctionnelle et corrective.
Ensuite, gagner en qualité. Le risque d’une application monolithique est en effet une dilution des responsabilités entre l’ensemble des développeurs, et surtout une certaine cécité : l’application étant tellement gigantesque que chaque développeur n’est jamais certain que ses actions ne risquent pas d’endommager le reste de l’application.
À l’inverse, une application développée en microservices gagne véritablement en qualité : plus faciles à documenter, ces derniers seront d’autant plus faciles à maintenir ou faire évoluer individuellement.
À première vue, on pourrait croire à un système miraculeux tant les avantages semblent nombreux, ce qui est le cas. Mais aussi miraculeux soient-ils, les microservices n’enlèvent rien à la complexité des applications : ils en déplacent simplement le centre de gravité.
Car pour répondre aux besoins et aux processus métiers, les interactions devront toujours exister, les tests effectués, les déploiements assurés, et les fonctionnalités maintenues, etc.
On l’aura compris, des modules plus petits facilitent la maintenabilité d’une application. Néanmoins, attention à une découpe trop granulaire qui conduirait à la création de nanoservices !
En bref, pour un découpage fonctionnel efficace, il est impératif, encore plus que dans le cadre d’une application monolithique, que l’équipe de développeurs comprennent parfaitement le métier et les usages que doit remplir l’application. C’est à cette condition que le découpage sera juste et cohérent, sans complexifier l’application plus que de raison.
En plus de transformer l’infrastructure logicielle d’une application, les microservices vont également modifier la façon d’aborder la création d’applications. Descendue d’une certaine tour d’ivoire, la DSI doit plus que jamais (c’est déjà de plus en plus le cas) s’intégrer aux métiers.
Car pour bien réussir une migration vers des architectures en microservices, il est essentiel d’étendre à l’ensemble de l’entreprise ce qui fait la force du DevOps en interne à la DSI : une communication et une collaboration toujours plus étroites entre toutes les parties prenantes, et où la maîtrise d’ouvrage est finalement de la responsabilité de chacun.
Vous avez aimé cet article ? Découvrez ou redécouvrez les autres épisodes de la série « Les microservices pour une architecture orientée web » :
_Partie 1 _Les microservices pour une architecture orientée web n°1 : Définitions et caractéristiques
_Partie 2 _Les microservices pour une architecture orientée web n°2 : Un changement de point de vue
_Partie 3 _Les microservices pour une architecture orientée web n°3 : Organisation des équipes pour une projet d’architecture en microservices
_Partie 4 _Les microservices pour une architecture orientée web n°4 : Simple comme Spring Boot
_Partie 5 _Les microservices pour une architecture orientée web n°5 : Spring Cloud, le couteau suisse des microservices
