Cet article vous présente les concepts généraux relatifs à la migration d'un site Web depuis une plate-forme monolithique vers une plate-forme de microservices refactorisée et basée sur des conteneurs sur Google Cloud. La migration est effectuée fonctionnalité par fonctionnalité, évitant ainsi un événement de migration à grande échelle et les risques qui en découlent. Cet article est destiné aux informaticiens responsables d’un site Web complexe hébergé sur une plate-forme monolithique qu’ils souhaitent moderniser. La lecture de cet article ne nécessite pas une connaissance approfondie de Google Cloud ou de Kubernetes.
L'objectif d'une telle migration est de fournir un environnement plus agile et évolutif pour les fonctionnalités individuelles du site, dans lequel celles-ci peuvent être plus facilement gérées et mises à jour que si elles faisaient partie de la plate-forme monolithique. L'exécution dans un tel environnement entraîne des améliorations plus rapides pour chaque fonctionnalité migrée, offrant aux utilisateurs une valeur ajoutée tout au long du processus.
Cet article utilise des sites Web d'e-commerce comme exemples de charge de travail. De nombreux sites Web d'e-commerce sont construits avec des plates-formes monolithiques et propriétaires. Ils constituent donc de bons candidats pour la migration décrite ici. Toutefois, vous pouvez appliquer les principes décrits dans cet article à un large éventail de charges de travail. Ils vous seront utiles si vos systèmes et vos contraintes sont suffisamment proches de ceux qui sont décrits ici. Par exemple, les sites Web de réservation d'hôtel ou de location de voiture seraient également de bons candidats pour ce modèle de migration.
Comme indiqué dans le document Migration vers Google Cloud : premiers pas, il existe trois modèles principaux de migration vers le cloud : la migration lift and shift, la migration improve and move et la migration rip and replace. Cet article décrit une version spécifique du modèle de migration Rip and Replace, dans laquelle celui-ci est appliqué de manière incrémentielle à chaque fonctionnalité de l'application plutôt qu'à l'application dans son ensemble.
En plus de ce modèle de migration, l'article aborde deux modèles hybrides. Pendant la migration elle-même, l'application utilise une architecture hybride au sein de laquelle certaines fonctionnalités sont disponibles dans le cloud et d'autres toujours sur site. Une fois la migration terminée, l’application complète est hébergée dans le cloud, mais elle interagit toujours avec les services de backend qui restent sur site.
Terminologie
- application
- Dans cet article, une application est un système logiciel complet, doté potentiellement de nombreuses fonctionnalités, qui est perçu comme une unité unique par les utilisateurs finaux. Par exemple, un site Web d'e-commerce est une application. Toutes les actions qui peuvent être effectuées avec une application sont réalisées à l'aide d'une fonctionnalité spécifique de celle-ci.
- fonctionnalité
- Fonctionnalité particulière d'une application. Une fonctionnalité peut être destinée aux utilisateurs et essentielle au fonctionnement de l'application (comme le panier d'achat d'un site Web d'e-commerce), destinée aux utilisateurs et requise par l'application (comme la connexion) ou interne à l'application (comme la gestion des stocks pour un site Web d'e-commerce).
- service
- Composant autonome d'une application. Dans cet article, une application est composée de différents services invisibles pour les utilisateurs finaux. Par exemple, une base de données utilisée par un site Web est un service.
- application monolithique
- Application construite en tant qu'unité déployable unique (également appelée simplement monolithe), par exemple une application Java EE unique ou une application Web .NET unique. Une application monolithique est souvent associée à une base de données et à une interface utilisateur côté client.
- microservice
- Service unique conçu pour prendre en charge une fonctionnalité de l'application. Dans le modèle de microservices, l’application représente l’agrégation de plusieurs services, chacun ayant un objectif spécifique. Par exemple, un service peut gérer le panier de vos clients, un autre le service de paiement et un autre encore l’interface avec une application backend pour le stock. Ces microservices doivent être faiblement couplés et s'interfacer via des API bien définies. Ils peuvent être écrits dans différents langages et frameworks et comporter des cycles de vie différents.
- architecture hybride
- Architecture dans laquelle vous utilisez un fournisseur de cloud public (tel que Google Cloud) en combinaison avec des ressources privées hébergées dans votre propre centre de données. Il existe de nombreuses raisons et manières de mettre en œuvre une architecture hybride. Celles-ci sont décrites dans l'article Modèles et pratiques hybrides et multicloud.
- services avec état et sans état
- Indication relative au stockage de données effectué directement par un service. Cet article emploie la même définition de "sans état" et "avec état" que la méthodologie de l’application à douze facteurs. Un service est sans état lorsqu'il ne s'appuie sur aucune donnée pour fonctionner. Un service avec état correspond à la situation inverse. Par exemple, un service qui gère les paniers d'achat de vos clients est avec état, car les paniers d'achat doivent être stockés et récupérés. Un service qui vérifie la disponibilité des articles dans le système de backend est sans état. Les données (état) sont stockées par le système de backend et non par le service.
Pourquoi passer aux microservices ?
Décomposer une application en microservices présente les avantages suivants (la plupart d'entre eux proviennent du fait que les microservices sont faiblement couplés) :
- Les microservices peuvent être testés et déployés indépendamment. Plus l'unité de déploiement est petite, plus le déploiement est facile.
- Ils peuvent être mis en œuvre dans différents langages et dans différents frameworks. Vous pouvez choisir la meilleure technologie pour le cas d'utilisation particulier de chaque microservice.
- Ils peuvent être gérés par différentes équipes. La limite entre les microservices permet de dédier une équipe à un ou plusieurs d'entre eux.
- En passant aux microservices, vous assouplissez les dépendances entre les équipes. Chaque équipe ne doit se préoccuper que des API des microservices dont elles dépendent. Elle n’a pas besoin de réfléchir à la manière dont ces microservices sont mis en œuvre, à leurs cycles de publication, etc.
- Vous pouvez concevoir pour les défaillances plus facilement. En établissant des limites claires entre les services, il est plus facile de déterminer la marche à suivre si l'un de ceux-ci ne fonctionne plus.
Les microservices présentent cependant quelques inconvénients par rapport aux monolithes :
- Dans la mesure où une application reposant sur des microservices correspond à un réseau de différents services qui interagissent souvent de manière peu claire, la complexité globale du système tend à augmenter.
- Contrairement aux composants internes d'un monolithe, les microservices communiquent via un réseau. Dans certaines circonstances, cela peut être considéré comme un problème de sécurité. Istio résout ce problème en chiffrant automatiquement le trafic entre les microservices.
- Le même niveau de performance que celui d'une approche monolithique peut être difficile à atteindre en raison des latences entre les services.
- Le comportement de votre système n'est pas causé par un seul service, mais par nombre d'entre eux et par leurs interactions. Pour cette raison, il est plus difficile de comprendre le comportement de votre système en production (son observabilité). Istio constitue également une solution à ce problème.
Alors que certaines entreprises comme Google utilisent des microservices depuis de nombreuses années, le concept (et sa relation avec l'architecture orientée service) a été formalisé par James Lewis, Martin Fowler et Sam Newman dans leur article intitulé Microservices.
Présentation du processus de migration
Le processus de migration décrit dans cet article est long et peut prendre plusieurs mois, car il s’agit d’un projet de grande envergure. Cette section explique comment passer d'une application monolithique sur site à une application entièrement hébergée sur Google Cloud et construite avec des microservices.
Le point de départ : une application monolithique sur site
Cet article suppose que vous exécutez actuellement une application monolithique sur site. Le diagramme d'architecture de haut niveau suivant est probablement semblable à votre architecture actuelle.
Ce diagramme n'est pas destiné à représenter exactement vos systèmes actuels. Certaines des technologies généralement présentes dans une architecture de ce type sont les suivantes :
- Bases de données relationnelles, telles que la base de données Oracle® ou SAP HANA
- Plates-formes d'e-commerce, telles que Oracle ATG ou SAP Hybris
- Apache Solr ou d'autres moteurs de recherche
Le point d'arrivée : une application basée sur des microservices et exécutée sur Google Cloud
Le processus de migration décrit ici est destiné à passer d’une architecture monolithique sur site à une architecture basée sur des microservices et exécutée sur Google Cloud. L'architecture cible se présente comme suit :
Dans l'architecture cible, vous exécutez des microservices dans Google Kubernetes Engine (GKE). Kubernetes est une plate-forme permettant de gérer, d'héberger, de mettre à l'échelle et de déployer des conteneurs, qui constituent un moyen portable d’empaqueter et d’exécuter du code. Ceux-ci sont bien adaptés au modèle de microservices, dans lequel chaque microservice peut être exécuté dans son propre conteneur. Les microservices peuvent appeler vos systèmes de backend via une connexion réseau privée créée par Cloud Interconnect ou Cloud VPN. Vous pouvez également utiliser Apigee pour exposer vos services de backend et en sécuriser l’accès. Pour en savoir plus sur ces produits et sur le choix de l'un d'entre eux, reportez-vous à la section Apigee, Cloud VPN et Cloud Interconnect ci-dessous.
Les microservices peuvent également interagir avec plusieurs autres produits Google Cloud selon leurs besoins. Cloud Storage et Cloud SQL constituent deux des produits Google Cloud les plus courants pour une application d'e-commerce. Pub/Sub peut être utilisé comme service de messagerie entre différents microservices pour les tâches asynchrones.
Vous exposez votre application sur Internet de deux manières : directement via un équilibreur de charge Google Cloud pour des éléments tels que des images, et éventuellement via Apigee pour vos API publiques.
Les tableaux suivants répertorient les produits que vous pouvez utiliser dans votre architecture cible. Tous ne sont pas obligatoires et leur utilisation dépend de votre cas d'utilisation spécifique.
Réseau
| Produit Google Cloud | Utilisation | Notes |
|---|---|---|
| Virtual Private Cloud | Un VPC est un réseau privé défini par logiciel où vos ressources (telles qu'un cluster GKE) résident. Il inclut des fonctionnalités telles que le pare-feu et le routage. Un VPC est disponible dans le monde entier, permettant une connectivité privée à travers le monde via les réseaux de fibre optique appartenant à Google. | Cloud VPC est obligatoire pour cette architecture. |
| Cloud Interconnect | Cloud Interconnect étend votre réseau sur site au réseau de Google via une connexion hautement disponible et à faible latence. Vous pouvez utiliser une interconnexion dédiée pour vous connecter directement à Google, ou passer par une interconnexion partenaire pour vous connecter à Google via un fournisseur de services compatible. | Votre site Web d'e-commerce doit probablement appeler des services de backend sur site tels qu'un système de gestion d'entrepôt ou un système de facturation. Cloud Interconnect constitue l'une des solutions permettant cela. |
| Cloud VPN | Cloud VPN étend de manière sécurisée votre réseau sur site au réseau de Google via un tunnel VPN IPsec. Le trafic est chiffré et acheminé entre les deux réseaux via le réseau Internet public. Cloud VPN est utile pour les connexions de données à faible volume. | Votre site Web d'e-commerce doit probablement appeler des services de backend sur site tels qu'un système de gestion d'entrepôt ou un système de facturation. Cloud VPN constitue l'une des solutions permettant cela. |
| Cloud Load Balancing | Cloud Load Balancing est la solution d'équilibrage de charge gérée de Google. Elle est compatible avec les équilibrages de charge L4 (TCP/UDP) et L7 (HTTP). Elle peut également servir de point de terminaison SSL (HTTPS). La création d'un équilibreur de charge Google Cloud vous attribue une adresse IP Anycast unique. Tous les utilisateurs qui tentent d'accéder à cette adresse IP sont automatiquement routés vers le point de présence Google le plus proche, avec un temps de latence plus faible, grâce au réseau Niveau Premium de Google. | Cloud Load Balancing est obligatoire pour cette architecture. |
| Cloud CDN | Cloud CDN (réseau de diffusion de contenu) utilise des points de présence distribués à l'échelle mondiale par Google pour mettre en cache le contenu à équilibrage de charge HTTP(S) à proximité de vos utilisateurs. La mise en cache de contenu à la périphérie du réseau de Google accélère la diffusion du contenu aux utilisateurs tout en réduisant les coûts de diffusion. | Cloud CDN n'est pas obligatoire dans ce scénario, mais il est recommandé, en particulier pour le contenu statique. |
Plate-forme
| Produit Google Cloud | Utilisation | Notes |
|---|---|---|
| Google Kubernetes Engine (GKE) | GKE est le produit Kubernetes géré de Google permettant de déployer des applications en conteneurs. GKE est entièrement compatible avec Kubernetes Open Source et fournit de nombreuses fonctionnalités avancées, telles que des clusters régionaux pour une haute disponibilité, des clusters privés, l'autoscaling vertical des pods, l'autoscaling des clusters, les GPU et les nœuds préemptifs. | GKE est obligatoire pour cette architecture. |
| Istio | Istio simplifie la gestion des déploiements de microservices en offrant une méthode uniforme pour sécuriser, connecter et surveiller ces derniers. | Istio n'est pas obligatoire dans cette architecture, mais fournit des fonctionnalités utiles telles que la surveillance améliorée, le chiffrement du trafic et le routage, ainsi que l'injection de pannes pour tester la résilience de votre application. |
| Apigee | Apigee est une passerelle API gérée. Apigee vous permet de concevoir, de publier, de surveiller et de monétiser vos API en toute sécurité. Vous pouvez utiliser Apigee pour exposer des API publiques et privées. Dans une architecture de microservices, les API publiques sont hébergées sur Google Cloud, tandis que les systèmes de backend sur site peuvent être exposés en tant qu'API privées utilisées uniquement par les microservices sur Google Cloud. |
Apigee n'est pas obligatoire pour cette architecture, mais il est recommandé que tous les contenus de votre site soient diffusés par des API publiques. Une passerelle API telle qu'Apigee fournit de nombreuses fonctionnalités pour la gestion des API, telles que les quotas, la gestion des versions et l'authentification. |
| Pub/Sub | Pub/Sub est un système de messagerie et de streaming. S'il est utilisé dans cette architecture, il fonctionne comme un service de messagerie entre les microservices, ce qui permet des workflows asynchrones entre ceux-ci. | Pub/Sub n'est pas obligatoire, mais le modèle éditeur/abonné peut permettre d'atténuer les problèmes de scaling. |
Stockage
| Produit Google Cloud | Utilisation | Notes |
|---|---|---|
| Cloud Storage | Cloud Storage fournit une API de stockage d'objets unifiée. Il convient à de nombreux cas d'utilisation, tels que la diffusion de contenus de sites Web, la sauvegarde et l'archivage de données, et la distribution d'objets volumineux. Dans le cas d'un site Web d'e-commerce, Cloud Storage est principalement utilisé pour stocker et gérer des éléments statiques, tels que des vidéos et des images de produits. | L'évolutivité transparente de Cloud Storage, associée à Cloud CDN, en fait un bon candidat pour l'architecture de microservices décrite dans ce document. Son utilisation est donc recommandée. |
| Firestore | Firestore est une base de données de documents NoSQL rapide et entièrement gérée. | Firestore n'est pas obligatoire pour cette architecture, mais il convient bien à plusieurs cas d'utilisation courants dans les sites d'e-commerce. Par exemple, il peut vous permettre de stocker les paniers d'achats et les métadonnées des utilisateurs. |
| Cloud SQL | Cloud SQL correspond au produit géré de Google pour MySQL et PostgreSQL. Ces bases de données relationnelles proposent un large éventail d'utilisations. | Cloud SQL n'est pas obligatoire dans ce scénario, mais il convient bien à plusieurs cas d'utilisation courants dans les sites d'e-commerce. Par exemple, il peut vous permettre de stocker des commandes, ce qui facilite l'agrégation et les calculs. |
| Cloud Spanner | Spanner est une base de données relationnelle disponible dans le monde entier. Il dispose d'une cohérence forte et d'une évolutivité horizontale. Avec un contrat de niveau de service qui promet un temps de disponibilité de 99,999 % (pour les instances multirégionales), il garantit une très haute disponibilité des données critiques de votre entreprise. | Spanner n'est pas obligatoire dans ce scénario. Parce qu'il s'agit d'une base de données relationnelle offrant une cohérence transactionnelle à l'échelle mondiale, Spanner est bien adapté aux sites d'e-commerce destinés à un public international. |
| Memorystore | Memorystore for Redis constitue une version gérée de Redis, qui est une base de données valeur/clé en mémoire. En tant que base de données à faible temps de latence, Redis convient bien aux données fréquemment consultées. | Memorystore n'est pas obligatoire dans ce scénario, mais il convient bien à plusieurs cas d'utilisation courants pour les sites Web, tels que le stockage des informations de session utilisateur et la fourniture d'un cache d'application. |
Vous pouvez également utiliser d'autres produits Google Cloud, mais cette liste représente les produits les plus couramment utilisés dans une architecture d'e-commerce. Vous devez également considérer le fait qu'une évolution naturelle de cette architecture consiste à ajouter des composants pour recueillir des informations à partir de données en exploitant des produits tels que Cloud BigTable, BigQuery et Vertex AI.
Vous pouvez également continuer à utiliser certaines de vos technologies actuelles dans cette architecture cible, soit parce qu'elles sont toujours pertinentes, soit parce que le coût de leur déplacement est trop élevé. Voici quelques exemples d'exécution des technologies courantes d'e-commerce sur Google Cloud :
- Les partenaires Google Cloud peuvent gérer vos charges de travail Oracle de manière à obtenir une latence inférieure à la milliseconde entre ces charges de travail et votre infrastructure Google Cloud. Cela vous permet également de réutiliser vos licences existantes.
- Grâce au partenariat entre SAP et Google Cloud, vous pouvez exécuter une large gamme de charges de travail SAP sur Google Cloud, par exemple HANA et Hybris.
- Vous pouvez exécuter Apache Solr sur GKE ou utiliser certaines des solutions Solr disponibles sur Google Cloud Marketplace.
- Vous pouvez exécuter Elasticsearch sur GKE (par exemple à l'aide de la solution Cloud Marketplace) ou utiliser le service géré par Elastic basé sur Google Cloud.
Apigee, Cloud VPN et Cloud Interconnect
L'une des décisions les plus importantes que vous devez prendre dès le début de ce projet se rapporte à la gestion de la communication entre les nouveaux microservices hébergés sur GKE et votre ancien système sur site. Il existe deux solutions principales, qui peuvent coexister : une communication basée sur des API et une communication basée sur une connexion privée.
Dans le cas de la solution basée sur des API, vous utilisez une solution de gestion des API telle qu'Apigee en tant que proxy entre les deux environnements. Cela vous accorde un contrôle précis sur les parties de vos anciens systèmes que vous exposez et sur la manière dont vous les exposez. Vous pouvez ainsi également refactoriser de manière transparente la mise en œuvre d'une API (c'est-à-dire passer d'un ancien service à un microservice) sans en affecter les consommateurs. Le diagramme suivant illustre les interactions entre Apigee, vos systèmes sur site et vos systèmes Google Cloud.
Les modèles de déploiement des API Kubernetes à grande échelle avec Apigee et l'e-book Apigee Beyond ESB Architecture with APIs peut vous aider dans cette conception.
Dans une solution basée sur la connectivité privée, vous connectez votre environnement Google Cloud et vos environnements sur site à l'aide d'une connexion réseau privée. Les microservices communiquent avec vos anciens systèmes via cette connexion. Vous pouvez configurer des tunnels VPN basés sur IPSec avec Cloud VPN. Cloud Interconnect fournit une connexion hautement disponible et à faible latence pour les besoins en bande passante plus importants. Consultez la page Choisir un type d'interconnexion pour obtenir un aperçu des différentes options.
Le diagramme suivant illustre les interactions entre vos systèmes sur site et vos systèmes Google Cloud via Cloud VPN ou Cloud Interconnect.
Une solution basée sur des API est mise en œuvre par les équipes dédiées aux applications. Dès le début du projet, une telle solution nécessite une plus grande intégration avec l'ancienne application qu'une solution basée sur la connectivité privée. Cependant, une solution basée sur des API offre davantage d'options de gestion à long terme. Une solution basée sur Cloud VPN ou Cloud Interconnect est mise en œuvre par une équipe chargée de la mise en réseau, et nécessite initialement moins d'intégration avec l'ancienne application. Cependant, elle n’apporte aucune valeur ajoutée à long terme.
Processus de migration
Cette section décrit les grandes étapes que vous devez suivre pour migrer vers la nouvelle architecture.
Prérequis
Avant de déplacer le premier microservice vers GKE, vous devez préparer l'environnement Google Cloud dans lequel vous travaillerez. Effectuez les actions suivantes avant de mettre votre premier microservice en production sur GKE :
- Configurez votre organisation Google Cloud, qui correspond à l’environnement global qui hébergera vos ressources Google Cloud. Dans le cadre de cette étape, vous configurez également vos identités Google, c'est-à-dire les comptes dont les employés de votre entreprise ont besoin pour utiliser les produits Google. Pour en savoir plus, consultez la page Décider comment intégrer les identités à Google Cloud.
- Concevez vos règles Google Cloud pour le contrôle des ressources Google Cloud. L'article Concevoir des règles pour les entreprises clientes peut vous y aider.
- Créez un plan pour déployer vos ressources Google Cloud, y compris les clusters GKE, en utilisant l'infrastructure en tant que code (IaC). Vous obtiendrez ainsi des environnements normalisés, reproductibles et contrôlables. Cloud Deployment Manager ou Terraform sont recommandés à cet effet.
- Étudiez les différentes fonctionnalités de GKE et modifiez-les au besoin. Pour une application stratégique, vous pouvez modifier certaines des valeurs par défaut et renforcer vos clusters. La section Renforcer la sécurité d'un cluster contient des informations sur la procédure à suivre.
- Construisez vos outils d'intégration continue/de livraison continue (CI/CD) pour Kubernetes. Vous pouvez utiliser Cloud Build pour créer vos images de conteneur et Container Registry pour stocker celles-ci et détecter les failles. Vous pouvez également combiner ces produits avec vos outils de CI/CD existants. Profitez de ces tâches pour mettre en œuvre les bonnes pratiques pour la construction et l’exploitation des conteneurs. Effectuer cela en début de projet vous permettra d'éviter les problèmes lorsque vous serez en production.
- Selon l'option choisie, configurez votre compte Apigee ou une connexion privée entre Google Cloud et votre centre de données sur site avec Cloud VPN ou Cloud Interconnect.
Migrer par étapes
Vous devez migrer les fonctionnalités de votre site Web d'e-commerce vers le nouvel environnement une par une, en créant des microservices si nécessaire. Ceux-ci peuvent rappeler l'ancien système en cas de besoin.
Cette approche équivaut à transformer ce projet majeur de migration et de refactorisation en plusieurs petits projets. Procéder de cette manière présente les deux avantages suivants :
- Chaque petit projet est plus facilement délimité et plus facile à traiter que le projet de migration global. La migration de l’ensemble du site Web en une seule fois exige des équipes qu’elles comprennent mieux les interactions entre systèmes, les contraintes, les systèmes tiers qui dépendent de la disponibilité du site Web, etc. Cela augmente donc le risque d'erreurs.
- Disposer d'un grand nombre de projets plus petits vous apporte une certaine flexibilité. Si votre équipe est plus petite, elle peut s'attaquer à ces projets les uns après les autres sans être submergée. Si vous avez plusieurs équipes, vous pourrez peut-être exécuter une partie du travail en parallèle et mener plusieurs migrations à la fois.
Le choix des fonctionnalités à migrer et du moment de leur migration constitue l’une des décisions les plus importantes que vous devrez prendre au cours de cette étape du projet. Lorsque vous prenez cette décision, vous devez tenir compte du réseau de dépendances entre les fonctionnalités. Certaines fonctionnalités peuvent fortement dépendre des autres pour fonctionner correctement, alors que d'autres peuvent être assez indépendantes. Plus le nombre de dépendances d'une fonctionnalité est faible, plus sa migration est facile. La question des dépendances, ainsi que d'autres facteurs à prendre en compte lorsque vous décidez de la fonctionnalité à migrer, est traitée plus en détail ci-après dans la section Quelles fonctionnalités devez-vous migrer en premier ?.
Exemple : Migrer un panier d'achat
Pour illustrer le processus de migration, cette section décrit la migration d'une fonctionnalité unique, à savoir le panier d'achat d'un site Web d'e-commerce.
Pour comprendre les dépendances de cette fonctionnalité, considérons un parcours utilisateur typique et sa mise en œuvre dans une application monolithique :
- L'utilisateur parcourt le site Web et trouve un article qui l'intéresse.
- Il clique sur Ajouter à mon panier. Cette action déclenche un appel d'API du navigateur de l'utilisateur vers la fonctionnalité de panier d'achat. Il s'agit de la première dépendance : l'interface agit sur le panier.
- Lorsque la fonctionnalité de panier d'achat reçoit l'appel, elle vérifie si l'article est en stock. Cet événement déclenche un appel d'API de la fonctionnalité de panier d'achat au système qui gère les stocks. Il s’agit de la deuxième dépendance : le panier d'achat dépend du sous-système de stock.
- Si l'article est en stock, la fonctionnalité de panier d'achat enregistre des informations telles que "le panier de l'utilisateur A contient 1 instance de l'article X". Il s'agit de la troisième dépendance : le panier a besoin d'une base de données pour stocker ces informations.
- Lorsque l'utilisateur passe la commande et effectue le processus de paiement, le sous-système de paiement interroge le panier d'achat pour en calculer le total. Lorsque le paiement est terminé, le sous-système de paiement demande à la fonctionnalité de panier d'achat de vider le panier. Il s'agit de la quatrième dépendance : le panier est interrogé par le sous-système de paiement.
En résumé, la fonctionnalité de panier d'achat est appelée par l'interface et le sous-système de paiement, et elle interroge une base de données et le sous-système de stock.
Une base de données de documents est bien adaptée au stockage de paniers d'achat. Vous n'avez pas besoin de la puissance des bases de données relationnelles pour les données des paniers d'achat, et ceux-ci peuvent facilement être indexés par les ID utilisateur. Firestore est une base de données de documents NoSQL gérée et sans serveur. Elle convient particulièrement à ce cas d'utilisation. Il s'agit donc du datastore suggéré pour l'architecture cible.
Vous pouvez migrer les données du panier d'achat de plusieurs manières (cette question est traitée plus en détail ci-après dans la section Stratégies de migration des données). Ce document suppose que l'approche de maintenance planifiée décrite ci-dessous est acceptable. Dans ces conditions, vous pouvez migrer la fonctionnalité de panier d'achat en procédant comme suit :
- Créez un microservice qui met en œuvre une API de panier d'achat. Utilisez Firestore pour stocker les paniers. Assurez-vous que ce nouveau microservice peut appeler le sous-système de stock.
- Créez un script qui extrait les paniers d'achat de votre ancien sous-système et les écrit dans Firestore. Écrivez le script de façon à ce qu'il puisse être réexécuté autant de fois que nécessaire et qu'il ne copie que les paniers d'achat modifiés depuis la dernière exécution.
- Créez un script qui accomplit le processus inverse : il doit copier les paniers depuis Firestore vers votre ancien système. Vous n'utiliserez ce script que si vous devez effectuer un rollback de la migration.
- Exposez l'API de panier d'achat avec Apigee.
- Préparez et testez les modifications apportées à l'interface et au sous-système de paiement afin qu’ils puissent appeler votre nouveau microservice de panier d'achat.
- Exécutez le script de migration de données que vous avez créé à l'étape 2.
- Faites passer votre site Web en mode de maintenance.
- Relancez le script de migration de données.
- Déployez les modifications de l'étape 5 sur votre ancien système de production.
- Désactivez le mode de maintenance de votre site Web.
La fonctionnalité de panier d'achat de votre site Web est maintenant un microservice hébergé sur Google Cloud. L'étape 5 est probablement l'étape la plus difficile de ce processus, car elle nécessite de modifier le système existant. Toutefois, cette étape devient plus facile à mesure que vous migrez davantage de fonctionnalités vers les microservices, car un nombre croissant de dépendances sera déjà constitué de microservices. En tant que telles, elles sont plus faiblement couplées que dans une application monolithique, et elles sont plus faciles à modifier et à déployer.
En guise de migration alternative, vous pouvez demander au nouveau microservice de rappeler la base de données de panier d'achat d'origine, puis migrer les données vers Firestore. Pour choisir entre ces deux modèles de migration, prenez en compte la latence entre le microservice et la base de données d'origine, la complexité de la refactorisation du schéma et la stratégie de migration des données que vous souhaitez adopter.
Quelles fonctionnalités devez-vous migrer en premier ?
Cette section vous aide à identifier les fonctionnalités à migrer en premier, c'est-à-dire l’effort de migration initial. Une approche "diviser pour mieux régner" est toujours préférable afin de réduire les risques inhérents aux migrations complexes.
Lorsque vous planifiez votre migration, il est tentant de commencer par les fonctionnalités les plus simples à migrer. Si cette simplicité présente un avantage, ce n'est peut-être pas la meilleure expérience d'apprentissage pour votre équipe. Au lieu de passer directement à la migration, vous devriez prendre le temps d'évaluer toutes les fonctionnalités et de créer des plans pour leur migration.
Vous pouvez utiliser la liste suivante de zones d’évaluation comme cadre pour effectuer votre analyse fonctionnalité par fonctionnalité :
- Processus métier
- Conception et développement
- Opérations
- Collaborateurs et équipes
Évaluer les processus métier
Les processus seront appris et développés par l'équipe de migration pendant les efforts de migration initiaux, et il est probable que des erreurs se produiront. C'est pourquoi les efforts de migration initiaux ne doivent pas impliquer des systèmes critiques pour l'entreprise (pour éviter tout impact sur les opérations principales), mais représenter des cas d'utilisation significatifs (et offrir à l'équipe une opportunité d'apprentissage). Lorsque vous évaluez des processus métier, tenez également compte des processus liés à la conformité et à la gestion des licences, et pas seulement des processus de développement.
Évaluer la conception et le développement
Du point de vue de la conception et du développement, les efforts de migration initiaux idéaux sont ceux qui présentent le moins de dépendances par rapport à d'autres fonctionnalités et données, et qui sont les plus faciles à refactoriser si nécessaire.
Vous devez analyser chaque fonctionnalité en tenant compte de ses dépendances et des efforts nécessaires à la refactorisation. Pour analyser les dépendances de chaque fonctionnalité, examinez les éléments suivants :
- Le type de dépendance : dépendances par rapport à des données ou d'autres fonctionnalités
- L'échelle de dépendance : le nombre de fonctionnalités pouvant être affectées par une modification des dépendances de cette fonctionnalité
La migration d'une fonctionnalité présentant de fortes dépendances de données n'est généralement pas une tâche triviale pour les raisons suivantes :
- Si vous décidez de migrer les fonctionnalités tout d'abord, puis les données associées, vous devez tenir compte de la latence accrue du réseau entre les producteurs, les consommateurs et les datastores après l'effort de migration initial.
- Des problèmes de synchronisation et d'intégrité des données se poseront lors de la phase de migration, car il est possible que vous lisiez et écriviez temporairement des données sur plusieurs emplacements.
La quantité de refactorisation nécessaire pour chaque fonctionnalité constitue une autre évaluation. La refactorisation potentielle dépend à la fois de la conception actuelle de la fonctionnalité et de son orientation future. Dans votre estimation, réfléchissez à l'impact que cet effort pourrait avoir sur les processus métier associés.
Voici les questions les plus importantes auxquelles vous devez répondre lors de cette évaluation :
- Quelles données cette fonctionnalité utilise-t-elle ?
- Quel volume de données cette fonctionnalité utilise-t-elle ?
- Cette fonctionnalité nécessite-t-elle d'autres fonctionnalités pour fonctionner correctement ?
- Combien d'autres fonctionnalités sont-elles affectées par une modification de cette fonctionnalité ?
- Cette fonctionnalité présente-t-elle des exigences en matière de réseau ou de connectivité ?
- De quelle manière la conception actuelle de cette fonctionnalité affecte-t-elle la refactorisation ?
Évaluer les opérations
Du point de vue des opérations, vous devez également prendre en compte les fonctionnalités qui peuvent se permettre le temps d'arrêt d’un intervalle de basculement. Si vous devez minimiser les temps d'arrêt, la migration de fonctionnalités nécessitant une haute disponibilité peut requérir un travail supplémentaire.
Évaluer les collaborateurs et les équipes
De préférence, choisissez des équipes disposant de processus bien définis pour diriger les efforts de migration initiaux. De plus, les équipes doivent être disposées à ouvrir la voie à la migration et comprendre qu’elles feront face à de nouveaux défis auxquels elles devront trouver des solutions.
Choisir un effort de migration initial
Selon ce cadre d'évaluation et dans l'idéal, l'effort de migration initial doit être suffisamment ambitieux pour être significatif, mais suffisamment simple pour minimiser le risque d'échec. Le processus de migration initial doit également :
- nécessiter peu de refactorisation, en tenant compte à la fois de la fonctionnalité elle-même et des processus métier associés ;
- être sans état, c'est-à-dire ne pas présenter d'exigences de données externes ;
- présenter peu ou pas de dépendances.
Exemple de plan de migration
La liste suivante présente un exemple d'ordre de migration :
- Interface de plate-forme, c'est-à-dire interface utilisateur
- Fonctionnalités sans état, telles qu'un service de conversion de devises
- Fonctionnalités présentant des ensembles de données indépendants (ensembles de données ne dépendant pas d'autres ensembles de données), tels qu'un service permettant de répertorier vos magasins physiques
- Fonctionnalités présentant des ensembles de données partagés : la logique métier de la plate-forme d'e-commerce
Interface de plate-forme et fonctionnalités sans état
Les interfaces de plate-forme et les fonctionnalités sans état présentent généralement peu de dépendances. Elles constituent toutes deux des candidates idéales pour la migration initiale, car elles ne correspondent pas à des composants triviaux de l'architecture. Elles requièrent une refactorisation limitée, car, dans la phase de migration initiale, l'API de backend est toujours diffusée à partir de l'ancien centre de données ou de l'environnement d'exécution hébergé par un autre fournisseur cloud.
Dans le cas des fonctionnalités d'interface de plate-forme et des fonctionnalités sans état, concentrez-vous sur le pipeline d'intégration et de déploiement. Étant donné que vos charges de travail GKE doivent être conteneurisées, vous devrez peut-être effectuer un travail plus opérationnel.
Fonctionnalités présentant des ensembles de données indépendants
Les composants suivants à migrer sont les fonctionnalités dont les ensembles de données sont indépendants des autres ensembles de données. Ces ensembles de données indépendants sont plus faciles à extraire de votre ancien système que ceux qui présentent des dépendances (bien entendu, par rapport à la migration de fonctionnalités sans état, la migration de fonctionnalités comportant des ensembles de données indépendants nécessite un travail supplémentaire, à savoir la création et la gestion du nouveau datastore ainsi que la migration des données).
Lorsque vous planifiez la migration des données, vous avez le choix entre plusieurs systèmes de stockage. Parce que vous souhaitez moderniser vos applications, vous pouvez utiliser les éléments suivants :
- Des services de stockage de données gérés tels que Cloud Storage ou Filestore pour stocker des fichiers
- Cloud SQL pour migrer les données à partir d'un SGBDR
- Firestore pour migrer les données à partir d'une base de données NoSQL
Fonctionnalités présentant des ensembles de données partagés
Les fonctionnalités présentant des ensembles de données partagés sont les plus difficiles à migrer. En effet, comme nous le verrons plus tard, la migration des données est une tâche difficile en raison des exigences de cohérence, de distribution, d'accès et de latence.
Stratégies de migration des données
Pour en savoir plus sur les approches de migration de données, consultez la page Approches de migration de données.
Bonnes pratiques pour les microservices
Les sections suivantes incluent un ensemble de bonnes pratiques à suivre lors de la conception, de l’écriture et du déploiement de microservices.
Concevoir des microservices
Lorsque vous concevez vos microservices, suivez un modèle qui vous permette de déterminer correctement le contexte et les limites de chaque microservice. Cela vous évite une fragmentation inutile de vos charges de travail liées aux microservice. Cela vous permet également de définir un contexte (ou domaine) précis dans lequel vos microservices sont valides. La conception Domain-Driven Design (DDD) constitue un exemple d'un tel modèle.
Contrats d'API
Chaque microservice ne doit être appelé qu'à partir d'un ensemble d'interfaces. Chaque interface doit à son tour être clairement définie par un contrat pouvant être mis en œuvre à l'aide d'un langage de définition d'API tel que la spécification OpenAPI Initiative (anciennement Swagger ou RAML). Disposer d'interfaces et de contrats d'API bien définis vous permet de développer des tests en tant que composant principal de votre solution (par exemple, en appliquant un développement piloté par les tests) par rapport à ces interfaces API.
Gérer les modifications
Si vous devez introduire des modifications importantes dans vos contrats d'API, vous devez vous préparer à l'avance afin de minimiser les efforts de refactorisation qui seront nécessaires pour que les clients puissent faire face aux modifications. Voici deux manières de traiter ce problème :
- Gestion des versions
- Mise en place d'un nouveau microservice
Gestion des versions
Pour plus de flexibilité dans la gestion des mises à jour susceptibles d'apporter des modifications destructives aux clients existants, vous devez mettre en œuvre un schéma de gestion des versions pour vos microservices. La gestion des versions vous permet de déployer les versions mises à jour d'un microservice sans pour autant affecter les clients utilisant une version existante. Si vous utilisez la gestion des versions, vous devez créer une nouvelle version chaque fois que vous apportez une modification qui rompt toute partie d'un contrat existant, même si la modification est minime.
Vous pouvez mettre en œuvre un schéma de gestion des versions à l'aide des schémas suivants :
- Gestion des versions globale
- Gestion des versions des ressources
Lorsque vous mettez en œuvre un schéma de gestion des versions globale, vous indiquez que vous gérez les versions de l'ensemble de l’API. L'une des mises en œuvre consiste à générer les informations de version dans les URI de ressource, comme suit :
/api/v1/entities or api.v3.domain.tld/entities
Ce type de schéma de gestion des versions est facile à déployer, car la gestion des versions est centralisée. Cependant, il n'est pas aussi flexible qu'un schéma de gestion des versions de ressources. Pour obtenir un exemple de schéma de gestion des versions global, reportez-vous au schéma de gestion des versions d'API Kubernetes.
Un schéma de gestion des versions des ressources vous permet de mettre à jour indépendamment chaque ressource diffusée par votre microservice. Pour une flexibilité maximale, vous pouvez même mettre à jour une ressource donnée en fonction de l'opération effectuée sur cette ressource (par exemple, le verbe HTTP). Vous pouvez mettre en œuvre ce schéma de gestion des versions de différentes manières. Vous pouvez par exemple utiliser des URI ou des en-têtes de requête HTTP personnalisés ou standards, comme suit :
Accept: application/tld.domain.entities.v2+json
Un schéma de gestion des versions de ressources peut se révéler plus difficile à concevoir qu'un schéma de gestion des versions globale, car vous avez besoin d'une approche généralisée pour toutes vos entités. Toutefois, cette solution est plus flexible, car vous pouvez mettre en œuvre différentes règles de mise à jour indépendantes pour vos ressources.
Mettre en place un nouveau microservice
Une autre approche permettant de faire face aux modifications destructives consiste à mettre en œuvre un nouveau microservice doté d’un nouveau contrat. Cette approche peut être utile si la nouvelle version du microservice nécessite tellement de modifications qu'il est plus logique d'écrire une nouvelle version que de mettre à jour la version existante. Bien que cette approche offre une flexibilité maximale, elle peut présenter des microservices comportant des fonctionnalités et des contrats qui se chevauchent. Après avoir mis en œuvre le nouveau microservice, vous pouvez progressivement refactoriser les clients pour qu'ils utilisent celui-ci et migrent depuis l’ancien microservice.
Étape suivante
- En savoir plus sur GKE Enterprise
- Commencer à utiliser GKE
- Modèles de déploiement des API Kubernetes à grande échelle avec Apigee
- Préparer la production pour le Black Friday
- Effectuer une migration de données entre Cloud SQL et des serveurs externes
- Consultez la page sur nos solutions pour les charges de travail relatives au secteur du commerce.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.