Migrer depuis AWS vers Google Cloud: migrer d'AWS Lambda vers Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud fournit des outils, des produits, des conseils et des services professionnels pour vous aider à migrer des charges de travail sans serveur depuis Amazon Web Services (AWS) Lambda vers Google Cloud. Bien que Google Cloud propose plusieurs services sur lesquels vous pouvez développer et déployer des applications sans serveur, ce document se concentre sur la migration vers Cloud Run, un environnement d'exécution sans serveur. AWS Lambda et Cloud Run présentent des similitudes, comme le provisionnement automatique des ressources, l'ajustement par le fournisseur de services cloud et un modèle de tarification basé sur l'utilisation.

Ce document vous aide à concevoir, implémenter et valider un plan de migration des charges de travail sans serveur d'AWS Lambda vers Cloud Run. De plus, il offre des conseils aux personnes qui évaluent les avantages potentiels et le processus d'une telle migration.

Ce document fait partie d'une série d'articles sur la migration depuis AWS vers Google Cloud, qui comprend les documents suivants :

Pour en savoir plus sur le choix de l'environnement d'exécution sans serveur adapté à votre logique métier, consultez la section Sélectionner un environnement d'exécution de conteneur géré. Pour obtenir un mappage complet entre les services AWS et Google Cloud, consultez la comparaison des services AWS et Azure aux services Google Cloud.

Pour cette migration vers Google Cloud, nous vous recommandons de suivre le framework de migration décrit dans la section Migrer vers Google Cloud : premiers pas.

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases.

Vous pouvez migrer depuis votre environnement source vers Google Cloud dans une série d'itérations. Par exemple, vous pouvez commencer par migrer certaines charges de travail, et en migrer d'autres ultérieurement. Pour chaque itération de migration distincte, vous suivez les phases du framework de migration général :

  1. Évaluer et découvrir vos charges de travail et vos données
  2. Planifier et établir vos fondations sur Google Cloud
  3. Migrer vos charges de travail et vos données vers Google Cloud
  4. Optimiser votre environnement Google Cloud

Pour en savoir plus sur les phases de ce framework, consultez la page Migrer vers Google Cloud : premiers pas.

Pour concevoir un plan de migration efficace, nous vous recommandons de valider chaque étape du plan et de vous assurer de disposer d'une stratégie de rollback. Pour vous aider à valider votre plan de migration, consultez la page Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

La migration des charges de travail sans serveur ne se limite souvent pas à déplacer des fonctions d'un fournisseur de services cloud à un autre. Étant donné que les applications cloud reposent sur un réseau de services interconnectés, la migration d'AWS vers Google Cloud peut nécessiter de remplacer les services AWS dépendants par des services Google Cloud. Prenons l'exemple d'un scénario dans lequel votre fonction Lambda interagit avec Amazon SQS et Amazon SNS. Pour migrer cette fonction, vous devrez probablement adopter Pub/Sub et Cloud Tasks pour obtenir une fonctionnalité similaire.

La migration vous offre également l'occasion de revoir en détail l'architecture et les décisions de conception de votre application sans serveur. Cet examen peut vous permettre de découvrir des opportunités pour:

  • Optimisez avec les fonctionnalités intégrées de Google Cloud: découvrez si les services Google Cloud offrent des avantages uniques ou s'ils correspondent mieux aux exigences de votre application.
  • Simplifiez votre architecture: évaluez si vous pouvez simplifier en regroupant des fonctionnalités ou en utilisant les services différemment dans Google Cloud.
  • Améliorer l'efficacité des coûts: évaluez les différences de coût potentielles entre l'exécution de votre application refactorisée sur l'infrastructure fournie sur Google Cloud et l'exécution sur l'infrastructure fournie sur Google Cloud.
  • Améliorez l'efficacité du code: refactorisez votre code en parallèle du processus de migration.

Planifiez votre migration de manière stratégique. Ne considérez pas votre migration comme un exercice de rehosting (lift and shift). Profitez de votre migration pour améliorer la conception et la qualité du code globaux de votre application sans serveur.

Évaluer l'environnement source

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour migrer votre environnement source vers Google Cloud.

La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des charges de travail que vous souhaitez migrer, de leurs exigences, de leurs dépendances et de votre environnement actuel. Vous devez comprendre votre point de départ pour planifier et exécuter avec succès une migration Google Cloud.

La phase d'évaluation comprend les tâches suivantes :

  1. Dresser un inventaire complet de vos applications
  2. Cataloguer vos charges de travail en fonction de leurs propriétés et de leurs dépendances
  3. Former et préparer vos équipes sur Google Cloud
  4. Créer des tests et des démonstrations de faisabilité sur Google Cloud
  5. Calculer le coût total de possession (TCO) de l'environnement cible
  6. Choisissez la stratégie de migration pour vos charges de travail.
  7. Choisissez vos outils de migration.
  8. Définissez le plan de migration et le calendrier.
  9. Validez votre plan de migration.

Pour en savoir plus sur la phase d'évaluation et ces tâches, consultez la page Migrer vers Google Cloud : évaluer et découvrir vos charges de travail. Les sections suivantes sont basées sur les informations de ce document.

Créer un inventaire de vos charges de travail AWS Lambda

Pour définir le champ d'application de votre migration, vous devez créer un inventaire et collecter des informations sur vos charges de travail AWS Lambda.

