Partager via

Évaluation et préparation des microservices

  • Article

Une architecture de microservices peut offrir de nombreux avantages pour vos applications, notamment en termes d’agilité, d’évolutivité et de haute disponibilité. Ce type d’architecture présente également son lot de défis. Lorsque vous générez des applications basées sur des microservices ou transformez des applications existantes en architecture de microservices, vous devez analyser et évaluer votre situation actuelle pour identifier les améliorations nécessaires.

Ce guide vous aidera à comprendre certaines considérations dont vous devez tenir compte lorsque vous opérez une migration vers une architecture de microservices. Vous pouvez l’utiliser pour évaluer la maturité de votre application, votre infrastructure, vos pratiques DevOps, votre modèle de développement, etc.

Cerner les priorités de l’entreprise

Pour commencer à évaluer une architecture de microservices, vous devez identifier les principales priorités de votre entreprise. Celles-ci peuvent avoir trait à l’agilité, à l’adoption du changement ou au développement rapide, par exemple. Vous devez déterminer si votre architecture est adaptée à vos principales priorités. Gardez à l’esprit que celles-ci peuvent changer avec le temps. Par exemple, si l’innovation constitue une priorité majeure pour les start-ups, après quelques années d’activité, la fiabilité et l’efficacité peuvent devenir les critères les plus importants.

Voici quelques-unes des priorités à prendre en compte :

  • Innovation
  • Fiabilité
  • Efficacité

Documentez les contrats de niveau de service alignés sur les différentes parties de votre application afin de garantir un engagement organisationnel qui peut servir de guide pour votre évaluation.

Enregistrer les décisions architecturales

Une architecture de microservices permet aux équipes de devenir autonomes. Les équipes peuvent prendre leurs propres décisions concernant les technologies, les méthodologies et les composants d’infrastructure, par exemple. Toutefois, ces choix doivent respecter les principes officiellement approuvés appelés gouvernance partagée, qui expriment l’accord entre les équipes sur la manière de traiter la stratégie globale pour les microservices.

Tenez compte de ces facteurs :

  • La gouvernance partagée est-elle en place ?
  • Suivez-vous les décisions et leurs compromis dans un journal d’architecture ?
  • Votre équipe peut-elle accéder facilement à votre journal d’architecture ?
  • Disposez-vous d’un processus d’évaluation des outils, technologies et infrastructures ?

Évaluer la composition de l’équipe

Vous devez disposer de la structure d’équipe appropriée pour éviter toute communication inutile entre les équipes. Une architecture de microservices encourage la formation d’équipes de petite taille, ciblées et polyvalentes et requiert un changement de mentalité avant de procéder à la restructuration de l’équipe.

Tenez compte de ces facteurs :

  • Vos équipes sont-elles scindées en fonction de sous-domaines, en suivant les principes de conception dirigée par le domaine ?
  • Vos équipes sont-elles polyvalentes, et offrent-elles une capacité suffisante pour créer et opérer les microservices connexes indépendamment ?
  • Combien de temps est consacré aux activités et tâches ad hoc sans lien avec les projets ?
  • Combien de temps est consacré à la collaboration entre équipes ?
  • Avez-vous mis en place un processus d’identification et de minimisation de la dette technique ?
  • Comment les enseignements tirés et l’expérience acquise sont-ils communiqués entre les équipes ?

Utiliser la méthodologie des applications à douze facteurs

L’objectif fondamental lié au choix d’une architecture de microservices est de générer de la valeur plus rapidement et d’être en mesure de s’adapter aux changements en suivant les pratiques agiles. La méthodologie des applications à douze facteurs fournit des recommandations pour la création d’applications faciles à gérer et évolutives. Ces recommandations promeuvent des attributs tels que l’immuabilité, l’éphémérité, la configuration déclarative et l’automatisation. En incorporant ces instructions et en évitant les écueils les plus fréquents, vous pouvez créer des microservices autonomes couplés de façon souple.

