Depuis ces dernières années, Harington préconise à ses clients l’adoption des architectures en microservices pour leur maintenabilité dans le temps et surtout leurs capacités à accélérer le time-to-market des nouveaux produits applicatifs ou solutions logicielles.

Le principe est simple et consiste à diviser la complexité du projet en une multitude de sous-problèmes indépendants qui peuvent être gérés par différentes équipes. On obtient un réseau de webservices par micro-services, un micro-service répondant à une seule fonctionnalité ou un problème. Tous ces micro-services sont ensuite orchestrés pour apporter la solution finale à l’expérience utilisateur attendue.
Hormis des bonnes pratiques telle qu’une organisation adaptée, de l’automatisation DevOps, une infrastructure adaptée et évolutive, voici les principaux écueils auxquels vous devrez vous confronter :

• Premier écueil auquel on se heurte est la taille du « micro » service car tous les domaines applicatifs ne sont pas forcément divisibles en petites unités !
• 2ème écueil, on a souvent plusieurs applications dont certaines parties utilisent la même fonctionnalité avec un risque donc de chevauchement.
• 3ème écueil, c’est le côté « humain » des programmateurs qui ont pour fâcheuse habitude de rajouter des fonctionnalités à tout ce qu’ils font 😉  … Et ils n’ont pas forcément autorité non plus pour relancer le refactoring du « mini monolithe » qu’ils découvrent lors de leur intervention à postériori, si celui-ci n’est pas conforme au micro-service attendu…
• 4ème écueil, confondre une vraie architecture micro-services avec un monolithique distribué en de nombreuses petites applications qui ne permet pas notamment de paralléliser les développements, (sans compter les problèmes de latence et de dépendance) … Résultat ? C’est toujours une architecture monolithique avec en plus la complexité d’une architecture distribuée !

Aller plus loin sur le sujet ? Pour ou contre les micro-services ? https://betterprogramming.pub/microservice-pros-cons-69ffe8c39faf