Les microservices seront-ils votre prochaine architecture logicielle ?

Quasiment tous les systèmes informatiques s’appuient sur des ressources partagées pour exécuter des tâches multiples, et l'une des questions de la programmation est de savoir dans quelle mesure les bits de code qui exécutent ces tâches doivent être liés les uns aux autres. Le concept de microservice, cette petite fonctionnalité discrète qui interagit avec d'autres microservices pour créer un système plus grand, est l’une des réponses les plus en vogue à cette question. Certes, l'idée de s’appuyer sur des composants discrets n’est pas nouvelle. Mais le mode d’implémentation des microservices fait qu’ils sont bien adaptés aux applications modernes basées sur le cloud. Les microservices s'inscrivent également dans la philosophie devops, qui encourage le déploiement rapide et continu de nouvelles fonctionnalités.

Définition des microservices

Dans microservices, le préfixe « micro » implique qu'il s'agit de petites applications. C'est parfois vrai, mais ce qui importe, c'est que les microservices aient juste la taille nécessaire pour exécuter une tâche particulière ou résoudre un problème particulier. De plus, ce problème doit être conceptuel et non technique. Comme l’explique Microsoft, « les microservices devraient être conçus en fonction des capacités de l'entreprise, et non pas autour de couches horizontales comme l'accès aux données ou la messagerie ». Les microservices communiquent avec d'autres microservices et des utilisateurs externes via des API relativement stables pour créer une application plus large. Cela permet de modifier la fonctionnalité interne d'un microservice individuel ou de la mettre entièrement à niveau sans affecter le reste du système. Cela dépend aussi du mode opérationnel choisi par les magasins devops : si les fonctions spécifiques d'une plus grande application sont segmentées en éléments de code discrets et indépendants, il est plus facile de coller au principe CI/CD (intégration continue et livraison continue) cher au devops. De plus, des API bien définies facilitent le test automatique des microservices.

Architecture de microservices vs. architecture monolithique

Quand on parle de microservices, on emploie souvent le terme « d’architecture microservices ». Cette expression englobe non seulement les microservices eux-mêmes, mais également les composants de gestion et de découverte de services, ainsi qu'une passerelle API qui gère la communication entre les microservices et le monde extérieur. Le rétronyme « d’application monolithique » est à l’opposé des microservices. Il désigne une application où l’ensemble du code est logé dans un gros fichier exécutable binaire. Une application monolithique est de plus en plus difficile à dimensionner et à améliorer. Mais, comme il s'agit d'une application cohérente en un seul morceau, elle n’a pas tellement besoin d’être gérée, comme c’est le cas d'une architecture de microservices.

Contexte délimité et microservice

Revenons un instant au principe précédent selon lequel un microservice ne devrait avoir qu’une fonction particulière, plus facile à énoncer qu’à appliquer. Car dans la pratique, la fonctionnalité est souvent imbriquée à d’autres fonctionnalités et il est plus difficile qu'il n'y paraît de les séparer. Les approches théoriques de l'analyse de domaine et de design axé sur le domaine peuvent faciliter le découpage d’un processus global en problèmes individuels que pourra résoudre un microservice. Microsoft détaille de manière claire ce processus dans plusieurs billets de blog : l’objectif est de créer un modèle abstrait du domaine d'activité, et de découvrir le contexte délimité regroupant les fonctionnalités qui interagissent avec le monde extérieur de manière spécifique. Par exemple, il peut y avoir avoir un contexte délimité pour la livraison et un autre pour les comptes. Évidemment, dans le monde réel, un objet physique aurait à la fois un prix et une destination. Mais les contextes délimités représentent les manières spécifiques dont votre application pense et interagit avec ces objets. Normalement, chaque microservice devrait entièrement exister dans un contexte délimité unique, même si certains contextes délimités peuvent englober plus d'un microservice.

Différences entre microservices, architecture orientée services et services web

À ce stade, si vous êtes un professionnel IT et que vous travaillez dans ce secteur depuis un certain temps, vous pourriez penser qu’il y a là beaucoup de choses familières. Les petits programmes individuels qui travaillent ensemble peuvent vous rappeler à la fois le SOA (architecture orientée services) et les services Web, deux termes très en vogues dans les années 2000 du Web 2.0. Si, dans un sens, il n'y a vraiment rien de nouveau sous le soleil, il y a des distinctions importantes entre ces concepts et les microservices. Le site Datamation a expliqué en long et en large les différences entre ces concepts, dont voici un résumé :

• dans une architecture orientée services, les composants individuels sont assez étroitement couplés, partagent souvent des ressources comme le stockage et communiquent via un logiciel spécialisé appelé bus de stockage d'entreprise. Les microservices sont plus indépendants, partagent moins de ressources et communiquent via des protocoles plus légers. Il convient de noter que les microservices sont issus des architectures orientées services (SOA) et sont parfois considérés comme une sorte de SOA, ou un successeur du concept

• un service Web désigne un ensemble de fonctionnalités auxquelles d'autres applications peuvent accéder via le Web. L'exemple le plus courant est probablement celui de Google Maps : le site Web d'un restaurant peut intégrer le service Google Maps pour aider ses clients à le localiser. C’est une connexion beaucoup moins stricte que celle que l’on trouve dans une architecture de microservices.

Communication des microservices

