Les pièges du traitement des microservices comme une solution globale | de William Anderson | décembre 2022

Facteurs à prendre en compte lors du choix d’une approche de microservices

En 2016, je faisais partie d’un groupe de stratégie de microservices au sein de mon employeur. Notre tâche ? Soyez prêt à répondre lorsque les clients vous demanderont : « Comment les microservices peuvent-ils révolutionner notre entreprise ? »

En 2022, j’assistais à une conférence au Sommet de l’IA à New York, où les conférenciers de l’USPS et d’Unilever étaient fiers d’annoncer qu’ils avaient réduit leur nombre de services à 900 et 1300, respectivement, et qu’ils visaient maintenant à le réduire considérablement.

Que s’est-il passé pendant ces six années ?

Dans cet article, nous allons explorer les avantages et les inconvénients de l’utilisation des microservices dans le développement de logiciels et examiner certains facteurs à prendre en compte pour décider si cette approche convient à votre équipe.

L’idée d’un microservice est séduisante : une application déployable avec une seule responsabilité, comme raccourcir des URL dans un corps de texte ou envoyer des e-mails. En faisant abstraction de votre logique et en créant quelques dizaines (ou centaines) de ces petits services, vous pouvez créer de nouvelles fonctionnalités en les assemblant simplement.

Cependant, il est important d’être conscient des inconvénients de cette approche. Les microservices introduisent de la complexité et des frais généraux dans un système par l’ajout de pièces mobiles et d’exigences de communication entre les composants distribués. De plus, les microservices peuvent entraîner une duplication de code, car chaque service peut contenir des fonctionnalités similaires ou identiques. Les tests, le débogage et le déploiement peuvent également être plus difficiles en raison de la nature distribuée du système.

Enfin, les microservices peuvent être plus gourmands en ressources, ce qui peut entraîner une utilisation et des coûts plus élevés des ressources. Lors d’une récente conférence au sommet de l’IA à New York, USPS et Unilever ont annoncé avoir réduit leur nombre de services à 900 et 1300, respectivement, et viser à baisser encore.

L’un des plus gros problèmes des microservices est qu’ils sont souvent traités comme une solution globale sans tenir compte des besoins et des contraintes spécifiques d’un projet donné. Quelle que soit la taille des services ajoutés à un système, plus de services signifie plus de complexité, ce qui signifie gérer cette complexité.

Les petites équipes aux ressources limitées devraient disposer d’un service plus important qui gère tout le formatage et l’envoi des e-mails plutôt que de diviser cette fonctionnalité en plusieurs microservices. Cela peut conduire à une meilleure réutilisation du code, à une intégration plus facile pour les nouveaux ingénieurs et à moins de travail DevOps nécessaire pour gérer les déploiements et orchestrer l’application en cours d’exécution.

En général, il est important d’aborder la conception de services dans le cadre de l’architecture logicielle avec un état d’esprit axé sur les personnes plutôt que sur la technique. Les stratégies de développement de logiciels doivent être suffisamment flexibles pour répondre aux besoins de l’entreprise plutôt que d’être dictées par des idéologies techniques.

Lorsque vous décidez d’utiliser ou non des microservices pour une nouvelle fonctionnalité ou une refactorisation, il est important de définir et de planifier avec soin, en gardant à l’esprit les contraintes suivantes :

• Structure de l’équipe : qui gérera la base de code du nouveau service ? Y aura-t-il une redondance suffisante d’ingénieurs qui comprennent comment cela fonctionne ? Aurez-vous besoin d’intégrer ou de retirer régulièrement des ingénieurs au(x) nouveau(x) service(s) ? Moins vous avez de personnes qui comprennent le système complet, plus vous avez besoin d’un système plus simple. Par exemple, si vous avez un seul ingénieur qui développe une nouvelle application exploitant 50 microservices et qu’il part sans laisser de documentation, il sera difficile pour quelqu’un d’entrer et de se mettre au courant. Toutefois, si vous avez un seul ingénieur utilisant un ensemble standard de bibliothèques pour créer un « macroservice » contenu et déployable, l’intégration ou la prise en charge sera beaucoup plus facile.
• Expérience de déploiement et d’orchestration : si vous avez un grand nombre de services dans votre architecture, les tâches quotidiennes de surveillance, de déploiement, de restauration, de mise à l’échelle, etc. seront très différentes de celles impliquées dans le déploiement d’un seul service monolithique. Pour gérer un grand nombre de services et les surveiller efficacement, vous aurez besoin d’une équipe expérimentée constituée à cet effet.
• Contexte commercial : lorsque vous décidez d’utiliser des microservices pour une nouvelle fonctionnalité ou un refactor, il est important de prendre en compte le contexte commercial de votre projet. Cela inclut des facteurs tels que la taille et la complexité du projet, les ressources disponibles (y compris la taille et l’expertise de l’équipe) et le retour sur investissement/coûts attendus.

Il y a six ans, nous explosions d’enthousiasme à l’idée de tout refactoriser en microservices. Maintenant, beaucoup d’entre nous remboursent des dettes techniques plus élevées que prévu. C’est une bonne leçon, sinon récurrente : les nouvelles technologies et philosophies sont passionnantes mais doivent être mises en œuvre spécifiquement et pour une valeur commerciale, pas uniquement par excitation.