Comprendre l’approche de décomposition

La transformation d’une application monolithique en architecture de microservices prend du temps. Commencez avec les services périphériques. Ceux-ci ont moins de dépendances sur d’autres services et peuvent être facilement décomposés du système en tant que services indépendants. Nous recommandons vivement de recourir à des modèles tels que le Figuier étrangleur et la Couche de lutte contre la corruption pour maintenir l’application monolithique dans un état de fonctionnement jusqu’à ce que tous les services soient décomposés en microservices distincts. Au cours de la séparation, les principes de conception dirigée par le domaine peuvent aider les équipes à choisir des composants ou services issus de l’application monolithique sur la base de sous-domaines.

Par exemple, un système de commerce électronique peut inclure les modules suivants : panier, gestion des produits, gestion des commandes, tarification, génération des factures et notification. Vous décidez de commencer la transformation de l’application avec le module de notification, car elle n’a pas de dépendances vis-à-vis d’autres modules. Il est toutefois possible que d’autres modules dépendent de ce module pour l’envoi de notifications. Le module de notification peut facilement être décomposé en un microservice distinct, mais vous devrez apporter des modifications à l’application monolithique pour invoquer le nouveau service de notification. Vous décidez de transformer le module de génération de factures ensuite. Ce module est invoqué chaque fois qu’une commande est générée. Vous pouvez utiliser des modèles tels que le Figuier étrangleur et la Couche de lutte contre la corruption pour prendre en charge cette transformation.

La synchronisation des données, les opérations d’écriture multiples sur les interfaces monolithiques et de microservices, la propriété des données, la décomposition des schémas, les jointures, le volume de données et l’intégrité des données peuvent compliquer la répartition et la migration des données. Plusieurs techniques peuvent être utilisées (par exemple, conservation d’une base de données partagée entre les microservices, découplage des bases de données à partir d’un groupe de services basé sur la capacité ou le domaine de l’entreprise, et l’isolation des bases de données d’avec les services). La solution recommandée consiste à décomposer chaque base de données avec chaque service. Bien souvent, cela n’est pas pratique. En pareil cas, vous pouvez utiliser des modèles tels que Vue de base de données et Service d’enveloppement de base de données.

Évaluer la préparation de vos pratiques DevOps

Lorsque vous opérez une migration vers une architecture de microservices, il est important d’évaluer les compétences des pratiques DevOps. Une architecture de microservices est conçue pour faciliter le développement agile au sein des applications afin d’accroître l’agilité de l’organisation. DevOps est l’une des pratiques clés que vous devez implémenter pour atteindre cette compétence.

Lorsque vous évaluez la capacité de vos pratiques DevOps pour une architecture de microservices, gardez les points suivants à l’esprit :

  • Les membres de votre organisation connaissent-ils les pratiques et principes fondamentaux des DevOps ?
  • Les équipes comprennent-elles les outils de contrôle de code source et leur intégration aux pipelines CI/CD ?
  • Implémentez-vous les pratiques DevOps correctement ?
    • Suivez-vous les pratiques agiles ?
    • L’intégration continue est-elle implémentée ?
    • La livraison continue est-elle implémentée ?
    • Le déploiement continu est-il implémenté ?
    • La surveillance continue est-elle implémentée ?
    • L’infrastructure en tant que code (Infrastructure as Code, IaC) est-elle utilisée ?
  • Utilisez-vous les outils appropriés pour prendre en charge CI/CD ?
  • Comment la configuration des environnements intermédiaires et de production est-elle gérée pour l’application ?
  • La chaîne d’outils intègre-t-elle le support de la communauté et un modèle de support, et fournit-elle des canaux et une documentation appropriés ?

Identifier les aspects opérationnels qui changent fréquemment

