Pourquoi utiliser les microservices ?

L’utilisation d’une architecture microservices est particulièrement préconisée sur des gros projets, à forte valeur ajoutée et sur lesquels les besoins suivants se font sentir :

• L’application doit être fiable & disponible : un service doit pouvoir échouer sans compromettre les services voisins évitant une panne généralisée de l’application
• Optimisation du Time to Market : besoins fréquents de mises à jour et de créations de nouvelles fonctionnalités
• Code facilement analysable, compréhensible, évolutif et maintenable
• Déploiement continu
• Indépendance vis-à-vis des technologies
• Besoin en scalabilité : pouvoir supporter des montées en charge désormais rendues plus simples grâces aux architectures cloud.
• Renforcement de la sécurité : le cloisonnement des services rend de fait l’application moins vulnérable aux intrusions
• Optimisation des coûts : hébergement (scalabilité des serveurs cloud) + Amélioration des process de Maintenance et de MAJ entrainent une baisse des temps de développement

On remarque également que ce type de projets s’accompagne généralement dans sa gestion d’une approche AGILE. Chaque service est composé d’une équipe (restreinte) qui fonctionne souvent en SCRUM. On peut y retrouver les profils suivants : Product Owner, ScrumMaster, Experts UX/UI, Développeurs Front/Back, Testeurs.

Chaque équipe est accompagnée d’un référent métier, « le client » qui assiste à certains rituels (i.e. review) et aide le PO à prioriser les prochains incréments à intégrer au product backlog.

Cette organisation présente un fort Avantage concurrentiel : une capacité d’innovation renforcée et couplée à un time 2 market rapide. L’entreprise adapte son outil le plus vite possible aux besoins de ses clients.

Excellent ! Les microservices c’est vraiment la panacée. Que dois-je faire de mon vieux monolithe du coup ? Je le revends sur le bon coin ?

Eh bien pas forcément... On l’a vu, certains projets ne sont (heureusement) pas prévus pour ce type de fonctionnement. Aussi, ne tombons pas dans le manichéisme et voyons les désagréments que peut engendrer une architecture microservices :

• Le coût : généralement la mise en place d’une telle architecture requiert le travail d’équipes affectées chacune à un service. Ce type d’organisation se prête de fait plus aux grosses structures ayant les moyens humains et financiers nécessaires.
• Complexité technique de la plateforme en elle-même.
• Travail d’architecture à systématiquement mettre en place en amont.
• Problèmes de performance des microservices : le fait que les services aient à s’appeler entre eux via API peut créer des latences, que de fait on ne retrouverait pas sur un monolithe.
• Problèmes liés à la communication et la collaboration entre les équipes. Faire collaborer des dizaines d’équipes de 5 personnes environs implique du temps, des coûts et beaucoup d’efforts d’organisation.
• Tests d’intégrations et recette métier. Même problème que plus haut (en pire)
• Implication continue du métier. A priori cela ne sembla pas un inconvénient (d’un point de vue IT tout du moins). Simplement cela phagocytera leur temps de travail sur les autres sujets.

 

Ainsi et ce n’est hélas pas un scoop, il n’existe pas d’architecture miracle pour votre application. Il convient avant toutes choses de prendre le temps de réfléchir à vos besoins immédiats et dans le futur, la solution s’imposera d’elle-même.

N'hésitez pas, à cet effet, à consulter nos articles sur la définition d'une architecture microservices et les principales différences avec les autres modèles.

Envie d’échanger autour des microservices et de connaitre les avis d’un pro ? Goweb étudie votre projet et vous accompagne de A à Z dans le développement et la gestion de votre projet !