L'objectif de cet article est d'aider ceux qui envisagent d'adopter une architecture microservices à comprendre quelles parties de l'application sont le plus fortement impactées par le nouveau processus de conception, puis à prendre une décision éclairée. Nous aborderons également la manière dont les offres de cloud computing peuvent être exploitées dans cet espace, ainsi que certaines étapes de base pour commencer à s'engager sur la voie des microservices.
Avantages et inconvénients des microservices
Les microservices présentent des avantages et des inconvénients significatifs. Peser le pour et le contre nous aidera à déterminer si les avantages l'emportent sur les coûts et si votre organisation peut s'accommoder des inconvénients à long terme. Examinons les inconvénients et les avantages, et voyons si les microservices sont la bonne réponse à votre problème.
Inconvénients des microservices
Plusieurs des inconvénients des microservices sont intentionnels. Le désir d' éviter ces inconvénients peut conduire à des problèmes plus importants et parfois à un "microservice-monolithe", subissant le pire des deux approches.
Lorsque vous considérez chacun de ces inconvénients, réfléchissez aux modèles et/ou processus que votre équipe ou votre organisation devra adopter pour s'assurer que vous êtes prêt à les gérer sans retomber dans les vieilles habitudes. Par exemple, des mesures de sécurité renforcées rendent l'accès plus difficile, mais peuvent supprimer le point de défaillance unique dans la protection de vos actifs.
1. LA COMPLEXITÉ STRUCTURELLE DE LA SOLUTION MICROSERVICE AUGMENTE RAPIDEMENT
Dans une architecture de microservices, l'ajout de comportements au système et l'extension des problèmes qu'il résout impliquent l'ajout de structures et de services supplémentaires pour y parvenir.
La maintenance de cette structure devient un espace de problèmes croissant. Une grande partie de cette complexité supplémentaire peut être gérée avec la bonne fondation DevOps et les bons outils d'automatisation. Mais sans eux, cela peut devenir un cauchemar en matière de maintenance.
2. QUAND LE PARTAGE D'INFORMATIONS ET DE DONNÉES ENTRE MICROSERVICES DEVIENT UN PROBLÈME
Lorsque les services ont besoin de données provenant de plusieurs domaines pour accomplir une tâche, nous sommes confrontés à la mise en œuvre de modèles d'intégration (un bon sujet à explorer si l'on décide de mettre en œuvre des microservices).
L'un des schémas d'intégration les plus courants est la double extraction de données ou le stockage en double. Nous finissons par échanger de l'espace de stockage contre une séparation des comportements. Essayer d'éviter cet inconvénient peut créer des problèmes beaucoup plus importants et aboutir à un point de défaillance unique pour l'ensemble du système.
3. LA MODIFICATION D'UN COMPORTEMENT TRANSVERSAL IMPLIQUE PLUSIEURS MICROSERVICES
Lorsque nous traitons de questions transversales telles que la journalisation, l'audit ou la sécurité, nous devons concevoir une solution qui fonctionne sur plusieurs services ou qui reproduit ces comportements par le biais d'un ensemble partagé d'utilitaires. Si nous partageons cet ensemble d'utilitaires, nous pouvons créer des contraintes sur le changement et le déploiement.
Il devient important de créer des utilitaires avec un versioning approprié qui ne couple pas inutilement votre système à d'autres versions (version du framework, par exemple) ou qui ne comporte pas de changements paralysants qui limitent l'adoption.
Avantages des microservices
Les avantages des microservices ne sont pas moins intentionnels dans leur conception que leurs inconvénients.
1. LA SÉPARATION DES PRÉOCCUPATIONS EST STRUCTURELLE
Lors de la construction de systèmes complexes, l'évitement des conséquences involontaires nécessite beaucoup de soin et de diligence. Cela repose souvent sur les connaissances et la discipline de l'équipe de développement du logiciel.
Avec les microservices, une partie de cette complexité est structurelle et peut être limitée. Les contrats d'API peuvent être versionnés et supprimés selon les besoins. Certaines parties du système peuvent être mises à jour plusieurs fois plus rapidement que d'autres. Cette complexité structurelle est également plus facilement automatisée avec les outils DevOps modernes.
2. L'ÉCHELLE EST CIBLÉE
Les systèmes construits avec une architecture de microservices peuvent avoir une échelle ciblée appliquée à certaines fonctions en dimensionnant le matériel pour cet ensemble de services. Cela permet de gérer plus facilement les performances et les pics de demande, souvent de manière automatisée à l'aide de fournisseurs de cloud modernes.
3. LA COMPLEXITÉ PEUT ÊTRE RÉPARTIE ENTRE PLUSIEURS ÉQUIPES
Travailler avec des systèmes monolithiques est difficile, en particulier pour les grands groupes de développement composés de plusieurs équipes. L'architecture des microservices aide à compartimenter quelque peu cette complexité tout en permettant à plusieurs équipes de travailler sur un système à grande échelle avec plus de flexibilité et moins de conflits.
Cela ne veut pas dire qu'ils sont entièrement isolés, mais ils le sont beaucoup plus qu'une base de code unique d'une grande application développée comme un monolithe.
Par où commencer ? Peut-être par le commencement
Lorsque l'on envisage un changement d'architecture, il est important d'examiner les processus de décision et de conception. Si nous abordons un changement d'architecture sans changer notre façon de concevoir, nous recréerons probablement des problèmes pires que ceux que nous connaissons aujourd'hui. Pourquoi des problèmes plus graves ? Parce que nous disposons aujourd'hui de systèmes basés sur ces processus.
En revanche, l'avenir que nous envisageons présentera probablement des conflits entre les principes de conception et les processus mis en œuvre. L'approche de conception sur laquelle nous nous appuyons fortement pour passer aux microservices est la conception pilotée par les domaines (Domain Driven Design).
Si vous n'avez pas encore exploré la conception pilotée par les domaines, jetez un coup d'œil à ce livre d'Eric Evans. Il présente un ensemble de tactiques et d'étapes permettant de progresser. En bref, il s'agit d'une structure de conception qui aide à décomposer de vastes domaines de complexité en domaines plus petits. Cela présente l'avantage de limiter l'étendue de la complexité et de permettre la variation de la conception dans les espaces de problèmes. Lorsque nous séparons les problèmes en domaines d'activité et que nous séparons ensuite les connexions des domaines aux concepts de base, chacun de ces domaines peut être influencé par les autres, mais pas contrôlé.
La similarité de la terminologie et la séparation des responsabilités lors du passage de l'approche de la conception à la mise en œuvre que nous offre la conception pilotée par les domaines nous permettent d'éliminer la complexité de la communication et d'aller rapidement à la racine des problèmes.
Sans cette similitude, les développeurs sont contraints de traduire l'intention dans un autre modèle mental. Cette traduction s'accompagne d'efforts, de confusion et souvent d'une perte de fidélité.
Composants clés des équipes de microservices performantes
Lorsque nous envisageons de passer aux microservices, nous observons certains thèmes communs dans les équipes performantes. Examinons-les maintenant.
1. DE BONS PROCESSUS D'AUTOMATISATION ET DE DÉVELOPPEMENT
Il n'est pas facile de déployer plusieurs services dans plusieurs versions et de s'assurer que la fiabilité n'est pas affectée négativement. Les équipes qui font de cette préoccupation un citoyen de première classe de leur processus de développement ont un taux de réussite nettement plus élevé que la plupart des autres (et pas seulement dans les microservices). Les bases d'un pipeline de construction et de libération dans les environnements de test et de production peuvent faire toute la différence.
2. DES ÉQUIPES DE DÉVELOPPEMENT DISCIPLINÉES
La collaboration, la conception, les tests et, en fin de compte, le succès du produit peuvent être résumés par la discipline de l'équipe de développement. Il y aura une tonne de raccourcis en cours de route qui peuvent dégrader la valeur du système et conduire à une dette technique à long terme. Si l'équipe ne peut pas voir et éviter ces raccourcis, elle aura du mal. Cela semble simple, mais lorsque le "chemin le plus court" prend 2 heures et que le "chemin le plus juste" en prend 6, même un Product Owner poussera pour le chemin le plus court.
La plupart du temps, il s'agit d'un compromis qui n'est pas compris et qui entraîne un important travail de reprise à l'avenir. La discipline en matière de conception et de mise en œuvre au sein d'une équipe est rare, mais lorsqu'elle est appliquée correctement, elle permet d'obtenir des résultats étonnants.
3. TESTER, TESTER ET ENCORE TESTER
La décomposition de la complexité ne supprime pas la complexité, et nous devons ajouter plus de tests que ce que la plupart des équipes aiment faire. Les définitions que les tests véhiculent permettent souvent de détecter des erreurs avant même qu'ils ne soient exécutés. Les bords et les cas limites d'un service deviennent les contraintes des services avec lesquels il interagit. Une suite de tests solide, bien entretenue et en pleine croissance résoudra de nombreux problèmes avant qu'ils ne surviennent.
4. DE BONS MODÈLES DE MESSAGERIE ET D'INTÉGRATION
Les systèmes distribués sont difficiles à construire et à comprendre en l'absence de modèles clairs. C'est l'un des principaux facteurs de réussite des équipes. Vous pouvez prendre un bon départ avec le bon cadre et quelques connaissances. Jetez un coup d'œil à MassTransit et Modèles d'intégration d'entreprise. Le cadre et le livre vous aideront à démarrer de la bonne manière.
Si vous ressentez la douleur d'un changement d'architecture qui a mal tourné ou si vous voulez éviter cette douleur, n'hésitez pas à nous appeler. Nous serions ravis de partager nos expériences avec vous.