On entend souvent dire à propos des architectures de microservices qu'elles devraient être dotées de « points d'extrémité intelligents et de transmissions muettes ». En d'autres termes, les microservices devraient utiliser des méthodes de communication de base et bien établies plutôt qu'une intégration complexe et étroite. Comme mentionné précédemment, c’est une autre différence entre les microservices et l'architecture SOA. En général, la communication entre les microservices devrait être asynchrone, dans le sens où les threads de code ne sont pas bloqués en attendant les réponses. (Il est toujours possible d'utiliser des protocoles de communications synchrones comme les HTTP, même si les protocoles asynchrones comme l’AMQP (Advanced Message Queuing Protocol) sont également courants dans les architectures microservices). Ce couplage plus souple fait que l’architecture de microservices est plus flexible en cas de défaillance d’un composant individuel ou de portions de réseau, ce qui est un avantage clé.

Microservices, Java, Spring Boot et Spring Cloud

Certains des premiers travaux dans le domaine des microservices ont été menés dans la communauté Java, et c’est Martin Fowler qui en a été l'un des premiers promoteurs. L'une des premières présentations les plus importantes sur le sujet, a eu lieu lors d'une conférence Java organisée en Pologne en 2012. Intitulée « Microservices - Java, the Unix Way », la présentation recommandait d'appliquer au développement Java les principes - « Écrire des programmes qui font une chose et qui la font bien. Écrire des programmes pour travailler ensemble » - qui avaient guidé le développement des premières applications Unix dans les années 1970. La conséquence de cette histoire, c’est que de nombreux frameworks Java permettent de construire des microservices. Spécialement conçu pour les microservices, Spring Boot est l’un des framework les plus populaires. Il a été étendu par Spring Cloud, qui, comme son nom l'indique, permet de déployer ces services dans le cloud. Pivotal Software, le développeur de Spring, a conçu un très bon tutoriel pour commencer à développer des microservices en utilisant ces frameworks.

Microservices et conteneurs : Docker, Kubernetes, et autres

La technologie sous-jacente qui est allée le plus loin dans l'intégration des microservices est celle des conteneurs. Un conteneur est équivalent à une instance de machine virtuelle (VM), mais au lieu d'inclure un système d'exploitation autonome complet, il créé un espace utilisateur isolé qui utilise le noyau du système d'exploitation hôte tout en conservant le code à l'intérieur de celui-ci. Les conteneurs sont beaucoup plus petits que les instances VM et sont déployables rapidement et facilement, en local ou dans le cloud, et peuvent être activés ou désactivés en fonction de la demande et des ressources disponibles. L'attrait des conteneurs pour les microservices devrait être évident : chaque microservice individuel peut fonctionner dans son propre conteneur, ce qui réduit considérablement le casse-tête de la gestion des services. La plupart des implémentations de conteneurs disposent d'outils d'orchestration complémentaires qui automatisent le déploiement, la gestion, la mise à l'échelle, la mise en réseau et la disponibilité des applications basées sur les conteneurs. C'est la combinaison de petits microservices faciles à construire et de conteneurs faciles à déployer qui rend la philosophie devops possible. Il existe plusieurs implémentations du concept de conteneur, mais Docker est de loin le plus populaire, couplé généralement avec la plate-forme d'orchestration Kubernetes.

Même s’il est populaire, le framework Spring est lié à la plate-forme Java. Les systèmes à base de conteneurs, par contre, sont polyglottes : tout langage de programmation supporté par le système d'exploitation peut être exécuté dans un conteneur, ce qui donne plus de flexibilité aux programmeurs. En effet, l'un des gros avantages des microservices, c’est que chaque service individuel peut être écrit dans la langue la plus appropriée ou avec laquelle les développeurs sont le plus à l'aise. En effet, un service peut être entièrement reconstruit dans un nouveau langage sans affecter le système dans son ensemble, tant que ses API restent stables. Un article publié par DZone détaille les avantages et les inconvénients de Spring Cloud par rapport à Kubernetes pour les microservices.

Modèles de design pour les microservices

Quel que soit le langage que vous utilisez pour développer des microservices, vous serez confronté à des problèmes que d'autres développeurs ont déjà rencontrés. Les modèles de design apportent des solutions abstraites et formalisées à des problèmes informatiques récurrents, et un certain nombre d'entre eux sont spécifiquement destinés aux microservices. La très bonne liste établie par Devopedia inclut :

• Service Registry : permet de connecter les clients aux instances de microservices disponibles.

• Circuit Breaker : évite que des services en panne ne soient appelés de façon répétée.

• Fallback : offre une alternative à un service défaillant

• Sidecar : fournit un service auxiliaire au conteneur principal, pour le login, la synchronisation des services ou la surveillance, par exemple.

• Adapter : standardise ou normalise l'interface entre le conteneur principal et le monde extérieur.

• Ambassador : connecte le conteneur principal au monde extérieur. Il permet par exemple de créer des proxies de connexions localhost pour établir des connexions extérieures.

Microservices et cloud : AWS et Azure

Comme indiqué plus haut, l'un des avantages des conteneurs, c’est qu'ils peuvent être facilement déployés dans le cloud, où ils ont accès à des ressources de calcul flexibles, ce qui permet d’optimiser l'efficacité de votre application. Comme vous pouvez l'imaginer, les principaux fournisseurs de cloud public veulent tous que vous utilisiez leurs plates-formes pour exécuter vos applications basées sur des microservices. Pour plus d'informations, consultez les offres d'Amazon, de Microsoft et de Google.