Que sont les microservices ?

Avantages des microservices

Les microservices fournissent un framework pour construire des applications Cloud Native qui peuvent s'adapter à l'évolution des exigences de l'entreprise. Les innombrables avantages découlent de l'architecture de l'application.

Agilité

L'architecture microservices se prête à un développement et à un déploiement indépendants. Contrairement aux applications monolithiques, où le changement d'une ligne de code implique la mise à jour de toute l'application, les développeurs peuvent modifier ou remplacer des services sans affecter le système distribué. La possibilité de déployer des services individuels facilite l'ajout de nouvelles fonctionnalités ou le retour en arrière des modifications apportées à une application.

Évolutivité

La mise à l'échelle d'une application entière n'est pas optimale. Avec les microservices, seuls les composants qui nécessitent une mise à l'échelle sont mis à l'échelle. Les développeurs peuvent s'occuper d'un service individuel en fonction des besoins, ce qui permet en fin de compte d'améliorer les performances en cas de charge importante, d'utiliser efficacement les ressources et de réduire les coûts d'infrastructure.

Choix

Dans l'architecture microservices, l'application Cloud Native ne partage pas une pile et une base de données communes. Les développeurs peuvent choisir les outils qu'ils préfèrent et les technologies pour répondre aux exigences distinctes des services individuels.

Intégration

Les développeurs peuvent écrire des microservices dans n'importe quel langage et les connecter à des microservices programmés dans n'importe quel langage. De plus, les microservices peuvent fonctionner sur n'importe quelle plateforme, ce qui permet de les intégrer aux systèmes existants.

Réutilisation du code

L'architecture microservices permet aux développeurs de construire des services modulaires qu'ils peuvent réutiliser dans les applications. En travaillant avec des composants réutilisables, les programmeurs réduisent le temps de développement et améliorent la qualité du code, car ils investissent dans une culture "écrire une fois, réutiliser souvent".

Tolérance de panne

L'architecture microservices favorise la résilience. Les services étant conçus pour fonctionner de manière autonome, la défaillance d'un seul d'entre eux entraîne rarement l'arrêt de l'application, comme c'est souvent le cas pour les applications monolithiques.

Collaboration

L'architecture microservices permet aux équipes de travailler simultanément sur différents services, ce qui se traduit par un délai de mise sur le marché plus rapide. Si les développeurs prennent des décisions sans avoir à se coordonner avec d'autres équipes, les microservices favorisent également la collaboration entre les équipes, puisque chacune d'entre elles est responsable du développement et de la maintenance d'une partie de l'ensemble. Cela peut conduire à un meilleur alignement sur les objectifs de l'entreprise et à une utilisation plus efficace des ressources.

Itération constante

L'application construite avec des microservices est faite pour évoluer. Les développeurs peuvent rapidement déployer des microservices de base en tant que produit minimum viable et mettre à niveau l'application au fur et à mesure que les équipes complètent les services supplémentaires. Les nouvelles technologies peuvent être intégrées dans la conception au fur et à mesure de leur apparition. L'application basée sur les microservices reste en cours, évoluant constamment vers la perfection théorique.

Quand utiliser les microservices ?

Bien que les microservices basés sur des conteneurs offrent de nombreux avantages, ils ne constituent pas toujours la bonne architecture d'application à choisir. Lorsque vous prenez des décisions en matière d'ingénierie logicielle, pensez à vos objectifs pour l'application, ainsi qu'aux obstacles au développement et aux besoins que vous prévoyez pour la durée de vie de l'application. Les microservices fonctionnent mieux avec les applications complexes. Les scénarios à envisager pour l'utilisation des microservices sont les suivants :

Grandes applications

Si vous construisez une application vaste et complexe, les microservices vous permettront de diviser l'application en morceaux gérables, ce qui facilitera son développement, son déploiement et sa maintenance.

Complexité du calendrier

L'architecture microservices peut accueillir des services indépendants avec des rythmes de développement différents. Même si un service connaît un retard inattendu, le projet peut se poursuivre sans incidence globale sur le calendrier de développement de l'application.

Mises à jour fréquentes

L'architecture microservice est idéale pour les applications qui nécessiteront des mises à jour fréquentes, car les services indépendants permettent aux développeurs de modifier le module plutôt que l'application.

Grande évolutivité

Si votre application doit gérer un volume de trafic important ou doit évoluer rapidement, les microservices sont indispensables. C'est notamment le cas si vous devez mettre à l'échelle des parties spécifiques de l'application, plutôt que l'ensemble de l'application.