Une architecture de microservices est flexible et adaptable. Pendant l’évaluation, menez une discussion au sein de l’organisation visant à déterminer les aspects dont vos collègues pensent qu’ils changeront fréquemment. La création de microservices permet aux équipes de répondre rapidement aux changements que les clients demandent et de réduire les efforts liés aux tests de régression. Dans une application monolithique, un changement dans un module nécessite plusieurs niveaux de test de régression et réduit l’agilité dans le cadre de la publication de nouvelles versions.

Tenez compte de ces facteurs :

  • Le service est-il déployable indépendamment ?
  • Le service suit-il les principes de conception dirigée par le domaine ?
  • Le service suit-il les principes SOLID ?
  • La base de données est-elle privée et accessible uniquement au service ?
  • Avez-vous créé le service à l’aide du modèle de châssis de microservices pris en charge ?

Évaluer la préparation de l’infrastructure

Lorsque vous passez à une architecture de microservices, la préparation de l’infrastructure est un point essentiel à prendre en compte. Les performances, la disponibilité et l’évolutivité de l’application seront affectées si l’infrastructure n’est pas correctement configurée ou si les services ou composants appropriés ne sont pas utilisés. Parfois, une application est créée avec toutes les méthodologies et procédures suggérées, mais l’infrastructure est inadaptée. Cela entraîne une dégradation des performances et de la maintenance.

Tenez compte de ces facteurs lorsque vous évaluez la préparation de votre infrastructure :

  • L’infrastructure assure-t-elle l’évolutivité des services déployés ?
  • L’infrastructure prend-elle en charge l’approvisionnement à l’aide de scripts qui peuvent être automatisés via CI/CD ?
  • L’infrastructure du déploiement offre-t-elle un contrat SLA pour la disponibilité ?
  • Disposez-vous d’un plan de récupération d’urgence et de planifications de recherche de routines ?
  • Les données sont-elles répliquées dans différentes régions à des fins de récupération d’urgence ?
  • Disposez-vous d’un plan de sauvegarde des données ?
  • Les options de déploiement sont-elles documentées ?
  • L’infrastructure de déploiement est-elle surveillée ?
  • L’infrastructure de déploiement prend-elle en charge la réparation spontanée (self-healing) des services ?

Évaluer les cycles de mise en version

Les microservices peuvent s’adapter au changement et tirer parti du développement agile pour raccourcir les cycles de mise en version et apporter davantage de valeur aux clients. Tenez compte de ces facteurs lorsque vous évaluez vos cycles de mise en version :

  • À quelle fréquence générez et publiez-vous des applications ?
  • À quelle fréquence vos versions échouent-elles après leur déploiement ?
  • Combien de temps faut-il pour procéder à une récupération ou corriger les problèmes après une panne ?
  • Utilisez-vous la gestion sémantique de version pour vos applications ?
  • Gérez-vous différents environnements et propagez-vous la même version dans un ordre donné (par exemple, dans un environnement intermédiaire, puis dans un environnement de production) ?
  • Utilisez-vous le contrôle de version pour vos API ?
  • Suivez-vous des instructions recommandations relatives au contrôle de version pour les API ?
  • Quand modifiez-vous une version d’API ?
  • Quelle approche de gestion du contrôle de version des API utilisez-vous ?
    • Contrôle de version du chemin d’accès de l’URI
    • Contrôle de version des paramètres de requête
    • Contrôle de version du type de contenu
    • Contrôle de version des en-têtes personnalisés
  • Avez-vous mis en place une pratique pour le contrôle de version des événements ?

Évaluer la communication entre les services

Les microservices sont des services autonomes qui communiquent entre eux au-delà des limites des processus pour gérer les scénarios d’entreprise. Pour bénéficier d’une communication fiable, vous devez sélectionner un protocole de communication approprié.

