Close

Microservices et architecture de microservices (MSA)

Découvrez les avantages et les inconvénients des microservices et en quoi ils diffèrent des monolithes.

Qu'est-ce que les microservices ?

Le terme « microservices » est un qualificatif moderne utilisé pour décrire un modèle traditionnel de « séparation des préoccupations » au sein d'un projet distribué en réseau. Les microservices sont une idée qui suit une vieille philosophie fondamentale d'Unix de « petits outils significatifs ».Ces deux concepts s'appuient sur un autre modèle fondamental de « composition » informatique, ce qui signifie que les systèmes complexes sont la somme de composants de niveau inférieur.

Articles sur les microservices

[SUITE]

La composition se produit à travers toutes les couches d'un projet logiciel. Au niveau le plus bas, le « niveau unitaire », les fonctions de code indépendantes et individuelles interagissent les unes avec les autres via une interface partagée pour créer des collections ou des « bibliothèques » de code. Au niveau de l'interpréteur de commandes du système d'exploitation, les commandes shell peuvent être composées pour créer un pipeline de fonctionnalités de niveau supérieur. Les microservices sont un niveau de composition qui intervient entre les services web. Un microservice est un service web responsable d'un élément de la logique de domaine. Les microservices interagissent les uns avec les autres via des protocoles réseau simples comme REST afin de réaliser des actions, mais ils n'ont aucune connaissance de la façon dont les autres services fonctionnent en interne. Cette interaction harmonieuse entre les microservices constitue une architecture de microservices.

L'architecture de microservices ou MSA attire beaucoup d'attention, car les équipes de développement logiciel recherchent de nouvelles façons d'améliorer leurs workflows de livraison. Amazon, Netflix et eBay font partie des entreprises qui optent ouvertement pour cette méthode de développement de logiciels, et elles ont apporté leur contribution à la communauté en publiant leur propre expérience et en développant des outils qui peuvent aider les autres à l'adopter.

Le principe directeur des microservices consiste à développer des applications en divisant les composants métier en services susceptibles d'être déployés et exploités indépendamment les uns des autres.

Diagramme montrant comment un grand cube peut être divisé en plusieurs petits cubes.

Les développeurs peuvent ensuite s'organiser en équipes plus petites spécialisées dans différents services, avec différents stacks et déploiements découplés. Cette séparation des préoccupations et ce découplement des fonctions indépendantes, permet de rationaliser les pratiques de développement logiciel Agile comme la livraison et l'intégration continues.

Architecture orientée service (SOA) et microservices

L'architecture orientée service et les microservices sont deux types d'architectures de service web de niveau supérieur. Les microservices peuvent être considérés comme une version allégée de l'architecture orientée service. La distinction entre les deux types d'architecture est la classification bureaucratique des types de services. L'architecture orientée service dispose de quatre types de services de base : les services Business, Entreprise, Application et Infrastructure. Ces types définissent la responsabilité spécifique du domaine connexe des services sous-jacents. En comparaison, les microservices n'ont que deux types de services : Fonctionnel et Infrastructure.

Les deux architectures partagent le même ensemble de normes à différentes couches d'une entreprise. L'existence de MSA découle de la réussite du modèle d'architecture orientée service. Par conséquent, le modèle MSA est un sous-ensemble de l'architecture orientée service. Ici, l'accent est mis sur l'autonomie d'exécution de chaque service.

Application monolithe et microservices

Diagramme montrant la différence entre des monolithes et des microservices dans la livraison continue.

Les microservices dissocient les principales préoccupations spécifiques au domaine d'activité en bases de code indépendantes et distinctes. Une architecture d'application monolithique peut être considérée comme l'inverse des microservices. Un monolithe est une base de code qui associe toutes les préoccupations de l'entreprise. Les monolithes peuvent être pratiques au début de la vie d'un projet pour faciliter la charge cognitive liée à la gestion du code et au déploiement. Cela permet de livrer tout le contenu du monolithe à la fois.

De nombreux projets commencent d'abord en tant que monolithe, puis évoluent vers une architecture de microservices. Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées à un monolithe, avoir de nombreux développeurs travaillant sur une base de code unique peut s'avérer laborieux. Les conflits de code se font plus fréquents, et le risque de mises à jour d'une fonctionnalité introduisant des bugs dans une fonctionnalité non liée augmente. L'apparition de ces schémas indésirables peut être le signe qu'il est temps d'envisager une migration vers les microservices.

