Les microservices, une réponse architecturale aux enjeux d'aujourd’hui


Publié le: 24 mai 2017 par Luc Champalle

Que l’on soit une grande institution publique, une entreprise en pleine transformation numérique ou un pure player digital, l’attente vis-à-vis des applications est désormais la même. Leur flexibilité doit être maximale pour pouvoir évoluer très rapidement au gré des demandes des clients, des initiatives des concurrents et des dernières innovations technologiques. Popularisés par Netflix et Amazon, les microservices sont une approche d’architecture logicielle émergente qui répond précisément à ce besoin.

Dans un modèle d’architecture microservices, l’application se décompose en un ensemble de services fonctionnels élémentaires indépendants. Liés entre eux par des contrats d’interface, les microservices accomplissent chacun une tâche donnée, en toute autonomie. Les échanges s’effectuent selon un protocole standard, souvent dans une communication de type REST, sans qu’aucune intervention intelligente du réseau ne soit nécessaire.

L’application se présente donc comme un scénario métier dont les microservices constituent les étapes unitaires, chacun appelant et produisant les informations spécifiées par les contrats d’interface. En revanche, rien n’est imposé quant à la technologie utilisée pour y parvenir.

Cette approche offre d’immenses avantages en termes de maintenance et d’évolutivité puisque l’on peut modifier, supprimer ou remplacer les services indépendamment les uns des autres, sans impact si le contrat d’interface ne change pas, ce qui allège considérablement le développement et le déploiement des évolutions. Par ailleurs, on gagnera en capacité de montée en charge – il suffira d’allouer davantage de ressources au service sollicité et non à l’ensemble de l’application –, et en continuité de service, l’application pouvant continuer à fonctionner en mode dégradé si l’un des services est indisponible.

« Résolument orientée métier, l’architecture microservices a des conséquences majeures sur l’ensemble du cycle de vie applicatif, à commencer par l’organisation du développement qui n’est plus axée autour de la technologie mais entièrement verticalisée. »

Chaque microservice est confié à une équipe, généralement pluridisciplinaire, qui en est responsable de bout en bout, de sa création à sa maintenance. Pour produire durablement les résultats exigés par le contrat d’interface, elle ne doit donc plus raisonner en termes de projet mais de produit.

La gouvernance de l’application se trouve ainsi décentralisée. Au lieu d’avoir à composer avec de multiples parties prenantes, et donc de devoir trouver des compromis, chaque problématique fonctionnelle sera résolue de la meilleure manière, par exemple en choisissant l’outil le mieux adapté, et même si parfois la décentralisation peut s’avérer compliquée. En outre, les équipes travaillent de façon indépendante, en parallèle, avec des procédures de test plus simples à mettre en œuvre et la possibilité de livrer à leur rythme, ce qui accroît encore la productivité du développement.

Pour les équipes, il s’agit cependant d’une profonde transformation dont il ne faut pas négliger l’ampleur. L’indépendance des services et la finesse de la granularité exigent en effet davantage d’abstraction, d’autonomie, d’engagement et de relation client. Cela constitue souvent un vrai défi mais cela permet aussi à la DSI de faire évoluer ses ressources et de les réorienter vers le cœur de métier de l’entreprise.

Avec autant de processus que de services et l’échange d’innombrables requêtes, le modèle microservices n’est guère adapté aux environnements limités en ressources, comme l’embarqué. Ce n’est donc pas la panacée mais il se prête particulièrement bien à deux cas d’usage.

Le premier est celui d’un important legacy à moderniser rapidement.

« L’architecture microservices permet en effet de migrer d’un patrimoine monolithique vers une structure atomisée de façon progressive et moins risquée. »

Le code est conservé mais les éléments sont dissociés, ce qui permet de les remplacer ou de les réécrire au fil des demandes des clients, des disponibilités budgétaires ou des évolutions technologiques. Par exemple, on pourra se débarrasser d’une interface vieillissante et lui substituer des technologies modernes sans remettre en cause la mécanique applicative sous-jacente. C’est cette approche qu’a mise en œuvre la CNAF avec Atos pour son portail partenaires.

Un autre emploi majeur des microservices concerne les applications appelées à beaucoup évoluer en fonction, par exemple, des réactions des utilisateurs ou des évolutions du marché, comme cela peut se pratiquer dans le e-commerce. Dans ce modèle, il est très facile de modifier, désactiver ou lancer une fonctionnalité sans bouleverser l’équilibre de l’application, qui est ainsi en mesure d’épouser toutes les fluctuations de l’activité.

Partager


Qui est Luc Champalle

Responsable de marché pour la CNAF
Luc Champalle est chef de projet pour le compte CNAF dans le cadre d’un marché de services applicatif concernant la gestion de la relation allocataires et partenaires. Luc a plus de vingt-cinq ans d’expérience dans le génie logiciel. Il est en charge de gérer un portefeuille d’une vingtaine de projets et/ou TMA pour la CNAF et de diriger cinquante collaborateurs contribuant à des prestations sur plusieurs sites en France et un centre de service localisé à Sophia-antipolis. Avant de rejoindre ATOS, Luc a occupé différents postes dans sa carrière : Architecte de solution, Développeur Hardware, Développeur Logiciel, Ingénieur Support, Expert Performances et Qualité et Chef de projet chez Texas Instruments, IBM et Lucent Technologies.

Suivre ou contacter Luc