Tenez compte des facteurs suivants :

  • Suivez-vous une approche donnant la priorité aux API où les API sont traitées comme des citoyens de première classe ?
  • Avez-vous des opérations à chaîne longue, où plusieurs services communiquent dans un ordre donné sur un protocole de communication synchrone ?
  • Avez-vous envisagé d’utiliser la communication asynchrone à un emplacement quelconque du système ?
  • Avez-vous évalué la technologie de courtier de messages et ses fonctionnalités ?
  • Comprenez-vous le débit des messages reçus et traités par les services ?
  • Utilisez-vous la communication directe entre les clients et services ?
  • Avez-vous besoin de conserver les messages au niveau du courtier de messages ?
  • Utilisez-vous le modèle Vue matérialisée pour gérer le comportement bavard des microservices ?
  • Avez-vous implémenté une nouvelle tentative, un disjoncteur, un backoff exponentiel et une gigue pour assurer la fiabilité des communications ? Le modèle Ambassadeur constitue un moyen courant de gérer cela.
  • Avez-vous défini des événements de domaine pour faciliter la communication entre les microservices ?

Évaluer les modalités d’exposition des services auprès des clients

Une passerelle API est l’un des principaux composants d’une architecture de microservices. L’exposition directe des services auprès des clients crée des problèmes en termes de facilité de gestion, contrôle et de communication fiable. Une passerelle API sert de serveur proxy, en interceptant le trafic et en l’acheminant vers les services back-end. Si vous avez besoin de filtrer le trafic par adresse IP, autorisation, réponses factices, etc., vous pouvez le faire au niveau de la passerelle API sans apporter aucune modification aux services.

Tenez compte des facteurs suivants :

  • Les services sont-ils directement consommés par les clients ?
  • Existe-t-il une passerelle API qui agit comme façade pour tous les services ?
  • La passerelle API peut-elle définir des stratégies telles que les limites de quota, les réponses factices et le filtrage des adresses IP ?
  • Utilisez-vous plusieurs passerelles API pour répondre aux besoins de différents types de clients, tels que les applications mobiles, les applications web et les partenaires ?
  • Votre passerelle API fournit-elle un portail où les clients peuvent découvrir des services et s’y abonner, comme un portail des développeurs dans la Gestion des API Azure ?
  • Votre solution offre-t-elle des fonctionnalités d’équilibrage de charge L7 ou de pare-feu d’applications web, en plus de la passerelle API ?

Évaluer la gestion des transactions

Les transactions distribuées facilitent l’exécution de plusieurs opérations sous la forme d’une unité de travail unique. Dans une architecture de microservices, le système est décomposé en de nombreux services. Un seul cas d’usage professionnel est traité par plusieurs microservices dans le cadre d’une seule transaction distribuée. Dans une transaction distribuée, une commande est une opération qui démarre lorsqu’un événement se produit. L’événement déclenche une opération dans le système. Si l’opération réussit, elle peut déclencher une autre commande, laquelle peut déclencher un autre événement, et ainsi de suite jusqu’à ce que toutes les transactions soient terminées ou annulées, selon que la transaction réussit ou non.

Prenez en compte les considérations suivantes :

  • Combien y a-t-il de transactions distribuées dans le système ?
  • Quelle approche de gestion des transactions distribuées utilisez-vous ? Évaluez l’utilisation du modèle Saga avec l’orchestration ou la chorégraphie.
  • Combien de transactions englobent plusieurs services ?
  • Suivez-vous un modèle de transaction ACID ou BASE pour assurer la cohérence et l’intégrité des données ?
  • Utilisez-vous des opérations de chaînage long pour les transactions qui englobent plusieurs services ?

Évaluer votre modèle de développement de service

La diversité technologique est l’un des principaux avantages des architectures de microservices. Les systèmes basés sur des microservices permettent aux équipes de développer des services en utilisant les technologies de leur choix. Dans le cadre du développement d’applications traditionnel, vous pouvez réutiliser du code existant lorsque vous créez de nouveaux composants, ou créer une infrastructure de développement interne afin de réduire les efforts liés au développement. L’utilisation de plusieurs technologies peut empêcher la réutilisation de code.