Fonctionnement de l'architecture de microservices

Prenons l'exemple d'un hypothétique projet de logiciel de commerce électronique. Il existe des fonctionnalités métier spécifiques au domaine clairement définies. Les sites de commerce électronique ont un système d'authentification pour la connexion et la déconnexion des utilisateurs, un panier pour conserver une liste des produits qui intéressent l'utilisateur et un système de facturation qui permet aux utilisateurs de payer leurs achats.

Dans une architecture de microservices, ces exemples de domaines métier seraient des services indépendants. Prenez le système de facturation comme exemple spécifique. En fonction du nombre d'employés de l'entreprise, il peut y avoir une « équipe de facturation » dédiée responsable du développement et de l'assurance qualité de ce microservice de facturation. Le microservice de facturation aurait son propre calendrier de publication et ses propres playbooks de déploiement. Le service de facturation fournirait une API documentée et versionnée afin que d'autres services puissent communiquer et utiliser ses fonctionnalités.

Avantages et inconvénients des microservices

Avantage : évolutivité horizontale

Les microservices sont distribués par design et peuvent être déployés dans des clusters. Cela permet une mise à l'échelle horizontale dynamique à travers les limites de service. Si un microservice réduit sa capacité de charge, de nouvelles instances de ce service peuvent être rapidement déployées sur le cluster attenant afin de réduire la pression.

Avantage : exécution de l'équipe indépendante

Les équipes propriétaires des microservices peuvent fonctionner indépendamment des autres équipes de fonctionnalité au sein de l'organisation. Il est ainsi possible d'exécuter et de livrer plus rapidement de nouvelles fonctionnalités.

Avantage : attention accrue à la qualité

La séparation des préoccupations métier en microservices indépendants garantit que l'équipe de service propriétaire de ce service se concentre entièrement sur la qualité du livrable.

Inconvénient : coûts d'infrastructure exponentiels

Chaque nouveau microservice qu'une organisation ajoute à son déploiement en production entraîne son propre coût en termes de suite de tests, de playbooks de déploiement, d'infrastructure d'hébergement, d'outils de surveillance, etc.

Inconvénient : frais organisationnels supplémentaires

Un niveau supplémentaire de communication et de collaboration est nécessaire à la coordination des mises à jour et des interfaces entre les équipes d'architecture de microservices.

Inconvénient : complexité de l'environnement de développement

Lorsqu'un projet est divisé en plusieurs microservices, il devient plus difficile de reproduire l'architecture distribuée pendant la configuration du développement local.

L'avenir des microservices

La conteneurisation et le déploiement de conteneurs est un nouveau modèle d'infrastructure distribuée. Des outils comme Docker et Kubernetes sont utilisés pour intégrer un service dans un « conteneur » complet qui peut être rapidement déployé et supprimé. Ces nouveaux outils d'infrastructure sont complémentaires à l'architecture de microservices. Les microservices peuvent être conteneurisés, puis facilement déployés et gérés à l'aide d'un système de gestion de conteneurs.

L'adoption des microservices doit être considérée comme un parcours plutôt que comme un objectif immédiat pour une équipe. Commencez petit pour comprendre les exigences techniques d'un système distribué, comment gérer les échecs normaux et mettre à l'échelle des composants individuels. Ensuite, vous pouvez progressivement extraire de plus en plus de services à mesure que vous acquérez de l'expérience et des connaissances.

L'architecture des microservices est encore assez récente, mais c'est un moyen prometteur de développer des applications, et elle vaut vraiment la peine d'être étudiée. Rappelez-vous toutefois qu'elle pourrait ne pas (encore) convenir à votre équipe.

Claire Maynard
Claire Maynard

Claire Maynard est une experte du marketing chez Atlassian. Elle s'est intéressée à la croissance, à la performance et au marketing produit. Elle est actuellement responsable de la marque, du contenu et de la stratégie de go-to-market pour Confluence Cloud. Dans son temps libre, elle aime surfer, courir, essayer de nouveaux restaurants à San Francisco ou dans d'autres villes à travers le monde.