Que sont les microservices ?
Aujourd’hui, le cloud régit le développement d’applications et la gestion des systèmes informatiques. Les applications cloud modernes doivent être rapides, agiles et extrêmement scalables et fiables.
L’utilisation de conteneurs peut vous aider à déployer des applications qui répondent à tous ces impératifs. Toutefois, placer une application dans un conteneur sans suivre de modèle de conception stratégique revient à conduire en espérant trouver un itinéraire vers une nouvelle ville sans utiliser de carte ou de GPS. Vous pouvez vous retrouver à destination, mais vous n’aurez probablement pas pris le meilleur itinéraire.
Une architecture de microservices est utile dans ce scénario. Les microservices vous offrent une approche du développement et du déploiement de logiciels parfaitement adaptée aux impératifs d’agilité, de scalabilité et de fiabilité des applications cloud modernes.
Qu’est-ce qu’une architecture de microservices ?
Dans une architecture de microservices, une application de grande envergure est divisée en un ensemble de services plus petits. Chaque service s’exécute dans son propre processus et communique avec d’autres processus à l’aide de protocoles tels que HTTP/HTTPS, WebSocket ou AMQP (Advanced Message Queuing Protocol). Chaque microservice implémente un domaine ou une fonctionnalité métier spécifique de bout en bout dans une certaine limite de contexte. Chaque microservice doit être développé de manière autonome et doit être déployable indépendamment. Enfin, chaque microservice doit avoir son modèle de données de domaine et sa logique de domaine associés. Les microservices peuvent être basés sur différentes technologies de stockage de données (SQL, NoSQL) et différents langages de programmation.
Voici quelques-unes des principales caractéristiques des microservices :
- Ils sont petits, indépendants et faiblement couplés.
- Chaque microservice dispose d’un codebase distinct qui peut être géré par une petite équipe de développement.
- Ils sont déployés de manière indépendante. Une équipe peut mettre à jour un microservice existant sans avoir à regénérer et redéployer l’application tout entière.
- Ils conservent leurs données ou l’état externe dans leurs bases de données respectives. Contrairement à une architecture monolithique, les microservices ne partagent pas de bases de données.
- Ils communiquent entre eux à l’aide d’API bien définies. Les détails de l’implémentation interne de chaque service sont cachés aux autres services.
- Ils prennent en charge la programmation polyglotte. Par exemple, les microservices qui composent une application web n’ont pas besoin de partager une pile technologique, des bibliothèques ou des infrastructures.
Pourquoi développer à l’aide d’une architecture de microservices ?
Les microservices encapsulent généralement des fonctionnalités plus simples basées sur les besoins du client. Celles-ci peuvent faire l’objet d’un scale-out ou d’un scale-in de votre part. Vous pouvez les tester, les déployer et les gérer de manière indépendante. Une approche basée sur les microservices offre un avantage important : les équipes sont davantage guidées par les scénarios client que par l’utilisation d’une technologie spécifique. Chaque petite équipe de développement développe un microservice basé sur un scénario client. L’équipe choisit les technologies qu’elle utilise.
Les microservices offrent une agilité sur le long terme. Les microservices garantissent une maintenabilité dans les systèmes complexes, de grande envergure et hautement scalables en vous permettant de créer des applications basées sur de nombreux services qui peuvent être déployés indépendamment, chacun ayant des cycles de vie précis et autonomes.
Un autre avantage est que les microservices peuvent subir un scale out de façon indépendante. Au lieu d’avoir une seule application monolithique dont vous devez effectuer le scale-out sous forme d’unité, vous pouvez effectuer un scale-out de microservices spécifiques. Vous pouvez mettre à l’échelle uniquement la zone fonctionnelle qui nécessite le plus de puissance de traitement ou de bande passante réseau pour la prise en charge de la demande, au lieu d’effectuer un scale-out d’autres zones de l’application qui n’ont pas besoin d’être mises à l’échelle. Cela signifie des frais réduits, car vous avez besoin de moins de matériel.
L’approche des microservices favorise les changements agiles et l’itération rapide de chaque microservice, car vous pouvez changer de petites zones ciblées d’applications complexes, de grande envergure et scalables.
Le fait d’architecturer des applications basées sur des microservices à granularité fine permet des pratiques d’intégration continue et de livraison continue. Il accélère également l’ajout de nouvelles fonctions dans l’application. Vous pouvez exécuter et tester des microservices de manière isolée, et les faire évoluer de manière autonome tout en conservant des contrats clairs entre les services. Tant que vous ne changez pas les contrats ou les interfaces, vous pouvez changer l’implémentation interne de n’importe quel microservice ou ajouter de nouvelles fonctionnalités sans perturber le fonctionnement des autres microservices.
Quel est le rôle des conteneurs ?
La mise en conteneur est une approche de développement de logiciels qui consiste à empaqueter une application ou un service, ses dépendances et sa configuration (extraits sous forme de fichiers manifeste de déploiement) sous forme d’image de conteneur. Vous pouvez tester l’application conteneurisée en tant qu’unité, et la déployer en tant qu’instance d’image conteneur sur le système d’exploitation hôte.
Tout comme les conteneurs d’expédition qui permettent de transporter des marchandises de toutes sortes par bateau, train ou camion, les conteneurs logiciels se comportent comme une unité standard de déploiement de logiciels, qui peut contenir du code et des dépendances de différentes natures. Les développeurs et les professionnels de l’informatique peuvent utiliser les logiciels conteneurisés pour déployer du code et des dépendances dans différents environnements avec peu ou pas de modifications.
La conteneurisation d’une application est un excellent moyen d’implémenter le modèle d’architecture des microservices. Les avantages liés à l’utilisation de conteneurs s’alignent presque exactement sur ceux liés à l’utilisation d’une architecture de microservices.
Remarque
La conteneurisation d’une application n’est pas la seule façon de déployer des microservices. Vous pouvez déployer des microservices en tant que services individuels dans Azure App Service, sur des machines virtuelles ou par d’autres moyens. Dans le reste de ce module, nous allons utiliser des conteneurs en tant qu’outil de déploiement de nos microservices.
L’autre avantage de la mise en conteneur est l’extensibilité. Vous pouvez rapidement effectuer un scale-out en créant des conteneurs à utiliser pour les tâches à court terme. Du point de vue de l’application, instancier une image (c.-à-d., créer un conteneur) revient à instancier un processus comme un service ou une application web.
Pour résumer, les conteneurs offrent les avantages de l’isolation, de la portabilité, de l’agilité, de l’extensibilité et du contrôle dans l’ensemble du flux de travail du cycle de vie de l’application.
Les microservices que vous générez dans ce module s’exécutent dans un conteneur Docker, publié à l’aide de l’interface CLI .NET.
Publication de conteneur. NET du Kit de développement logiciel (SDK)
Dans .NET 7, le SDK .NET a acquis la capacité de créer des images conteneur via la commande dotnet publish. Les outils pour ce faire effectuent des inférences en fonction des propriétés de votre projet et de ses sorties. .NET crée ensuite la même image qu’un Dockerfile créerait. Il suffit d’un minimum de deux commandes pour créer une nouvelle application et la publier sous forme d’image :
dotnet new webapi
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release
Les commandes CLI .NET précédentes créent une nouvelle API web et publient l’application en tant que conteneur :
- Cibler Linux comme système d’exploitation (--os linux).
- Spécification d’une architecture x64 (--arch x64).
- Utilisation de la configuration de mise en production (-c Release).
Vous pouvez contrôler de nombreux aspects du conteneur généré via les propriétés MSBuild. En général, si vous pouvez utiliser une commande dans un Dockerfile pour définir une configuration, vous pouvez en faire de même via MSBuild.
Pourquoi créer des microservices dans .NET ?
Depuis .NET Core jusqu’aux itérations actuelles, .NET est conçu pour être natif Cloud en priorité. Il est multiplateforme. Ainsi, votre image Docker peut être basée sur une saveur de Linux, et permettre l’exécution de votre code .NET. Microsoft a déjà créé des images .NET pour Docker. De plus, .NET est extrêmement rapide. Le serveur web ASP.NET Kestrel surpasse régulièrement les autres serveurs web.
Docker
Docker est une plateforme open source qui vous permet d’automatiser le déploiement d’applications en tant que conteneurs portables et autonomes pouvant s’exécuter dans le cloud ou en local. Docker est également l’entreprise qui promeut et fait évoluer cette technologie. Docker en tant qu’organisation travaille en collaboration avec les fournisseurs de solutions cloud, Linux et Windows, dont Microsoft.
Les conteneurs Docker peuvent s’exécuter n’importe où, en local dans le centre de données du client, dans un fournisseur de services externe ou dans le cloud. Les conteneurs d’images Docker peuvent s’exécuter en mode natif sur Linux et Windows.
Qu’est-ce qu’une image ?
Quand un développeur utilise Docker, il crée une application ou un service, puis crée un package de l’application ou du service et de ses dépendances dans une image conteneur. Une image est une représentation statique de l’application ou du service, de leur configuration et de leurs dépendances.
L’image, quand elle s’exécute, devient le conteneur. Le conteneur est l’instance en mémoire d’une image.
Une image conteneur est non modifiable. Une fois que vous avez généré une image, celle-ci ne peut plus être changée. Dans la mesure où vous ne pouvez pas changer une image, si vous devez apporter des changements à l’application ou au service et à ses dépendances, créez une image. Cette fonctionnalité garantit que l’imageF que vous utilisez en production est la même que celle utilisée à des fins de développement et de test.
Qu’est-ce qu’un Dockerfile ?
Un fichier Dockerfile est un fichier texte qui contient des instructions sur la génération d’une image Docker. Les fichiers Dockerfile sont écrits dans un langage de script minimal conçu pour la génération et la configuration d’images. Les fichiers Dockerfile documentent également les opérations nécessaires à la génération d’une image, à partir d’une image de base.
Pour créer une image Docker contenant votre application, vous devez généralement commencer par identifier une image de base. Vous devez ensuite ajouter d’autres fichiers et une configuration à l’image de base. Le processus d’identification d’une image de base appropriée commence généralement par une recherche sur Docker Hub d’une image prête à l’emploi qui contient déjà un framework d’application et tous les outils et utilitaires d’une distribution Linux comme Ubuntu ou Alpine. Par exemple, si vous avez une application ASP.NET que vous souhaitez empaqueter dans un conteneur, Microsoft publie une image appelée mcr.microsoft.com/dotnet/aspnet qui contient déjà le runtime ASP.NET.
Vous pouvez personnaliser une image en démarrant un conteneur avec une image de base, puis en lui apportant des changements. Les changements impliquent généralement des activités telles que la copie de fichiers dans le conteneur à partir du système de fichiers local, et l’exécution de divers outils et utilitaires pour compiler le code.
Un fichier Dockerfile est un ensemble d’instructions qui créent une image Docker contenant exactement les logiciels dont vous avez besoin pour exécuter votre application ainsi que l’application proprement dite.