Pour créer l'inventaire de vos charges de travail AWS Lambda, nous vous recommandons d'implémenter un mécanisme de collecte de données basé sur les API AWS, les outils pour les développeurs AWS et l'interface de ligne de commande AWS.

Après avoir créé votre inventaire, nous vous recommandons de rassembler des informations sur chaque charge de travail AWS Lambda de l'inventaire. Pour chaque charge de travail, concentrez-vous sur les aspects qui vous aident à anticiper les frictions potentielles. Analysez également cette charge de travail pour comprendre comment vous devrez peut-être la modifier et ses dépendances avant de migrer vers Cloud Run. Nous vous recommandons de commencer par collecter des données sur les aspects suivants de chaque charge de travail AWS Lambda:

  • Le cas d'utilisation et la conception
  • Dépôt de code source
  • Les artefacts de déploiement
  • L'appel, les déclencheurs et les sorties
  • Environnements d'exécution et d'exécution
  • Configuration de la charge de travail
  • Les contrôles d'accès et les autorisations
  • Les exigences de conformité et réglementaires
  • Les processus de déploiement et opérationnels

Cas d'utilisation et conception

La collecte d'informations sur le cas d'utilisation et la conception des charges de travail permet d'identifier une stratégie de migration appropriée. Ces informations vous aident également à déterminer si vous devez modifier vos charges de travail et leurs dépendances avant la migration. Pour chaque charge de travail, nous vous recommandons de procéder comme suit:

  • Obtenez des insights sur le cas d'utilisation spécifique auquel la charge de travail répond et identifiez les dépendances avec d'autres systèmes, ressources ou processus.
  • Analysez la conception et l'architecture de la charge de travail.
  • Évaluez les exigences de latence de la charge de travail.

Dépôt du code source

L'inventaire du code source de vos fonctions AWS Lambda est utile si vous devez refactoriser vos charges de travail AWS Lambda pour les rendre compatibles avec Cloud Run. La création de cet inventaire implique de suivre le codebase, qui est généralement stocké dans des systèmes de contrôle des versions tels que Git ou dans des plates-formes de développement telles que GitHub ou GitLab. L'inventaire de votre code source est essentiel pour vos processus DevOps, tels que les pipelines d'intégration et de développement continus (CI/CD), car ces processus devront également être mis à jour lorsque vous migrerez vers Cloud Run.

Artefacts de déploiement

Savoir quels artefacts de déploiement sont nécessaires à la charge de travail est un autre élément qui vous aide à déterminer si vous devrez peut-être refactoriser vos charges de travail AWS Lambda. Pour identifier les artefacts de déploiement dont la charge de travail a besoin, collectez les informations suivantes:

  • Type de package de déploiement à utiliser pour déployer la charge de travail.
  • Toute couche AWS Lambda contenant du code supplémentaire, comme des bibliothèques et d'autres dépendances.
  • Toutes les extensions AWS Lambda sur lesquelles la charge de travail dépend.
  • Les qualificatifs que vous avez configurés pour spécifier des versions et des alias.
  • Version de la charge de travail déployée.

Appel, déclencheurs et sorties

AWS Lambda est compatible avec plusieurs mécanismes d'appel, tels que les déclencheurs, et différents modèles d'appel, tels que l'appel synchrone et l'appel asynchrone. Pour chaque charge de travail AWS Lambda, nous vous recommandons de collecter les informations suivantes concernant les déclencheurs et les invocations:

  • Les déclencheurs et les mappages de sources d'événements qui appellent la charge de travail.
  • Indique si la charge de travail est compatible avec les invocations synchrones et asynchrones.
  • Les URL de la charge de travail et les points de terminaison HTTP(S).

Vos charges de travail AWS Lambda peuvent interagir avec d'autres ressources et systèmes. Vous devez savoir quelles ressources consomment les sorties de vos charges de travail AWS Lambda et comment ces ressources les consomment. Ces connaissances vous aident à déterminer si vous devez modifier tout ce qui peut dépendre de ces sorties, comme d'autres systèmes ou charges de travail. Pour chaque charge de travail AWS Lambda, nous vous recommandons de collecter les informations suivantes sur les autres ressources et systèmes:

  • Ressources de destination auxquelles la charge de travail peut envoyer des événements.
  • Les destinations qui reçoivent des enregistrements d'informations pour les invocations asynchrones.
  • Format des événements que la charge de travail traite.
  • Comment votre charge de travail AWS Lambda et ses extensions interagissent avec les API AWS Lambda ou d'autres API AWS

Pour fonctionner, vos charges de travail AWS Lambda peuvent stocker des données persistantes et interagir avec d'autres services AWS. Pour chaque charge de travail AWS Lambda, nous vous recommandons de collecter les informations suivantes sur les données et les autres services:

  • Indique si la charge de travail accède à des cloud privés virtuels (VPC) ou à d'autres réseaux privés.
  • Comment la charge de travail stocke-t-elle les données persistantes, par exemple à l'aide d'un stockage de données éphémères et d'Amazon Elastic File System (EFS) ?

Environnements d'exécution et d'exécution

AWS Lambda est compatible avec plusieurs environnements d'exécution pour vos charges de travail. Pour mapper correctement les environnements d'exécution AWS Lambda aux environnements d'exécution Cloud Run, nous vous recommandons d'évaluer les éléments suivants pour chaque charge de travail AWS Lambda:

  • Environnement d'exécution de la charge de travail.
  • Architecture de l'ensemble d'instructions du processeur de l'ordinateur sur lequel la charge de travail s'exécute.