Équipes multiples

Si plusieurs équipes de développement travaillent sur la même application, les microservices vous aideront à conserver agilité et efficacité. Chaque équipe peut travailler sur son microservice, en utilisant la pile technologique qui lui convient, sans se soucier du reste de l'application.

Architecture décentralisée

Si vous souhaitez construire une application avec une architecture décentralisée, les microservices sont autonomes et peuvent être déployés à différents endroits, même parmi différents fournisseurs de services cloud.

Cloud hybride

Si vous prévoyez une architecture de cloud hybride, dans laquelle certains services continueront à fonctionner sur place et d'autres dans le cloud, les microservices vous aideront à gérer la complexité de l'application.

Construire et déployer des applications basées sur les microservices

L'architecture microservices exige une planification minutieuse. Certaines technologies et pratiques communes à l'environnement de production permettent aux développeurs de développer, de maintenir et d'exploiter efficacement des applications basées sur des microservices.

DevOps

Les pratiques DevOps, notamment CI/CD, sont essentielles à l'approche architecturale des microservices. Contrairement aux applications monolithiques, les microservices sont des systèmes distribués intrinsèquement complexes, avec de nombreuses pièces mobiles et des piles technologiques indépendantes. Cette complexité exige une collaboration fréquente entre les équipes de développement et d'exploitation afin de garantir une intégration transparente des composants.

Les pratiques DevOps fournissent les outils de collaboration, de communication et d'automatisation nécessaires pour rassembler efficacement les équipes tout au long du cycle de vie du développement logiciel.

Livraison continue

La livraison continue va de pair avec les microservices, permettant aux développeurs de déployer des mises à jour logicielles fréquemment et de manière fiable en faisant appel à des outils d'automatisation de l'infrastructure, tels que des serveurs d'intégration continue, des pipelines de déploiement et des cadres de tests automatisés pour rationaliser le processus CI/CD.

La livraison constante est particulièrement importante pour garantir que chaque service peut être mis à jour et publié indépendamment des autres microservices.

REST

Les microservices communiquent entre eux - et la plupart le font au sein d'applications web - ce qui rend REST complémentaire. REST, ou Representational State Transfer, est un modèle de conception architecturale pour construire des API RESTful, qui permettent aux services de communiquer via HTTP dans des formats standard, tels que XML, HTML et JSON. Mais les API REST sont essentielles pour les applications basées sur les microservices, et ce pour plusieurs raisons.

Les API REST sont légères et agnostiques en termes de plateforme, ce qui signifie qu'elles fournissent une interface standardisée qui permet aux microservices de communiquer, quelle que soit leur technologie sous-jacente. Étant donné que les exigences contiennent les informations nécessaires pour compléter la demande, les API REST ne nécessitent pas de contexte stocké sur le serveur. Ils peuvent traiter de gros volumes de demandes sans compromettre les performances, et les services d'une architecture microservices basée sur REST peuvent évoluer de manière indépendante, en communiquant efficacement de manière apatride.

Conteneurs

Bien que les microservices permettent aux équipes de choisir le langage et le cadre de leur service, travailler avec différents langages dans le même pipeline de CD pose des problèmes. Containers fait abstraction de la variance entre les services, car chaque microservice devient une unité autonome progicialisée avec sa base de code, sa base de données et ses dépendances. Le pipeline de CD, désormais homogène, peut effectuer des tests cohérents sur chaque conteneur.

Les services sont capables d'interagir sans interférer les uns avec les autres lorsqu'ils sont séparés par des conteneurs, et une fois déployés, les conteneurs fournissent un environnement d'exécution léger et portable qui permet aux services de fonctionner de manière cohérente sur toutes les plateformes. Des outils comme Docker et Kubernetes sont largement utilisés pour gérer les microservices conteneurisés.

Orchestrateur Kubernetes

Un outil d'orchestration comme Kubernetes peut faire abstraction de l'infrastructure sous-jacente et automatiser la gestion, le déploiement et la mise à l'échelle des conteneurs sur plusieurs serveurs. Son extensibilité permet également aux développeurs et aux opérateurs d'utiliser leurs outils logiciels libres et commerciaux préférés, réduisant ainsi le travail manuel de gestion des conteneurs.

Sans serveur

L'informatique sans serveur est une autre option pour déployer des microservices. Les architectures sans serveur utilisent des plateformes de fonctions en tant que service (FaaS) pour créer des unités de déploiement encore plus petites et évoluer à la demande. Bien que les architectures sans serveur puissent augmenter les dépendances des fournisseurs, elles offrent une réduction des coûts opérationnels, de la complexité et des délais d'ingénierie.

