Que sont les microservices? Votre prochaine architecture logicielle

Presque chaque système informatique exécute plusieurs tâches en utilisant des ressources partagées, et l'une des questions de la programmation informatique est de savoir dans quelle mesure les bits de code qui exécutent ces tâches doivent être liés les uns aux autres. Une réponse de plus en plus populaire est le concept de microservice - un petit bloc discret de fonctionnalités qui interagit avec d'autres microservices pour créer un système plus grand.

Bien que l'idée de base d'avoir de tels composants discrets ne soit pas nouvelle, la façon dont les microservices sont mis en œuvre en fait une base naturelle pour les deux 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.

Que sont les microservices?

Le «micro» dans les microservices implique qu'il s'agit de petites applications. C'est parfois vrai, mais une meilleure façon de penser à eux est qu'ils devraient être aussi grands que nécessaire pour faire une chose spécifique ou résoudre un problème particulier. Ce problème doit être conceptuel et non technique. Comme le dit Microsoft, «les microservices doivent être conçus autour des capacités de l'entreprise, et non sur des couches horizontales telles que l'accès aux données ou la messagerie.» Ils communiquent avec d'autres microservices et des utilisateurs externes via des API relativement stables pour créer une application plus grande.

Ainsi, la fonctionnalité interne d'un microservice individuel peut être modifiée ou radicalement mise à niveau sans affecter le reste du système. Cela à son tour est lié à la manière dont les boutiques de développement cherchent à fonctionner: si les fonctions spécifiques d'une application plus grande sont segmentées en morceaux de code discrets et fonctionnant indépendamment, il est plus facile de vivre le mantra devops de CI / CD (intégration continue et livraison continue) . De plus, des API bien définies facilitent le test automatique des microservices.

Architecture de microservices vs architecture monolithique

Vous entendrez souvent parler de microservices en termes d '«architecture de microservices ». Cette phrase englobe non seulement les microservices eux-mêmes, mais également des 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.

Une «application monolithique» est l'opposé de ce que sont les microservices. C'est un rétronyme pour une application où tout le code est dans un gros fichier exécutable binaire. Comme l'explique TechTarget, une application monolithique est plus difficile à mettre à l'échelle et plus difficile à améliorer. Mais comme il est construit comme une application cohérente unique, il ne nécessite pas autant de gestion qu'une architecture de microservices.

Concepts limités: comment définir un microservice

Revenons un instant à notre commandement précédent selon lequel les microservices devraient faire une chose spécifique. C'est facile à dire, mais dans la pratique, les fonctionnalités sont souvent entremêlées et les divisions de dessin sont plus difficiles qu'il n'y paraît. L'analyse de domaine et la conception axée sur le domaine sont les approches théoriques qui vous aideront à séparer votre tâche globale en problèmes individuels qu'un microservice peut résoudre. Dans ce processus, décrit dans une série éclairante d'articles de blog de Microsoft, vous créez un modèle abstrait de votre domaine d'entreprise et, ce faisant, vous découvrez les contextes délimités , qui regroupent les fonctionnalités qui interagissent avec le monde d'une manière spécifique.

Par exemple, vous pouvez avoir un contexte limité pour l'expédition et un autre pour les comptes. Un objet physique du monde réel aurait à la fois un prix et un endroit où il doit aller, bien sûr, mais les contextes délimités représentent des façons spécifiques dont votre application pense et interagit avec ces objets. Chaque microservice doit exister entièrement dans un seul contexte limité, bien que certains contextes limités puissent englober plus d'un microservice.

Microservices vs architecture orientée services vs services Web

À ce stade, si vous êtes un professionnel de l'informatique qui travaille dans l'industrie depuis un certain temps, vous pourriez penser que cela vous semble familier. L'idée de petits programmes individuels travaillant ensemble pourrait vous rappeler à la fois la SOA (architecture orientée services) et les services Web , deux mots à la mode des jours enivrants du Web 2.0 des années 2000. Bien que dans un sens il n'y ait vraiment rien de nouveau sous le soleil, il existe des distinctions importantes entre ces concepts et les microservices. Datamation a une bonne ventilation des différences, mais voici une version courte:

  • Dans une architecture orientée services, les composants individuels sont relativement étroitement couplés, partageant souvent des actifs tels que le stockage, et ils 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 est à noter que les microservices sont issus du milieu SOA et sont parfois considérés comme une sorte de SOA, ou le successeur du concept.
  • Un service Web est un ensemble de fonctionnalités accessibles au public auquel d'autres applications peuvent accéder via le Web; L'exemple le plus répandu est probablement Google Maps, que le site Web d'un restaurant pourrait intégrer pour fournir des directions aux clients. Il s'agit d'une connexion beaucoup plus lâche que celle que vous verriez dans une architecture de microservices.

Communication microservices

Un slogan que vous entendrez souvent utilisé à propos des architectures de microservices est qu'elles devraient comporter des «points de terminaison intelligents et des tuyaux stupides». En d'autres termes, les microservices devraient viser à utiliser des méthodes de communication de base et bien établies plutôt qu'une intégration complexe et étroite. Comme indiqué, c'est une autre chose qui distingue les microservices de SOA.

En général, la communication entre les microservices doit être asynchrone , dans le sens où les threads de code ne sont pas bloqués en attente de réponses. (Il est toujours bon d'utiliser des protocoles de communication synchrones tels que HTTP, bien que les protocoles asynchrones tels que AMQP (Advanced Message Queuing Protocol) soient également courants dans les architectures de microservices.) Ce type de couplage lâche rend une architecture de microservices plus flexible face à l'échec. des composants individuels ou des parties du réseau, ce qui est un avantage clé.

Microservices, Java et Spring Boot et Spring Cloud

Certains des premiers travaux sur les microservices ont vu le jour dans la communauté Java; Martin Fowler a été l'un des premiers promoteurs. Une conférence Java de 2012 en Pologne a présenté l'une des premières présentations les plus importantes sur le sujet, intitulée «Micro services - Java, à la manière d'Unix». programmes qui font une chose et la font bien. Ecrire des programmes pour travailler ensemble ») pour le développement Java.

À la suite de cet historique, de nombreux frameworks Java vous permettent de créer des microservices. L'un des plus populaires est Spring Boot, qui est spécialement conçu pour les microservices; Boot est étendu par Spring Cloud, qui, comme son nom l'indique, vous permet également de déployer ces services sur le cloud. Pivotal Software, le développeur de Spring, propose un bon tutoriel sur la mise en route du développement de microservices à l'aide de ces frameworks.

Microservices et conteneurs: Docker, Kubernetes et au-delà

La technologie sous-jacente qui est allée le plus loin dans l'intégration des microservices est celle des conteneurs .  Un conteneur est similaire à une instance de VM, mais au lieu d'inclure un système d'exploitation autonome complet, un conteneur n'est qu'un espace utilisateur isolé qui utilise le noyau du système d'exploitation hôte, mais qui maintient le code en cours d'exécution à l'intérieur de celui-ci. Les conteneurs sont beaucoup plus petits que les instances de VM et sont faciles à déployer rapidement, localement ou dans le cloud, et peuvent être augmentés ou réduits pour répondre à la demande et aux ressources disponibles.

L'attrait des conteneurs pour les microservices doit être évident: chaque microservice individuel peut s'exécuter dans son propre conteneur, ce qui réduit considérablement la charge de 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 des conteneurs. C'est la combinaison de petits microservices faciles à créer et de conteneurs faciles à déployer qui rend possible la philosophie devops. Il existe plusieurs implémentations du concept de conteneur, mais la plus populaire est de loin Docker, qui est généralement associée à Kubernetes en tant que plate-forme d'orchestration.

Spring, bien que populaire, est lié à la plate-forme Java. Les systèmes basés sur des conteneurs, par contre, sont polyglottes: tout langage de programmation pris en charge par le système d'exploitation peut s'exécuter dans un conteneur, ce qui donne plus de flexibilité aux programmeurs. En effet, un gros avantage des microservices est que chaque service individuel peut être écrit dans le langage le plus logique ou avec lequel les développeurs sont le plus à l'aise. En effet, un service pourrait être entièrement reconstruit dans un nouveau langage sans affecter le système dans son ensemble, tant que ses API restent stables. DZone a publié un article sur les avantages et les inconvénients de Spring Cloud par rapport à Kubernetes pour les microservices. 

Modèles de conception de microservices

Quel que soit le langage que vous utilisez pour développer des microservices, vous rencontrerez des problèmes que d'autres développeurs ont déjà rencontrés. Les modèles de conception sont des solutions formalisées et abstraites à des problèmes récurrents en informatique, et un certain nombre d'entre eux sont spécifiquement destinés aux microservices. Devopedia a une excellente liste, qui comprend:

  • Service Registry: pour connecter les clients aux instances disponibles de microservices
  • Disjoncteur: pour empêcher les services défaillants d'être appelés à plusieurs reprises
  • Fallback: pour fournir une alternative à un service défaillant
  • Sidecar: pour fournir un service auxiliaire au conteneur principal, comme pour la journalisation, la synchronisation des services ou la surveillance
  • Adaptateur: pour standardiser ou normaliser l'interface entre le conteneur principal et le monde extérieur
  • Ambassador: pour connecter le conteneur principal au monde extérieur, par exemple pour le proxy des connexions localhost vers des connexions extérieures

Microservices et cloud : AWS et Azure

Comme indiqué ci-dessus, l'un des avantages de l'utilisation de conteneurs est qu'ils peuvent être facilement déployés dans le cloud, où des ressources de calcul flexibles sont disponibles afin que vous puissiez maximiser l'efficacité de votre application. Comme vous pouvez l'imaginer, les principaux fournisseurs de cloud public sont tous impatients que vous utilisiez leurs plates-formes pour exécuter vos applications basées sur des microservices. Pour plus d'informations, consultez les ressources d'Amazon, Microsoft et Google.