Si vos charges de travail AWS Lambda s'exécutent dans des environnements d'exécution spécifiques à la langue, tenez compte des points suivants pour chaque charge de travail AWS Lambda:

  • Type, version et identifiant unique de l'environnement d'exécution spécifique au langage.
  • Toutes les modifications que vous avez appliquées à l'environnement d'exécution.

Configuration de la charge de travail

Pour configurer vos charges de travail lorsque vous les migrez d'AWS Lambda vers Cloud Run, nous vous recommandons d'évaluer la façon dont vous avez configuré chaque charge de travail AWS Lambda.

Pour chaque charge de travail AWS Lambda, rassemblez les informations sur les paramètres de concurrence et d'évolutivité suivants:

  • Les contrôles de simultanéité.
  • Paramètres d'évolutivité.
  • Configuration des instances de la charge de travail en termes de quantité de mémoire disponible et de durée d'exécution maximale autorisée.
  • Indique si la charge de travail utilise AWS Lambda SnapStart, la simultanéité réservée ou la simultanéité provisionnée pour réduire la latence.
  • Les variables d'environnement que vous avez configurées, ainsi que celles que AWS Lambda configure et sur lesquelles la charge de travail dépend.
  • Les tags et le contrôle des accès basé sur des attributs
  • Machine à états pour gérer les conditions exceptionnelles.
  • Les images de base et les fichiers de configuration (tels que le fichier Dockerfile) des packages de déploiement qui utilisent des images de conteneur.

Contrôles d'accès et autorisations

Dans le cadre de votre évaluation, nous vous recommandons d'évaluer les exigences de sécurité de vos charges de travail AWS Lambda et leur configuration en termes de contrôles et de gestion des accès. Ces informations sont essentielles si vous devez implémenter des contrôles similaires dans votre environnement Google Cloud. Pour chaque charge de travail, tenez compte des points suivants:

  • Rôle et autorisations d'exécution
  • Configuration de la gestion des identités et des accès utilisée par la charge de travail et ses couches pour accéder à d'autres ressources.
  • Configuration de la gestion des identités et des accès utilisée par d'autres comptes et services pour accéder à la charge de travail.
  • Commandes de gouvernance

Exigences de conformité et réglementaires

Pour chaque charge de travail AWS Lambda, assurez-vous de comprendre ses exigences de conformité et réglementaires en procédant comme suit:

  • Évaluez les exigences de conformité et réglementaires que la charge de travail doit respecter.
  • Déterminez si la charge de travail répond actuellement à ces exigences.
  • Déterminez si des exigences futures devront être remplies.

Les exigences de conformité et réglementaires peuvent être indépendantes du fournisseur de services cloud que vous utilisez. Elles peuvent également avoir un impact sur la migration. Par exemple, vous devrez peut-être vous assurer que le trafic de données et de réseau reste dans les limites de certaines zones géographiques, comme l'Union européenne (UE).

Évaluer vos processus de déploiement et opérationnels

Il est essentiel de bien comprendre leur fonctionnement. Ces processus font partie intégrante des pratiques qui préparent et gèrent votre environnement de production et les charges de travail qui y sont exécutées.

Vos processus de déploiement et opérationnels peuvent créer les artefacts dont vos charges de travail ont besoin pour fonctionner. Par conséquent, vous devez collecter des informations sur chaque type d'artefact. Par exemple, un artefact peut être un package du système d'exploitation, un package de déploiement d'application, une image du système d'exploitation, une image de conteneur ou autre.