Meilleures pratiques en matière de microservices

La conception d'une architecture de microservices exige une planification et une réflexion approfondies. Pour créer des applications basées sur les microservices réussies, les développeurs doivent observer les bonnes pratiques suivantes :

• Conception axée sur le domaine : La conception axée sur le domaine (DDD) est une approche de conception qui se concentre sur le domaine d'activité et le comportement de l'application. Il aide les développeurs à diviser l'application en composants plus petits et plus faciles à gérer, ce qui facilite la construction, le déploiement et la maintenance.
• Limites du service : Lors de la conception d'une architecture de microservices, il est essentiel de définir des limites de service claires. Chaque microservice doit avoir une responsabilité bien définie.
• Petits services : Gardez les services "micro", concentrés sur une seule responsabilité. Si vous perdez de vue ce principe fondamental, vous sacrifierez la facilité de gestion.
• Conception de l'API : Les microservices communiquent par le biais d'API. Utilisez donc des API cohérentes, évolutives et sécurisées qui limitent l'accès aux données aux applications, utilisateurs et serveurs autorisés.
• Gestion décentralisée des données : Les applications microservices nécessitent une variété d'options de stockage et de base de données. Chaque microservice doit disposer de son propre datastore. Cette approche vous aide à éviter les incohérences de données et vous permet de mettre à l'échelle chaque microservice de manière autonome. Vous voulez que l'équipe de développement choisisse la base de données pour chaque service afin de s'assurer qu'elle convient le mieux à son projet.
• Pipelines CI/CD: La mise en œuvre de CI/CD vous aidera à trouver et à corriger les bogues rapidement, ce qui est particulièrement précieux avec plusieurs bases de code à gérer dans une architecture de microservices.
• Résilience intentionnelle : Protégez l'application contre les arrêts dus à des défaillances de dépendances. N'utilisez pas d'appels de procédure à distance (RPC) entre les microservices, si possible, et intégrez des fonctions telles que des disjoncteurs pour arrêter les défaillances en cascade.
• SOP: Élaborer des procédures opérationnelles normalisées qui définissent les conventions de codage, les structures de répertoire et les protocoles de communication. Le respect d'un ensemble de normes permet de créer des microservices cohérents et gérables.

Adopter les microservices

eBay, Etsy, Uber - d'innombrables entreprises ont démantelé leurs applications monolithiques et les ont refaçonnées en architectures basées sur les microservices pour capitaliser sur les avantages d'échelle, l'agilité de l'entreprise et les gains financiers.

Les organisations qui prévoient de passer aux microservices devraient d'abord adopter DevOps, ce qui vous mettra en condition pour gérer les complexités que vous rencontrerez. De manière générale, anticipez les étapes décrites ci-dessous lors de l'élaboration de votre projet.

Identifier les capacités de l'entreprise

La première étape de la migration vers l'architecture microservices consiste à identifier les capacités ou les fonctionnalités commerciales que votre application doit prendre en charge. Cela vous aidera à définir le champ d'application de votre application et à prendre des décisions sur les capacités à développer en priorité, ainsi que sur la manière dont ces microservices doivent être conçus et intégrés les uns aux autres.

Décomposer l'application monolithique

La plupart des organisations utilisent la conception pilotée par domaine ou la décomposition basée sur les fonctionnalités pour décomposer leurs applications monolithiques.

Après avoir identifié les capacités commerciales de l'application, définissez les limites des services pour chaque microservice, en veillant à ce que chaque microservice ait une responsabilité distincte et bien définie. Vous voudrez cartographier les dépendances entre les capacités de l'entreprise, les datastores et les systèmes externes. Sur la base des contextes délimités et des dépendances, définissez les microservices qui remplaceront l'application monolithique.

Chaque microservice, axé sur une seule capacité commerciale, doit avoir des interfaces claires. Examinez les modalités d'accès aux entités de données et, enfin, réfléchissez à la manière de partitionner les données afin de réduire les dépendances entre les services.

Définir les interfaces de service

Mettez en œuvre les interfaces de service pour chaque microservice, en veillant à ce que l'interface reflète la seule responsabilité du microservice. Vous pouvez utiliser différentes techniques, telles que les API RESTful ou les protocoles de messagerie, pour définir les interfaces de service.

Mettre en œuvre et tester les services

En fonction de vos exigences et de votre expertise, choisissez les langages de programmation et les cadres pour mettre en œuvre les services. Répétez la conception si nécessaire, notamment en testant les nouvelles interfaces, les protocoles de communication et les datastores.