Tenez compte de ces facteurs :

  • Utilisez-vous un modèle de service pour lancer rapidement le développement d’un nouveau service ?
  • Suivez-vous la méthodologie des applications à douze facteurs et utilisez-vous une base de code unique pour les microservices afin d’isoler les dépendances et d’externaliser la configuration ?
  • Conservez-vous la configuration sensible dans des coffres de clés ?
  • Placez-vous vos services dans des conteneurs ?
  • Connaissez-vous vos exigences de cohérence des données ?

Évaluer votre approche de déploiement

Votre approche de déploiement est votre méthode de publication des versions de votre application au sein de différents environnements de déploiement. Les systèmes basés sur des microservices offrent l’agilité nécessaire pour publier des versions plus rapidement qu’avec les applications traditionnelles.

Lorsque vous évaluez votre plan de déploiement, tenez compte des facteurs suivants :

  • Avez-vous défini une stratégie pour le déploiement de vos services ?
  • Utilisez-vous des outils et technologies modernes pour déployer vos services ?
  • Quel type de collaboration est nécessaire entre les équipes dans le cadre du déploiement des services ?
  • Approvisionnez-vous l’infrastructure à l’aide de l’infrastructure en tant que code (IaC) ?
  • Utilisez-vous des capacités DevOps pour automatiser les déploiements ?
  • Propagez-vous les mêmes builds dans plusieurs environnements, comme suggéré par la méthodologie des applications à douze facteurs ?

Évaluer votre plateforme d’hébergement

L’évolutivité est l’un des principaux avantages des architectures de microservices. Les microservices étant mappés à des domaines d’entreprise, chaque service peut être mis à l’échelle de manière indépendante. Une application monolithique est déployée en tant qu’unité unique sur une plateforme d’hébergement et doit être mise à l’échelle de façon globale. Cela entraîne un temps d’arrêt, un risque de déploiement et la nécessité d’effectuer une opération de maintenance. Votre application monolithique peut être bien conçue, avec des composants qui traitent des domaines d’entreprise individuels. Mais en raison d’un manque de limites de processus, le risque de violer les principes de responsabilité unique devient plus difficile à gérer. Cela finit par créer du code spaghetti. L’application étant composée et déployée comme un processus d’hébergement unique, l’évolutivité est difficile.

Les microservices permettent aux équipes de choisir la plateforme d’hébergement adaptée pour prendre en charge leurs besoins d’évolutivité. Diverses plateformes d’hébergement permettent de résoudre ces problèmes. Elles fournissent des fonctionnalités telles que la mise à l’échelle automatique, l’approvisionnement élastique, une disponibilité plus élevée, un déploiement plus rapide et une surveillance simple.

Tenez compte de ces facteurs :

  • Quelle plateforme d’hébergement utilisez-vous pour déployer vos services (machines virtuelles, conteneurs, serverless) ?
  • La plateforme d’hébergement est-elle évolutive ? Prend-elle en charge la mise à l’échelle automatique ?
  • Combien de temps faut-il pour mettre à l’échelle votre plateforme d’hébergement ?
  • Comprenez-vous les contrats SLA fournis par diverses plateformes d’hébergement ?
  • Votre plateforme d’hébergement prend-elle en charge la récupération d’urgence ?

Évaluer la surveillance des services

La surveillance représente un élément important d’une application basée sur des microservices. L’application étant divisée en un certain nombre de services qui s’exécutent indépendamment, il peut être décourageant de devoir résoudre les erreurs. Si vous utilisez la sémantique appropriée pour surveiller vos services, vos équipes peuvent facilement surveiller et examiner les erreurs et y répondre.