Outre le type d'artefact, réfléchissez à la façon dont vous effectuez les tâches suivantes :

  • Développez vos charges de travail. Évaluez les processus mis en place par les équipes de développement pour créer vos charges de travail. Par exemple, comment vos équipes de développement conçoivent-elles, codent-elles et testent-elles vos charges de travail ?
  • Générez les artefacts que vous déployez dans votre environnement source. Pour déployer vos charges de travail dans votre environnement source, vous pouvez générer des artefacts déployables, tels que des images de conteneur ou des images de système d'exploitation, ou vous pouvez personnaliser des artefacts existants, tels que des images de système d'exploitation tiers en installant et en configurant des logiciels. La collecte d'informations sur la manière dont vous générez ces artefacts vous permet de vous assurer qu'ils sont adaptés au déploiement dans Google Cloud.

  • Stockez les artefacts. Si vous produisez des artefacts que vous stockez dans un registre d'artefacts dans votre environnement source, vous devez les rendre disponibles dans votre environnement Google Cloud. Pour ce faire, vous pouvez utiliser des stratégies telles que les suivantes :

    • Établir un canal de communication entre les environnements : rendez les artefacts de votre environnement source accessibles depuis l'environnement Google Cloud cible.
    • Refactoriser le processus de compilation des artefacts : effectuez une refactorisation mineure de votre environnement source afin de pouvoir stocker des artefacts à la fois dans l'environnement source et dans l'environnement cible. Cette approche traite votre migration en créant une infrastructure telle qu'un dépôt d'artefacts avant que vous ayez à implémenter des processus de compilation d'artefacts dans l'environnement Google Cloud cible. Vous pouvez mettre en œuvre cette approche directement ou vous appuyer sur l'approche précédente qui consiste à d'abord établir un canal de communication.

    Le fait de disposer d'artefacts disponibles dans les environnements source et cible vous permet de vous concentrer sur la migration sans avoir à implémenter de processus de compilation d'artefacts dans l'environnement Google Cloud cible dans le cadre de la migration.

  • Scanner et signer le code. Dans le cadre de vos processus de compilation d'artefacts, vous pouvez utiliser l'analyse de code pour vous protéger contre les failles courantes et l'exposition involontaire au réseau, et la signature de code pour vous assurer que seul le code approuvé s'exécute dans vos environnements.

  • Déployez des artefacts dans votre environnement source. Après avoir généré des artefacts déployables, vous pouvez les déployer dans votre environnement source. Nous vous recommandons d'évaluer chaque processus de déploiement. L'évaluation permet de s'assurer que vos processus de déploiement sont compatibles avec Google Cloud. Elle vous permet également de comprendre les efforts nécessaires pour refactoriser les processus à terme. Par exemple, si vos processus de déploiement ne fonctionnent qu'avec votre environnement source, vous devrez peut-être les refactoriser pour cibler votre environnement Google Cloud.

  • L'injection d'une configuration d'exécution. Vous pouvez injecter une configuration d'environnement d'exécution pour des clusters, des environnements d'exécution ou des déploiements de charges de travail spécifiques. La configuration peut initialiser des variables d'environnement et d'autres valeurs de configuration telles que des secrets, des identifiants et des clés. Pour vous assurer que vos processus d'injection de configuration d'environnement d'exécution fonctionnent sur Google Cloud, nous vous recommandons d'évaluer la façon dont vous configurez les charges de travail exécutées dans votre environnement source.

  • Journalisation, surveillance et profilage Évaluez les processus de journalisation, de surveillance et de profilage que vous avez mis en place pour surveiller l'état de votre environnement source, les métriques d'intérêt et la façon dont vous consommez les données fournies par ces processus.

  • Authentification Évaluez la façon dont vous vous authentifiez auprès de votre environnement source.

  • Provisionnez et configurez vos ressources. Pour préparer votre environnement source, vous avez peut-être conçu et implémenté des processus de provisionnement et de configuration des ressources. Par exemple, vous pouvez utiliser Terraform avec des outils de gestion de la configuration pour provisionner et configurer des ressources dans votre environnement source.

Terminer l'évaluation

Après avoir créé les inventaires de votre environnement AWS Lambda, effectuez les autres étapes de la phase d'évaluation décrites sur la page Migrer vers Google Cloud: évaluer et découvrir vos charges de travail.

Planifier et établir vos fondations

Au cours de la phase de planification et de compilation, vous provisionnez et configurez l'infrastructure pour effectuer les opérations suivantes :

  • Exécuter vos charges de travail dans votre environnement Google Cloud
  • Se connecter à votre environnement source et à votre environnement Google Cloud pour effectuer la migration

La phase de planification et de compilation est composée des tâches suivantes :

  1. Créez une hiérarchie de ressources.
  2. Configurer Identity and Access Management (IAM) de Google Cloud
  3. Configurer la facturation
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurer la journalisation, la surveillance et les alertes

Pour en savoir plus sur chacune de ces tâches, consultez la section Migrer vers Google Cloud: planifier et créer vos fondations.

Migrer vos charges de travail AWS Lambda

Pour migrer vos charges de travail d'AWS Lambda vers Cloud Run, procédez comme suit:

  1. Concevez, provisionnez et configurez votre environnement Cloud Run.
  2. Si nécessaire, refactorisez vos charges de travail AWS Lambda pour les rendre compatibles avec Cloud Run.
  3. Refactorisez vos processus de déploiement et d'exploitation pour déployer et observer vos charges de travail sur Cloud Run.
  4. Migrez les données dont vos charges de travail AWS Lambda ont besoin.
  5. Validez les résultats de la migration en termes de fonctionnalités, de performances et de coûts.

Pour vous aider à éviter les problèmes lors de la migration et à estimer les efforts nécessaires à celle-ci, nous vous recommandons d'évaluer les similitudes entre les fonctionnalités AWS Lambda et celles de Cloud Run. Les fonctionnalités d'AWS Lambda et de Cloud Run peuvent sembler similaires lorsque vous les comparez. Cependant, les différences de conception et de mise en œuvre des caractéristiques entre les deux fournisseurs cloud peuvent avoir des répercussions significatives sur votre migration depuis AWS Lambda vers Cloud Run. Ces différences peuvent influencer vos décisions de conception et de refactoring, comme indiqué dans les sections suivantes.

Concevoir, provisionner et configurer votre environnement Cloud Run

La première étape de la phase de migration consiste à concevoir votre environnement Cloud Run afin qu'il puisse prendre en charge les charges de travail que vous migrez depuis AWS Lambda.

Pour concevoir correctement votre environnement Cloud Run, utilisez les données que vous avez recueillies lors de la phase d'évaluation sur chaque charge de travail AWS Lambda. Ces données vous aident à effectuer les opérations suivantes:

  1. Choisissez les ressources Cloud Run appropriées pour déployer votre charge de travail.
  2. Concevez la configuration de vos ressources Cloud Run.
  3. Provisionnez et configurez les ressources Cloud Run.

Choisir les bonnes ressources Cloud Run

Pour chaque charge de travail AWS Lambda à migrer, choisissez la ressource Cloud Run appropriée pour déployer vos charges de travail. Cloud Run est compatible avec les ressources principales suivantes:

  • Services Cloud Run: ressource qui héberge un environnement d'exécution conteneurisé, expose un point de terminaison unique et adapte automatiquement l'infrastructure sous-jacente en fonction de la demande.
  • Jobs Cloud Run: ressource qui exécute un ou plusieurs conteneurs jusqu'à la fin.