Conteneuriser les services

Une fois les services mis en œuvre et testés, vous voudrez les conteneuriser à l'aide de technologies de conteneurs, telles que Docker ou Kubernetes. La conteneurisation vous permettra de déployer et de gérer les services de manière indépendante.

Automatiser le déploiement et l'orchestration

Automatisez l'orchestration des services à l'aide d'outils tels que Kubernetes ou Docker Swarm. En plus de rationaliser efficacement le déploiement des services, l'automatisation via Kubernetes ou Docker améliorera la fiabilité et la disponibilité de l'application. L'une ou l'autre de ces plates-formes peut détecter une défaillance ou une absence de réponse d'une instance de service et prendre des mesures pour remédier au problème. Kubernetes, par exemple, peut redémarrer les instances défaillantes ou les reprogrammer sur d'autres nœuds, tandis que Docker peut migrer automatiquement le conteneur défaillant vers un autre nœud.

Contrôler et gérer les services

La décomposition d'une application monolithique n'est pas un processus unique. Il nécessite une maintenance et des mises à jour au fur et à mesure de l'évolution des besoins de l'application et de ses utilisateurs. Surveillez les nouveaux microservices et suivez les indicateurs clés, tels que le temps de réponse et l'utilisation des ressources.

Sécuriser les microservices

Les applications microservices hautement distribuées et cloud-natives introduisent des complexités en matière de sécurité. Au lieu d'un seul point d'entrée, ils comportent des dizaines, voire des centaines, de points de vulnérabilité potentiels - et chacun d'entre eux doit être sécurisé. Les API et les dépendances du code ne représentent que deux sources de risque dans la surface d'attaque croissante de l'application moderne.

Sécurité des applications web et des API

Les applications modernes consomment des entrées provenant de diverses sources - requêtes web standard, appels API d'appareils mobiles, événements cloud, communication de télémétrie d'appareils IoT, stockage cloud, etc. Qui plus est, la demande web d'un seul client (c'est-à-dire le trafic nord-sud) peut engendrer des centaines d'appels API entre microservices internes (c'est-à-dire le trafic est-ouest).

La complexité des applications web centrées sur les API nécessite des stratégies évolutives, flexibles et multicouches qui fonctionnent pour tout type de charge de travail dans tout type d'environnement ou d'architecture cloud. Sécuriser l'interface web frontale de l'application Cloud Native ne suffit pas. Les exigences des applications Cloud Native nécessitent une protection de la couche applicative pour les API Cloud Native. La sécurité des applications web et des API (WAAS) est essentielle.

Dépendances du code et analyse de la composition des logiciels

Les composants logiciels libres représentent environ 70 % des applications Cloud Native. Bien que cela accélère le développement, de nombreux progiciels open-source et leurs dépendances contiennent des vulnérabilités. En outre, chaque version d'un progiciel de logiciel libre dépendant peut modifier des fonctionnalités essentielles. Sans une visibilité totale, les vulnérabilités ne sont pas détectées.

Les outils autonomes d'analyse de la composition des logiciels (SCA) mettent en évidence les risques liés aux logiciels libres trop tard dans le cycle de développement, ce qui entraîne une accumulation de vulnérabilités qui ne peuvent pas toujours être résolues. Des outils distincts pour le SCA et la sécurité de l'IaC donnent lieu à des alertes bruyantes sans contexte et sans connaissance des risques interconnectés. Parce que les lacunes sont inévitables sans couverture de l'exécution et de la charge de travail, il est préférable de sécuriser les applications Cloud Native avec une sécurité Cloud Native intégrée.

Code-to-Cloud CNAPP

Identifiant et hiérarchisant les risques critiques de l'ensemble de l'application cloud-native, une cloud-native application protection platform (CNAPP) intègre plusieurs types de sécurité pour offrir une protection complète, de code à cloud - gestion de la posture de sécurité cloud (CSPM), protection de la charge de travail cloud, gestion des droits à l'infrastructure cloud (CIEM), gestion de la posture de sécurité Kubernetes (KSPM), sécurité de l'infrastructure en tant que code, WAAS, SCA et bien d'autres encore.

Les responsables de la sécurité du cloud qui explorent la meilleure façon de sécuriser les besoins de développement rapide des applications employant des technologies cloud-natives, telles que les conteneurs, les microservices et les fonctions sans serveur, devraient envisager d'adopter un CNAPP.

FAQ sur les microservices