Tenez compte de ces facteurs :

  • Surveillez-vous vos services déployés ?
  • Disposez-vous d’un mécanisme de journalisation ? Quels outils utilisez-vous ?
  • Avez-vous une infrastructure de suivi distribuée en place ?
  • Enregistrez-vous les exceptions ?
  • Conservez-vous les codes d’erreur métier pour une identification rapide des problèmes ?
  • Utilisez-vous des sondes d’intégrité pour les services ?
  • Utilisez-vous la journalisation sémantique ? Avez-vous implémenté des métriques, des seuils et des indicateurs clés ?
  • Masquez-vous les données sensibles pendant la journalisation ?

Évaluer l’affectation des jetons de corrélation

Dans une architecture de microservices, une application se compose de différents microservices hébergés indépendamment, qui interagissent entre eux pour gérer différents cas d’usage métier. Lorsqu’une application interagit avec des services back-end pour effectuer une opération, vous pouvez affecter un numéro unique, appelé jeton de corrélation, à la requête. Nous vous recommandons d’envisager d’utiliser des jetons de corrélation, car ils peuvent vous aider à résoudre les erreurs. Ils vous aident à déterminer la cause racine d’un problème, à évaluer l’impact et à définir une approche pour résoudre le problème.

Vous pouvez utiliser des jetons de corrélation pour récupérer la trace des requêtes en identifiant les services qui contiennent le jeton de corrélation et ceux dont ce n’est pas le cas. Les services qui n’ont pas le jeton de corrélation pour cette requête ont échoué. En cas d’échec, vous pouvez réessayer ultérieurement la transaction. Pour appliquer l’idempotence, seuls les services qui n’ont pas le jeton de corrélation traiteront la requête.

Par exemple, si vous avez une longue chaîne d’opérations impliquant de nombreux services, la transmission d’un jeton de corrélation aux services peut vous aider à examiner facilement les problèmes si l’un des services échoue au cours d’une transaction. Chaque service a généralement sa propre base de données. Le jeton de corrélation est conservé dans l’enregistrement de base de données. En cas de relecture d’une transaction, les services qui comportent ce jeton de corrélation particulier dans leurs bases de données ignorent la requête. Seuls les services qui n’ont pas le jeton traitent la requête.

Tenez compte de ces facteurs :

  • À quelle étape affectez-vous le jeton de corrélation ?
  • Quel composant affecte le jeton de corrélation ?
  • Enregistrez-vous des jetons de corrélation dans la base de données du service ?
  • Quel est le format des jetons de corrélation ?
  • Enregistrez-vous des jetons de corrélation et d’autres informations sur les requêtes ?

Évaluer la nécessité d’une infrastructure de châssis de microservices

Une infrastructure de châssis de microservices est une infrastructure de base qui fournit des fonctionnalités pour les préoccupations transversales telles que la journalisation, la gestion des exceptions, le suivi distribué, la sécurité et la communication. Lorsque vous utilisez une infrastructure de châssis, vous vous concentrez davantage sur l’implémentation de la limite de service que sur l’interaction avec les fonctionnalités d’infrastructure.

Par exemple, imaginons que vous créez un service de gestion de panier. Vous souhaitez valider le jeton entrant, écrire des journaux dans la base de données de journalisation et communiquer avec un autre service en invoquant le point de terminaison de ce service. Si vous utilisez une infrastructure de châssis de microservices, vous pouvez réduire les efforts de développement. Le système Dapr est fournit différents blocs de construction pour l’implémentation des préoccupations transversales.

Tenez compte de ces facteurs :

  • Utilisez-vous une infrastructure de châssis de microservices ?
  • Utilisez-vous Dapr pour interagir avec les préoccupations transversales ?
  • Votre infrastructure de châssis est-elle non spécifique à un langage ?
  • Votre infrastructure de châssis est-elle générique de telle sorte qu’elle prend en charge tous les types d’applications ? Une infrastructure de châssis ne doit pas contenir de logique spécifique à l’application.
  • Votre infrastructure de châssis offre-t-elle un mécanisme permettant d’utiliser les composants ou services sélectionnés en fonction des besoins ?