Le tableau suivant récapitule la correspondance des ressources AWS Lambda avec ces principales ressources Cloud Run:

Ressource AWS Lambda Ressource Cloud Run
Fonction AWS Lambda déclenchée par un événement, comme ceux utilisés pour les sites Web et les applications Web, les API et les microservices, le traitement des données en streaming et les architectures basées sur des événements. Service Cloud Run que vous pouvez appeler avec des déclencheurs.
Fonction AWS Lambda planifiée pour s'exécuter, comme celles pour les tâches en arrière-plan et les tâches par lot. Job Cloud Run qui s'exécute jusqu'à la fin.

En plus des services et des jobs, Cloud Run fournit des ressources supplémentaires qui étendent ces ressources principales. Pour en savoir plus sur toutes les ressources Cloud Run disponibles, consultez le modèle de ressource Cloud Run.

Concevoir la configuration de vos ressources Cloud Run

Avant de provisionner et de configurer vos ressources Cloud Run, vous devez concevoir leur configuration. Certaines options de configuration AWS Lambda, telles que les limites de ressources et les délais avant expiration des requêtes, sont comparables à des options de configuration Cloud Run similaires. Les sections suivantes décrivent les options de configuration disponibles dans Cloud Run pour les déclencheurs de service et l'exécution de tâches, la configuration des ressources et la sécurité. Ces sections mettent également en avant les options de configuration AWS Lambda comparables à celles de Cloud Run.

Déclencheurs de service Cloud Run et exécution de tâches

Les déclencheurs de service et l'exécution des tâches sont les principales décisions de conception que vous devez prendre en compte lorsque vous migrez vos charges de travail AWS Lambda. Cloud Run propose diverses options pour déclencher et exécuter les charges de travail basées sur les événements utilisées dans AWS Lambda. De plus, Cloud Run propose des options que vous pouvez utiliser pour les charges de travail en streaming et les tâches planifiées.

Lorsque vous migrez vos charges de travail, il est souvent utile de commencer par comprendre les déclencheurs et les mécanismes disponibles dans Cloud Run. Ces informations vous aident à comprendre le fonctionnement de Cloud Run. Vous pouvez ensuite utiliser cette compréhension pour déterminer quelles fonctionnalités Cloud Run sont comparables aux fonctionnalités AWS Lambda et quelles fonctionnalités Cloud Run peuvent être utilisées lors du refactoring de ces charges de travail.

Pour en savoir plus sur les déclencheurs de service fournis par Cloud Run, consultez les ressources suivantes:

  • Appel HTTPS : envoyez des requêtes HTTPS pour déclencher des services Cloud Run.
  • Appel HTTP/2 : envoyez des requêtes HTTP/2 pour déclencher des services Cloud Run.
  • WebSockets : connectez les clients à un serveur WebSockets exécuté sur Cloud Run.
  • Connexions gRPC : connectez-vous aux services Cloud Run à l'aide de gRPC.
  • Appel asynchrone : mettez en file d'attente des tâches à l'aide de Cloud Tasks pour qu'elles soient traitées de manière asynchrone par les services Cloud Run.
  • Appel planifié : utilisez Cloud Scheduler pour appeler des services Cloud Run de manière planifiée.
  • Appel basé sur les événements : créez des déclencheurs Eventarc pour appeler des services Cloud Run sur des événements spécifiques au format CloudEvents.
  • Intégration à Pub/Sub : appelez les services Cloud Run à partir d'abonnements push Pub/Sub.
  • Intégration à Workflows : appelez un service Cloud Run à partir d'un workflow.

Pour en savoir plus sur les mécanismes d'exécution des tâches fournis par Cloud Run, consultez les ressources suivantes:

Le tableau suivant vous aidera à comprendre quels mécanismes d'invocation ou d'exécution Cloud Run sont comparables aux mécanismes d'invocation AWS Lambda. Pour chaque ressource Cloud Run que vous devez provisionner, veillez à choisir le mécanisme d'invocation ou d'exécution approprié.

Fonctionnalité AWS Lambda Fonctionnalité Cloud Run
Déclencheur HTTPS (URL de fonction) Appel HTTPS
Déclencheur HTTP/2 (partiellement compatible à l'aide d'une passerelle API externe) Appel HTTP/2 (compatible en mode natif)
WebSockets (compatibles avec une passerelle API externe) WebSockets (compatibles en mode natif)
N/A (connexions gRPC non compatibles) Connexions gRPC
Appel asynchrone Intégration à Cloud Tasks
Appel planifié Intégration à Cloud Scheduler
Déclencheur basé sur les événements dans un format d'événement propriétaire Appel basé sur des événements au format CloudEvents
Intégration d'Amazon SQS et d'Amazon SNS Intégration Pub/Sub
AWS Step Functions Intégration des workflows
Configuration des ressources Cloud Run

Pour compléter les décisions de conception que vous avez prises pour déclencher et exécuter vos charges de travail migrées, Cloud Run est compatible avec plusieurs options de configuration qui vous permettent d'ajuster plusieurs aspects de l'environnement d'exécution. Ces options de configuration se composent de services de ressources et de tâches.

