Microservices : Etes-vous prêt à relever le défi ?

© Martin Fowler

Durant les dernières décennies, plusieurs nouvelles méthodologies et architectures ont été introduites dans l’industrie logicielle, toutes avec la promesse de rendre les entreprises plus productives, agiles, flexibles et  capables de répondre plus efficacement aux changements imposés par le marché et les réglementations. Ainsi on a vu les services Web, SOA, les architectures basées sur les composants, les ESB, et j’en passe.

Aujourd'hui c'est au tour des microservices.

La mise en œuvre d’une architecture en microservices se heurte à plusieurs problématiques organisationnelles, conceptuelles et techniques. Je me contenterai dans cet article de citer un exemple de chaque type :

La structure d’entreprise 

Nous avons tous entendu parler de la loi de Conway : «  les entreprises qui conçoivent des systèmes sont contraintes de les produire sous des designs qui sont des images de leur structure de  communication. ». Si vous avez une équipe « front », une équipe « back », une équipe d’exploitants,…  chacune spécialisée dans son métier, votre entreprise sera contrainte à concevoir des systèmes qui ressemblent à ces niveaux. Une organisation des équipes techniques en silos avec des « managers » au-dessus de ces équipes est un obstacle à la mise en œuvre de l’architecture en microservices.

La granularité des microservices

L'un des problèmes souvent évoqués dans la conception d'une architecture en microservices, c'est estimer le bon niveau de granularité des microservices. Des microservices de trop grandes tailles, comme ils ont pu être conçus dans les architectures SOA, perdent leurs avantages en termes de souplesse en production. Au contraire, des microservices trop fins vont être plus faciles à maintenir et faire évoluer, mais seront très difficiles à gérer en production. En pratique trouver la bonne granularité des microservices reste un exercice complexe et périlleux.

Les appels de processus distants

Dans une application monolithique, les services sont appelés via des appels internes de classe et de méthode, par contre lorsqu’on adopte une architecture en microservices on n’utilisera que des appels de processus distants (RPC). Ces derniers sont plus lents ce qui causera une perte de performance de notre système.

Morale de l’histoire, réussir une architecture en microservices dépend de la capacité de votre entreprise à trouver les réponses à toutes ces problématiques, et à mon avis la tâche la plus complexe c’est d’adapter l’organisation de votre entreprise aux microservices. Des entreprises comme Netflix ou Amazon, qui ont réussi à mettre en place cette architecture, avaient une organisation interne adaptée à cette architecture.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *