Le coût des microservices (2020)

• Article sur les coûts et les avantages d’un passage d’un backend monolithique à une architecture de microservices
• À mesure que le nombre d’équipes contribuant à une base de code unique augmente, les composants deviennent de plus en plus couplés, ce qui réduit la productivité et accroît la complexité
• Une solution pour atténuer ces problèmes consiste à scinder le backend monolithique en un ensemble de services déployables indépendamment, communiquant via des API : les microservices
• Le terme « micro » est trompeur, car un service n’a pas besoin d’être « micro ». Le terme plus approprié serait architecture orientée services
• Décomposer le backend en un ensemble de services aux frontières bien définies accélère le développement de l’application, car une petite équipe suffit pour développer et exploiter chaque service
• Chaque microservice peut être mis à l’échelle indépendamment et adopter une pile technologique différente selon ses besoins, ce qui facilite l’expérimentation et l’évaluation de nouvelles technologies
• Cependant, l’architecture de microservices ajoute davantage de pièces mobiles à l’ensemble du système, ce qui augmente la complexité et exige un certain niveau de standardisation
• Utiliser des langages, bibliothèques et stores de données différents pour chaque microservice peut se transformer en désordre difficile à maintenir, rendant les déplacements de développeurs entre équipes plus compliqués
• Pour prendre en charge un grand nombre de services indépendants, il faut pouvoir créer facilement de nouveaux serveurs, stores de données et autres ressources, ce qui nécessite une automatisation importante
• Les appels distants sont coûteux et introduisent de nouvelles façons pour le système d’échouer ; des mécanismes de défense comme les timeouts, les retries et les circuit breakers sont donc nécessaires
• L’intégration continue garantit que les modifications de code passent par des processus automatisés de build et de test avant d’être fusionnées dans la branche principale
• Les tests d’intégration de l’ensemble des microservices sont bien plus difficiles que ceux d’un monolithe ; lorsque des services individuels interagissent, des comportements très subtils et inattendus peuvent apparaître
• Les équipes qui développent les services sont généralement aussi responsables des appels liés à ceux-ci, ce qui crée des frictions entre le travail de développement et les coûts opérationnels
• Déboguer les pannes système devient plus difficile avec les microservices ; un bon logging et un bon monitoring sont essentiels à tous les niveaux
• Scinder une application en services distincts signifie que le modèle de données n’existe plus dans un store de données unique ; il faut donc généralement accepter une cohérence éventuelle
• En général, il vaut mieux commencer avec un monolithe et ne scinder que lorsqu’il devient difficile de définir correctement les frontières entre services
• Il ne faut adopter une approche microservices-first que si l’on a déjà de l’expérience en la matière, si l’on a construit une plateforme adaptée, ou si l’on a pris en compte le temps nécessaire pour en construire une