Comme indiqué précédemment, vous pouvez mieux comprendre le fonctionnement de Cloud Run en commençant par comprendre toutes les options de configuration disponibles dans Cloud Run. Cette compréhension vous aide ensuite à comparer les fonctionnalités AWS Lambda à des fonctionnalités Cloud Run similaires, et à déterminer comment refactoriser vos charges de travail.

Pour en savoir plus sur les configurations fournies par les services Cloud Run, consultez les ressources suivantes:

Pour en savoir plus sur les jobs proposés par Cloud Run, consultez les ressources suivantes:

Pour vous aider à comprendre quelles options de configuration Cloud Run sont comparables aux options de configuration AWS Lambda, consultez le tableau suivant. Pour chaque ressource Cloud Run que vous devez provisionner, veillez à choisir les bonnes options de configuration.

Fonctionnalité AWS Lambda Fonctionnalité Cloud Run
Simultanéité provisionnée Nombre minimal d'instances
Simultanéité réservée par instance
(Le pool de simultanéité est partagé entre les fonctions AWS Lambda de votre compte AWS.)		 Nombre maximal d'instances par service
N/A (non compatible, une requête est mappée sur une instance) Requêtes simultanées par instance
N/A (dépend de l'allocation de mémoire) Allocation du processeur
Paramètres d'évolutivité Autoscaling d'instances pour les services
Parallélisme pour les tâches
Configuration de l'instance (processeur, mémoire) Limites de processeur et de mémoire
Temps d'exécution maximal Délai avant expiration des requêtes pour les services
Délai avant expiration des tâches pour les jobs
AWS Lambda SnapStart Optimisation du processeur au démarrage
Variables d'environnement Variables d'environnement
Stockage de données éphémère Installations de volume en mémoire
Connexions Amazon Elastic File System Installations de volumes NFS
Les montages de volumes S3 ne sont pas acceptés Montages de volume Cloud Storage
AWS Secrets Manager dans les charges de travail AWS Lambda Secrets
URL de la charge de travail et points de terminaison HTTP(S) URL attribuées automatiquement
Intégrations Cloud Run avec les produits Google Cloud
Sessions persistantes (à l'aide d'un équilibreur de charge externe) Affinité de session
Qualifiers Révisions

En plus des fonctionnalités listées dans le tableau précédent, vous devez également tenir compte des différences entre la façon dont AWS Lambda et Cloud Run provisionnent des instances de l'environnement d'exécution. AWS Lambda provisionne une seule instance pour chaque requête simultanée. Toutefois, Cloud Run vous permet de définir le nombre de requêtes simultanées qu'une instance peut traiter. Autrement dit, le comportement de provisionnement d'AWS Lambda équivaut à définir le nombre maximal de requêtes simultanées par instance sur 1 dans Cloud Run. Définir le nombre maximal de requêtes simultanées sur plus d'une peut vous faire économiser beaucoup de coûts, car le processeur et la mémoire de l'instance sont partagés par les requêtes simultanées, mais ne sont facturés qu'une seule fois. La plupart des frameworks HTTP sont conçus pour gérer les requêtes en parallèle.

Sécurité et contrôle des accès dans Cloud Run

Lorsque vous concevez vos ressources Cloud Run, vous devez également choisir les contrôles de sécurité et d'accès dont vous avez besoin pour vos charges de travail migrées. Cloud Run est compatible avec plusieurs options de configuration pour vous aider à sécuriser votre environnement et à définir des rôles et des autorisations pour vos charges de travail Cloud Run.

Cette section met en avant les contrôles de sécurité et d'accès disponibles dans Cloud Run. Ces informations vous aident à comprendre comment vos charges de travail migrées fonctionneront dans Cloud Run et à identifier les options Cloud Run dont vous pourriez avoir besoin si vous refactorisez ces charges de travail.

Pour en savoir plus sur les mécanismes d'authentification fournis par Cloud Run, consultez les ressources suivantes:

Pour en savoir plus sur les fonctionnalités de sécurité fournies par Cloud Run, consultez les ressources suivantes:

Le tableau suivant vous aidera à comprendre quels contrôles de sécurité et d'accès Cloud Run sont comparables à ceux disponibles dans AWS Lambda. Pour chaque ressource Cloud Run que vous devez provisionner, veillez à choisir les bons contrôles d'accès et les bonnes fonctionnalités de sécurité.

Fonctionnalité AWS Lambda Fonctionnalité Cloud Run
Contrôle des accès avec AWS Identity and Access Management Contrôle des accès avec IAM de Google Cloud
Rôle d'exécution Rôle IAM de Google Cloud
Limites d'autorisation Autorisations IAM et audiences personnalisées de Google Cloud
Commandes de gouvernance Service de règles d'organisation
Signature de code Autorisation binaire
Accès complet au VPC Contrôles d'accès précis à la sortie du VPC

Provisionner et configurer des ressources Cloud Run

Après avoir choisi les ressources Cloud Run pour déployer vos charges de travail, vous les provisionnez et les configurez. Pour en savoir plus sur le provisionnement de ressources Cloud Run, consultez les ressources suivantes:

Refactoriser les charges de travail AWS Lambda

Pour migrer vos charges de travail AWS Lambda vers Cloud Run, vous devrez peut-être les refactoriser. Par exemple, si une charge de travail basée sur des événements accepte des déclencheurs contenant des événements Amazon CloudWatch, vous devrez peut-être la refactoriser pour qu'elle accepte les événements au format CloudEvents.

Plusieurs facteurs peuvent influencer la quantité de refactoring dont vous avez besoin pour chaque charge de travail AWS Lambda, par exemple:

  • Architecture Réfléchissez à la conception de la charge de travail en termes d'architecture. Par exemple, les charges de travail AWS Lambda qui ont clairement séparé la logique métier de la logique d'accès aux API spécifiques à AWS peuvent nécessiter moins de refactoring que les charges de travail où les deux logiques sont mélangées.
  • Idempotence Déterminez si la charge de travail est idempotente par rapport à ses entrées. Une charge de travail idempotente par rapport aux entrées peut nécessiter moins de refactoring que les charges de travail qui doivent conserver l'état des entrées qu'elles ont déjà traitées.
  • État Déterminez si la charge de travail est sans état. Une charge de travail sans état peut nécessiter moins de refactorisation que les charges de travail qui conservent l'état. Pour en savoir plus sur les services compatibles avec Cloud Run pour stocker des données, consultez la section Options de stockage Cloud Run.
  • Environnement d'exécution Demandez-vous si la charge de travail fait des hypothèses sur son environnement d'exécution. Pour ces types de charges de travail, vous devrez peut-être respecter les mêmes hypothèses dans l'environnement d'exécution Cloud Run ou refactoriser la charge de travail si vous ne pouvez pas faire les mêmes hypothèses pour l'environnement d'exécution Cloud Run. Par exemple, si une charge de travail nécessite que certains packages ou bibliothèques soient disponibles, vous devez les installer dans l'environnement d'exécution Cloud Run qui va héberger cette charge de travail.
  • Injection de configuration Déterminez si la charge de travail accepte l'utilisation de variables d'environnement et de secrets pour injecter (définir) sa configuration. Une charge de travail compatible avec ce type d'injection peut nécessiter moins de refactoring par rapport aux charges de travail compatibles avec d'autres mécanismes d'injection de configuration.
  • API Déterminez si la charge de travail interagit avec les API AWS Lambda. Une charge de travail qui interagit avec ces API peut nécessiter une refactorisation pour utiliser les APIs Cloud et les API Cloud Run.
  • Signalement d'erreurs Déterminez si la charge de travail signale des erreurs à l'aide de flux de sortie et d'erreur standards. Une charge de travail qui effectue ce type de signalement d'erreurs peut nécessiter moins de refactoring par rapport aux charges de travail qui signalent les erreurs à l'aide d'autres mécanismes.

Pour en savoir plus sur le développement et l'optimisation des charges de travail Cloud Run, consultez les ressources suivantes:

Refactoriser les processus de déploiement et opérationnels

Après avoir refactorisé vos charges de travail, vous devez refactoriser vos processus de déploiement et d'exploitation pour effectuer les opérations suivantes:

  • Provisionnez et configurez des ressources dans votre environnement Google Cloud au lieu de le faire dans votre environnement source.
  • Créez et configurez des charges de travail, puis déployez-les dans Google Cloud au lieu de les déployer dans votre environnement source.

Vous avez recueilli des informations sur ces processus lors de la phase d'évaluation plus tôt dans ce processus.

Le type de refactoring que vous devez envisager pour ces processus dépend de la façon dont vous les avez conçus et implémentés. La refactorisation dépend également de l'état final que vous souhaitez pour chaque processus. Nous vous conseillons, par exemple, de suivre les recommandations suivantes :

  • Vous avez peut-être mis en œuvre ces processus dans votre environnement source, et vous avez l'intention de concevoir et de mettre en œuvre des processus équivalents dans Google Cloud. Par exemple, vous pouvez refactoriser ces processus pour utiliser Cloud Build, Cloud Deploy et Infrastructure Manager.
  • Vous avez peut-être implémenté ces processus dans un autre environnement tiers en dehors de votre environnement source. Dans ce cas, vous devez refactoriser ces processus pour cibler votre environnement Google Cloud au lieu de votre environnement source.
  • Une combinaison des approches précédentes.

La refactorisation des processus de déploiement et opérationnels peut être complexe et nécessiter un effort considérable. Si vous essayez d'effectuer ces tâches lors de la migration de votre charge de travail, celle-ci peut devenir plus complexe et vous exposer à des risques. Après avoir évalué vos processus de déploiement et opérationnels, vous comprenez probablement leur conception et leur complexité. Si vous estimez que vous avez besoin d'un effort considérable pour refactoriser vos processus de déploiement et opérationnels, nous vous recommandons de refactoriser ces processus au cours d'un projet distinct dédié.

Pour en savoir plus sur la conception et la mise en œuvre des processus de déploiement sur Google Cloud, consultez les ressources suivantes:

Ce document se concentre sur les processus de déploiement qui produisent les artefacts à déployer et les déploient dans l'environnement d'exécution cible. La stratégie de refactoring dépend fortement de la complexité de ces processus. La liste suivante décrit une stratégie de refactoring générale possible:

  1. Provisionnez des dépôts d'artefacts sur Google Cloud. Par exemple, vous pouvez utiliser Artifact Registry pour stocker des artefacts et créer des dépendances.
  2. Refactorisez vos processus de compilation pour stocker des artefacts à la fois dans votre environnement source et dans Artifact Registry.
  3. Refactorisez vos processus de déploiement pour déployer vos charges de travail dans votre environnement Google Cloud cible. Par exemple, vous pouvez commencer par déployer un petit sous-ensemble de vos charges de travail dans Google Cloud, à l'aide d'artefacts stockés dans Artifact Registry. Vous augmentez ensuite progressivement le nombre de charges de travail déployées dans Google Cloud, jusqu'à ce que toutes les charges de travail à migrer s'exécutent sur Google Cloud.
  4. Refactorisez vos processus de compilation pour stocker les artefacts dans Artifact Registry uniquement.
  5. Si nécessaire, migrez les versions antérieures des artefacts à déployer depuis les dépôts de votre environnement source vers Artifact Registry. Par exemple, vous pouvez copier des images de conteneur dans Artifact Registry.
  6. Mettez hors service les dépôts de votre environnement source lorsque vous n'en avez plus besoin.

Pour faciliter les éventuels rollbacks en raison de problèmes imprévus lors de la migration, vous pouvez stocker des images de conteneurs à la fois dans vos dépôts d'artefacts actuels dans Google Cloud pendant la migration vers Google Cloud. Enfin, dans le cadre du décommissionnement de votre environnement source, vous pouvez refactoriser vos processus de création d'images de conteneur pour stocker des artefacts uniquement dans Google Cloud.

Bien que cela ne soit pas essentiel à la réussite d'une migration, vous devrez peut-être migrer vos versions antérieures d'artefacts depuis votre environnement source vers vos dépôts d'artefacts sur Google Cloud. Par exemple, pour permettre le rollback de vos charges de travail à des moments arbitraires, vous devrez peut-être migrer les versions antérieures de vos artefacts vers Artifact Registry. Pour en savoir plus, consultez la page Migrer des images à partir d'un registre tiers.

Si vous utilisez Artifact Registry pour stocker vos artefacts, nous vous recommandons de configurer des contrôles pour vous aider à sécuriser vos dépôts d'artefacts, tels que le contrôle des accès, la prévention de l'exfiltration de données, l'analyse des failles et l'autorisation binaire. Pour en savoir plus, consultez la section Contrôler l'accès et protéger les artefacts.

Refactoriser les processus opérationnels

Lors de votre migration vers Cloud Run, nous vous recommandons de refactoriser vos processus opérationnels afin de surveiller en permanence et efficacement votre environnement Cloud Run.

Cloud Run s'intègre aux services opérationnels suivants:

Migrer les données

La phase d'évaluation effectuée plus tôt dans ce processus aurait dû vous aider à déterminer si les charges de travail AWS Lambda que vous migrez dépendent ou produisent des données qui se trouvent dans votre environnement AWS. Par exemple, vous avez peut-être déterminé que vous devez migrer des données d'AWS S3 vers Cloud Storage, ou d'Amazon RDS et Aurora vers Cloud SQL et AlloyDB pour PostgreSQL. Pour en savoir plus sur la migration de données depuis AWS vers Google Cloud, consultez la page Migrer depuis AWS vers Google Cloud: premiers pas.

Comme pour la refactorisation des processus de déploiement et opérationnels, la migration de données depuis AWS vers Google Cloud peut être complexe et nécessiter un effort considérable. Si vous essayez d'effectuer ces tâches de migration de données lors de la migration de vos charges de travail AWS Lambda, celle-ci peut devenir complexe et vous exposer à des risques. Après avoir analysé les données à migrer, vous aurez probablement une idée de leur taille et de leur complexité. Si vous estimez que vous avez besoin d'un effort considérable pour migrer ces données, nous vous recommandons de migrer les données dans le cadre d'un projet distinct dédié.

Valider les résultats de la migration

La validation de la migration de votre charge de travail n'est pas un événement ponctuel, mais un processus continu. Vous devez vous concentrer sur les tests et la validation avant, pendant et après la migration d'AWS Lambda vers Cloud Run.

Pour garantir la réussite de la migration avec des performances optimales et des perturbations minimales, nous vous recommandons d'utiliser le processus suivant pour valider les charges de travail que vous migrez d'AWS Lambda vers Cloud Run:

  • Avant de commencer la phase de migration, refactorisez vos cas de test existants pour tenir compte de l'environnement Google Cloud cible.
  • Pendant la migration, validez les résultats des tests à chaque jalon de migration et effectuez des tests d'intégration approfondis.
  • Après les migrations, effectuez les tests suivants :
    • Tests de référence: établissez des benchmarks de performances de la charge de travail d'origine sur AWS Lambda, tels que le temps d'exécution, l'utilisation des ressources et les taux d'erreur sous différentes charges. Répliquez ces tests sur Cloud Run pour identifier les écarts pouvant indiquer des problèmes de migration ou de configuration.
    • Tests fonctionnels: assurez-vous que la logique de base de vos charges de travail reste cohérente en créant et en exécutant des cas de test couvrant différents scénarios d'entrée et de sortie attendus dans les deux environnements.
    • Tests de charge: augmentez progressivement le trafic pour évaluer les performances et la scalabilité de Cloud Run dans des conditions réelles. Pour assurer une migration fluide, corrigez les écarts tels que les erreurs et les limites de ressources.

Optimiser votre environnement Google Cloud

L'optimisation est la dernière phase de votre migration. Au cours de cette phase, vous effectuez des itérations sur les tâches d'optimisation jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de chaque itération sont les suivantes :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Vous devez répéter cette séquence jusqu'à ce que vous ayez atteint vos objectifs d'optimisation.

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud, consultez les pages Migrer vers Google Cloud : optimiser votre environnement et Processus d'optimisation des performances.

Étape suivante

Contributeurs

Auteurs :

Autres contributeurs :