Évaluer votre approche des tests de l’application

Traditionnellement, les tests sont effectués une fois le développement terminé et l’application prête à être déployée au sein d’environnements de test d’acceptation utilisateur et de production. Il y a actuellement un changement (shift) dans cette approche : le test intervient ainsi plus tôt (left) dans le cycle de développement de l’application. Le test Shift-Left améliore la qualité des applications car le test est effectué au cours de chaque phase du cycle de vie de développement des applications, y compris les phases de conception, de développement et de post-développement.

Par exemple, lorsque vous développez une application, vous commencez par concevoir une architecture. Lorsque vous utilisez l’approche Shift-Left, vous testez la conception des vulnérabilités à l’aide d’outils tels que Microsoft Threat Modeling Tool. Lorsque vous démarrez le développement, vous pouvez analyser votre code source en exécutant des outils tels que les tests statiques de sécurité des applications (SAST) et en utilisant d’autres outils d’analyse pour détecter les problèmes. Après avoir déployé l’application, vous pouvez utiliser des outils tels que le test de sécurité dynamique des applications (DAST) pour la tester pendant qu’elle est hébergée. Les tests fonctionnels, les tests par le chaos, les tests d’intrusion et les autres types de tests interviennent plus tard.

Tenez compte de ces facteurs :

  • Écrivez-vous des plans de test qui couvrent l’intégralité du cycle de vie du développement ?
  • Incluez-vous des testeurs dans le cadre des réunions consacrées aux spécifications et dans l’ensemble du cycle de vie de développement des applications ?
  • Utilisez-vous la conception pilotée par les tests ou la conception pilotée par le comportement ?
  • Testez-vous les récits utilisateur ? Incluez-vous des critères d’acceptation dans vos récits utilisateur ?
  • Testez-vous votre conception à l’aide d’outils tels que Microsoft Threat Modeling Tool ?
  • Écrivez-vous des tests unitaires ?
  • Utilisez-vous des analyseurs de code statique ou d’autres outils pour mesurer la qualité du code ?
  • Utilisez-vous des outils automatisés pour tester les applications ?
  • Implémentez-vous des pratiques DevOps sécurisées ?
  • Effectuez-vous des tests d’intégration, des tests d’applications de bout en bout, des tests de charge/performance, des tests d’intrusion et des tests par le chaos ?

Évaluer la sécurité des microservices

La protection des services, l’accès sécurisé et la communication sécurisée figurent parmi les considérations les plus importants à prendre en compte pour une architecture de microservices. Par exemple, un système basé sur des microservices qui recouvre plusieurs services et utilise la validation des jetons pour chaque service n’est pas une solution viable. Ce système affecterait l’agilité du système global et le potentiel d’introduction de la dérive d’implémentation entre les services.

Les problèmes de sécurité sont généralement gérés par la passerelle API et le pare-feu d’application. La passerelle et le pare-feu acceptent les requêtes entrantes, valident les jetons et appliquent différents filtres et stratégies, tels que l’implémentation des 10 principes OWASP majeurs pour intercepter le trafic. Enfin, ils envoient la requête aux microservices back-end. Cette configuration permet aux développeurs de se concentrer sur les besoins de l’entreprise plutôt que sur la préoccupation transversale que représente la sécurité.

Tenez compte de ces facteurs :

  • L’authentification et l’autorisation sont-elles requises pour le service ?
  • Utilisez-vous une passerelle API pour valider les jetons et les requêtes entrantes ?
  • Utilisez-vous SSL ou mTLS pour assurer la sécurité de la communication avec le service ?
  • Avez-vous des stratégies de sécurité réseau en place pour autoriser la communication requise entre les services ?
  • Utilisez-vous des pare-feux (L4, L7) le cas échéant, pour assurer la sécurité des communications internes et externes ?
  • Utilisez-vous des stratégies de sécurité dans la passerelle API pour contrôler le trafic ?

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes