Que sont les microservices ?

Les microservices décrivent une approche architecturale cloud-native du développement logiciel qui structure une application à partir de services faiblement couplés en communication les uns avec les autres via des API ou des protocoles de messagerie. Chaque service est autonome et indépendant et exécute un processus unique. Alors que les développeurs cherchent à créer des applications évolutives et résilientes, les microservices sont devenus de plus en plus populaires.

 

Les microservices expliqués

Les microservices, également connus sous le nom d'architecture microservices, sont un type d'architecture logicielle utilisé dans le développement d'applications Cloud Native. Les applications conçues selon ce modèle comprennent de petits composants indépendants et faiblement couplés qui peuvent être déployés et qui, ensemble, fournissent les capacités de l'application.

Dans une architecture de microservices, chaque service exécute une fonction métier distincte et communique avec d'autres microservices par le biais d'interfaces bien définies, la plupart du temps à l'aide d'API RESTful.

S'éloignant de l'application monolithique développée en une seule unité, les microservices permettent aux développeurs de construire avec des modules qu'ils peuvent développer, tester et déployer de manière indépendante, ce qui accélère la mise sur le marché. La nature découplée des microservices permet aux développeurs d'introduire de nouveaux codes et de nouvelles fonctionnalités plus fréquemment qu'ils ne le pourraient autrement, ce qui permet aux applications modernes de suivre l'évolution des besoins des clients.

Plus de développement d'applications Cloud Native, remplaçant leurs applications monolithiques hébergées par des serveurs web individuels par des applications conteneurisées, natives du cloud et réparties sur un cluster de serveurs hôtes.

 

De l'architecture orientée services aux microservices

L'architecture orientée services (SOA) est apparue au début des années 2000 comme un moyen de construire de grands systèmes distribués en les décomposant en services plus petits et faiblement couplés. L'architecture microservices est apparue comme une évolution naturelle de l'architecture SOA.

Le concept de microservices a été introduit par Fred George lors d'un atelier sur l'architecture logicielle en 2011. George avait essayé de résoudre des problèmes d'évolutivité avec l'architecture SOA alors qu'il travaillait sur un site de commerce électronique et il a eu l'idée de construire de petits services autonomes.

L'architecture microservices a repris les principes SOA d'orientation des services et les a affinés pour les applications cloud-natives modernes. Les services à gros grain de la SOA sont devenus des "micro" services à grain fin et granulaire, ce qui les rend très efficaces et offre la flexibilité nécessaire pour adapter une pile technologique à un service donné. L'architecture microservices a même réduit la charge de communication en remplaçant les API SOAP encombrantes par des options légères, telles que les API REST ou les files d'attente de messages.

Les microservices ont rapidement gagné en popularité parmi les architectes de logiciels, et des entreprises comme Netflix, Amazon, The Guardian et Spotify ont commencé à adopter cette architecture.

L'architecture de microservices est à la base des avantages associés à l'application moderne et Cloud Native.

Figure 1 : L'architecture de microservices est à la base des avantages associés à l'application moderne et Cloud Native.

 

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.

Appels API représentant les demandes des clients acheminées par la passerelle API vers les terminaux des microservices internes.

Figure 2 : Les appels API représentant les demandes des clients acheminées par API gateway vers les terminaux des microservices internes.

 

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

Toutes les applications cloud-natives sont des applications microservices, mais toutes les applications microservices ne sont pas cloud-natives. L'architecture microservices peut être mise en œuvre sur place ou dans le cloud et ne nécessite pas nécessairement de technologies ou d'outils spécifiques au cloud.
Les microservices communiquent via des API, et une passerelle API est souvent utilisée comme couche intermédiaire, en particulier lorsque le nombre de services d'une application augmente. Située à la périphérie de vos microservices, la passerelle API agit comme un proxy pour gérer tout le trafic entrant, en fournissant un point d'entrée unique et en acheminant toutes les demandes.
Un maillage de services est une couche d'infrastructure dédiée appliquée à un système basé sur des microservices qui permet aux développeurs de séparer et de gérer la communication entre services au sein d'une architecture de microservices. La technologie de maillage de services peut prendre en charge des éléments tels que la découverte de services, l'équilibrage des charges et la gestion du trafic, ce qui permet aux développeurs de se concentrer sur l'écriture du code plutôt que sur la gestion de l'infrastructure.
Les microservices étant des systèmes distribués avec de multiples composants et services, la journalisation et la surveillance jouent un rôle essentiel dans la préservation de la santé et des performances globales du système. Chaque microservice génère un journal, qui doit être agrégé et analysé pour identifier les problèmes dans le système.
Les microservices sans état ne conservent pas d'informations sur l'état entre les requêtes. Conçus pour être autonomes, ils ne s'appuient pas sur des données préalablement stockées pour traiter les demandes entrantes. Les microservices sans état sont plus faciles à gérer et à faire évoluer, mais peuvent nécessiter une complexité supplémentaire pour maintenir la cohérence des données sur plusieurs exigences. Les microservices sans état sont souvent utilisés pour des tâches simples et indépendantes, telles que la validation ou l'autorisation de données, où les opérations avec état ne sont pas exigées.
Les microservices avec état sont un type de microservice qui maintient l'état d'une application. Cela signifie que le microservice a accès aux données persistantes entre les requêtes et peut les modifier, ce qui peut inclure les données de session de l'utilisateur, les connexions à la base de données ou d'autres informations à l'état stable. Les microservices avec état peuvent offrir des avantages tels qu'une amélioration des performances, une meilleure cohérence des données et une réduction de la complexité de la conception de l'application. Elles nécessitent toutefois une gestion supplémentaire et peuvent être difficiles à échelonner horizontalement.
Si un domaine représente un problème à résoudre - comme c'est le cas dans la conception dirigée par le domaine (DDD) - le modèle de domaine est le modèle qui met en œuvre la solution au problème.
Le contexte délimité représente un ensemble de caractéristiques fonctionnelles, un modèle de domaine, dans les limites d'un domaine. En d'autres termes, tout comme un sous-domaine est un segment du domaine, un contexte délimité est un segment de la solution. Un microservice est donc un contexte délimité, mais tous les contextes délimités ne sont pas des microservices. En fait, les contextes délimités ne sont pas nécessairement isolés les uns des autres.
Le traçage distribué est une technique qui permet aux développeurs de suivre une requête à travers plusieurs microservices et d'identifier tout problème dans le flux de la requête. Les outils de traçage distribués permettent aux développeurs de suivre le flux des demandes à travers le système et d'identifier les goulets d'étranglement ou les problèmes dans le flux des demandes.
Les architectures microservices sont conçues et mises en œuvre à l'aide du langage pattern microservices. Les langages de modèles comprennent des modèles pour la recherche d'événements, la gestion des données, la communication et bien d'autres choses encore.
Les modèles de découverte de services aident les applications et les services à se trouver les uns les autres dans un environnement distribué de microservices. Les instances de service changent dynamiquement en raison de l'échelle, des mises à niveau et des défaillances de service, et ces modèles fournissent des mécanismes de découverte pour faire face à la transience. L'équilibrage de la charge peut utiliser des modèles de découverte de services en utilisant les contrôles de santé et les défaillances de services comme déclencheurs pour rééquilibrer le trafic.
Les modèles de microservices d'adaptation traduisent les relations entre des classes ou des objets autrement incompatibles. Une application qui s'appuie sur des API tierces peut utiliser un modèle d'adaptateur pour assurer la communication entre l'application et les API.
Les modèles d'application Strangler aident à gérer le processus de refonte d'une application monolithique en microservices en remplaçant progressivement des parties du monolithe par des microservices.
Les modèles "backend-for-frontend" (BFF) identifient la manière dont les données sont récupérées entre le serveur et les clients. Le BFF insère une couche entre l'interface utilisateur et les ressources auxquelles l'interface fait appel, ce qui permet aux développeurs de créer et de prendre en charge un type de backend par interface utilisateur, en utilisant les meilleures options pour cette interface. Cela permet d'améliorer les performances du frontend en adaptant les ressources aux besoins de l'interface.
Les modèles d'entités et d'agrégats permettent de classer les données de manière significative. Par exemple, un site de commerce électronique peut utiliser le modèle d'entité pour représenter les produits individuels et le modèle d'agrégat pour représenter les commandes, qui sont des ensembles de produits commandés par un acheteur.
La mise en cache est un élément important de nombreuses applications microservices, car elle permet d'améliorer les performances et de réduire la charge sur le backend. La plupart des fournisseurs de services cloud (CSP) proposent à leurs clients un service de mise en cache géré.
Le stockage d'objets fait partie intégrante de nombreuses applications microservices, car il permet de stocker et d'extraire des fichiers et des objets de données volumineux. La plupart des CSP proposent un service de stockage d'objets géré qui peut être utilisé pour stocker et récupérer des objets pour des applications microservices.