Google Cloud pour les utilisateurs professionnels d'AWS : services de calcul

Guide mis à jour le 21 novembre 2017

Comparez les services de calcul fournis par Amazon Web Services (AWS) et Google Cloud dans leurs environnements cloud respectifs. Les services de calcul sont généralement fournis selon les quatre modèles de service suivants :

  • Infrastructure as a Service (IaaS) : les utilisateurs disposent d'un accès direct et à la demande aux VM, ainsi qu'à une suite de services connexes pour automatiser les tâches courantes.
  • Platform as a Service (PaaS) : la couche matérielle est complètement éliminée, et les utilisateurs interagissent avec les ressources par le biais de services et d'API de haut niveau.
  • Functions as a Service (FaaS) : un modèle de calcul sans serveur qui permet d'exécuter des fonctions individuelles en réponse à divers déclencheurs.
  • Containers as a Service (CaaS) : un service hybride IaaS/PaaS qui élimine la couche matérielle, mais conserve une grande partie de la flexibilité du modèle IaaS.

Cet article présente les services IaaS, PaaS, FaaS et CaaS proposés par Google Cloud et AWS.

Comparaison des offres IaaS

Pour les offres IaaS, AWS propose Amazon Elastic Compute Cloud (EC2) et Google Cloud propose Compute Engine. Google et Amazon adoptent des approches similaires pour leurs services IaaS. Amazon EC2 et Compute Engine sont :

  • des composants fondamentaux de leur environnement cloud ;
  • utilisés pour exécuter presque tous les types de charges de travail de clients sur leur plate-forme.

De manière générale, les termes et les concepts d'Amazon EC2 peuvent être comparés à ceux de Compute Engine :

Fonctionnalité Amazon EC2 Compute Engine
Machines virtuelles Instances Instances
Images système Amazon Machine Image Image
Machines virtuelles temporaires Instances ponctuelles VM préemptives
Pare-feu Groupes de sécurité Règles de pare-feu Compute Engine
Autoscaling d'instances Autoscaling Autoscaler Compute Engine
Disque local associé Espace disque éphémère Disque SSD local
Importation de VM Formats compatibles : RAW, OVA, VMDK et VHD Formats compatibles : RAW, OVA, VMDK et VHD
Zone de déploiement Zonal Zonal

Instances de machines virtuelles

Les instances de machines virtuelles Compute Engine et Amazon EC2 partagent en grande partie les mêmes fonctionnalités. Les deux services vous permettent d'effectuer les opérations suivantes :

  • Créer des instances à partir d'images de disque stockées
  • Lancer et arrêter des instances à la demande
  • Gérer des instances sans restrictions
  • Ajouter des tags aux instances
  • Installer différents systèmes d'exploitation sur une instance

Accès à la machine

L'accès à la machine dans Compute Engine et Amazon EC2 est légèrement différent :

  • Avec Amazon EC2, vous devez inclure votre propre clé SSH pour accéder au terminal de l'instance.
  • Compute Engine vous permet de créer la clé lorsque vous en avez besoin, même si votre instance est déjà en cours d'exécution.
  • Vous pouvez utiliser le terminal SSH de Compute Engine qui est disponible dans Google Cloud Console via un navigateur sans avoir à stocker les clés sur un ordinateur local.

Types d'instances

Amazon EC2 et Compute Engine offrent de nombreuses configurations d'instance prédéfinies avec des volumes spécifiques de processeur virtuel, de mémoire RAM et de réseau.

  • Amazon EC2 fait référence à ces configurations en tant que types d'instances.
  • Compute Engine les appelle types de machines.
  • Compute Engine vous permet de vous écarter des configurations prédéfinies en personnalisant le processeur et la mémoire RAM de votre instance en fonction de votre charge de travail.

Les instances prédéfinies peuvent être classées grossièrement en fonction de l'usage auquel elles sont destinées, tel que décrit dans le tableau suivant :

Type de machine Description
Cœur partagé

Machines s'exécutant sur une partie d'un processeur physique.

Convient aux tâches qui nécessitent peu de ressources, mais qui doivent rester en ligne pendant de longues périodes.

Standard

Machines équilibrant les ressources de calcul, de réseau et de mémoire.

Convient à la plupart des applications générales sans exigences de ressources spécifiques.

Haute capacité de mémoire

Machines dont le ratio mémoire/processeurs virtuels est supérieur au standard.

Convient aux applications qui utilisent beaucoup de mémoire, mais peu de ressources de calcul. Exemples : applications de base de données hautes performances, applications devant conserver des caches de données volumineux et applications volumineuses axées sur les données telles que les systèmes de gestion d'entreprise.

Haute capacité de calcul

Machines dont le ratio processeurs virtuels/mémoire est supérieur au standard.

Convient aux applications qui utilisent beaucoup de ressources de calcul avec peu d'exigences de mémoire. Exemples : logiciel de transformation des données (par exemple, encodage vidéo), logiciel de simulation pour les sciences et l’ingénierie, et serveurs Web à trafic élevé.

GPU

Machines comprenant des unités de traitement graphique (GPU) discrètes.

Convient aux applications nécessitant un traitement mathématique exigeant. Le machine learning est un exemple typique, mais de nombreuses autres tâches tirent parti de l'efficacité accrue des GPU de traitement mathématique avancé.

Stockage SSD

Machines avec un stockage SSD local.

Convient aux applications nécessitant un débit de stockage élevé. Le stockage SSD offre un accès aux données plus rapide que le stockage magnétique.

Stockage dense

Machines qui incluent un stockage sur support magnétique de grande capacité.

Convient aux applications qui conservent de grandes quantités de données sur des disques locaux. Dans de nombreux cas, les applications aux exigences de stockage importantes peuvent stocker des données dans d'autres services Web plutôt que sur des disques associés à des VM.

Le tableau suivant répertorie les types d'instances des deux services disponibles en mai 2016.

Type de machine Elastic Compute Cloud Compute Engine
Cœur partagé t2.micro - t2.large f1-micro
g1-small
Standard m3.medium - m3.2xlarge
m4.large - m4.10xlarge
n1-standard-1 - n1-standard-64
Haute capacité de mémoire r3.large - r3.8xlarge
x1.32xlarge
n1-highmem-2 - n1-highmem-64
Haute capacité de calcul c3.large - c3.8xlarge
c4.large - c4.8xlarge
n1-highcpu-2 - n1-highcpu-64
GPU g2.2xlarge
g2.8xlarge
Ajouter des GPU à la plupart des types de machines
Stockage SSD i2.xlarge - i2.8xlarge n1-standard-1 - n1-standard-64
n1-highmem-2 - n1-highmem-64
n1-highcpu-2 - n1-highcpu-64*
Stockage dense d2.xlarge - d2.8xlarge ND

* Bien que Compute Engine ne fournisse pas de types de machines qui correspondent exactement aux types d'instances d'AWS, l'association d'un stockage SSD local à d'autres types de machines permet d'obtenir les mêmes capacités.

Compute Engine et AWS partagent plusieurs types d'instances généraux, tels que la mémoire standard, la haute capacité de mémoire, la haute capacité de processeur et le cœur partagé. Toutefois, Compute Engine ne dispose pas de catégories spécifiques pour les instances qui utilisent le stockage SSD local : tous les types d'instances non partagés de Compute Engine sont compatibles avec l'ajout de disques SSD locaux. Consultez la section Disques associés localement pour obtenir une comparaison plus détaillée de la mise en œuvre de ce type de stockage par chaque environnement.

Compute Engine n'offre actuellement pas de stockage magnétique à grande échelle.

Instances temporaires

Les instances temporaires sont des machines virtuelles qui s'exécutent sur les cycles libres de ressources allouées à d'autres processus. Cela engendre une VM disponible de manière imprévisible et dont le coût est inférieur à celui d'une VM créée avec des ressources dédiées. Les instances temporaires sont utiles dans les cas suivants :

  • Tâches pouvant être interrompues sans perte de travail
  • Tâches à faible priorité qui n'ont pas à être terminées dans un délai donné
  • Ressources supplémentaires pour les tâches pouvant tirer parti d'un gain de puissance de calcul, le cas échéant. Par exemple, affichage d'une vidéo.

Amazon EC2 fournit des instances temporaires appelées instances spot, et Compute Engine propose des instances similaires, appelées VM préemptives. Les deux offrent des fonctionnalités semblables, mais suivent des modèles de tarification différents.

Les instances spot et les VM préemptives possèdent les caractéristiques suivantes :

  • Limitées à un plus petit ensemble de types d'instances et d'images système disponibles que les instances à la demande standards
  • Performances identiques aux instances à la demande lors de l'exécution
  • Entièrement contrôlables lors de l'exécution

Il existe deux catégories d'instances spot Amazon EC2 :

  • Instances spot standard :
    • Mises aux enchères sur le marché spot
    • Lancées lorsqu'une enchère est acceptée
    • Actives jusqu'à ce que vous les arrêtiez ou qu'AWS les interrompe
  • Blocs spot :
    • Prix fixe inférieur à celui des instances classiques à la demande
    • Limités à un maximum de six heures au tarif réduit

Les VM préemptives de Compute Engine diffèrent des instances spot comme suit :

  • Le tarif est fixe. Selon le type de machine, le tarif des VM préemptives peut être 80 % inférieur à celui des instances à la demande.
  • Si elles ne sont pas récupérées par Compute Engine, les VM préemptives s'exécutent pendant 24 heures au maximum, puis s'arrêtent automatiquement.
  • Si vous utilisez un système d'exploitation premium avec des frais de licence, le coût total de la licence vous sera facturé lors de l'utilisation de cette VM préemptive.

Images système

Compute Engine et Amazon EC2 créent des instances à l'aide d'images système. Amazon appelle ces images "Amazon Machine Images (AMI)" et Compute Engine les nomme simplement "images".

Amazon EC2 et Compute Engine sont suffisamment similaires pour que vous puissiez utiliser le même workflow pour la création d'images sur les deux plates-formes. Par exemple, les AMI d'Amazon EC2 et les images de Compute Engine contiennent un système d'exploitation. Elles peuvent également comporter d'autres logiciels, tels que des serveurs Web ou des bases de données. En outre, les deux services vous permettent d'utiliser des images publiées par des fournisseurs tiers ou des images personnalisées créées pour un usage privé.

Amazon EC2 et Compute Engine stockent les images de différentes manières. Avec AWS, vous stockez des images dans Amazon Simple Storage Service (S3) ou Amazon Elastic Block Store (EBS). Si vous créez une instance basée sur une image stockée dans Amazon S3, vous constaterez une latence plus élevée pendant le processus de création qu'avec Amazon EBS.

Sur Google Cloud, les images sont stockées dans Compute Engine. Pour afficher les images disponibles ou pour créer ou importer des images, vous pouvez consulter la page Images de Cloud Console ou utiliser l'outil de ligne de commande gcloud du SDK Cloud.

Contrairement à Amazon EC2, Compute Engine ne dispose pas de mécanisme permettant de rendre une image publique, ni de dépôt communautaire d'images disponibles. Toutefois, vous pouvez partager des images de manière informelle en les exportant vers Cloud Storage et en les rendant publiques.

Les images système d'Amazon sont disponibles uniquement dans une région spécifique, tandis que celles de Compute Engine le sont dans le monde entier.

Images publiques

Amazon EC2 et Compute Engine fournissent de nombreuses images publiques avec des systèmes d'exploitation couramment utilisés. Sur les deux plates-formes, si vous choisissez d'installer une image premium avec un système d'exploitation nécessitant une licence, vous payez des frais de licence en plus des coûts normaux associés aux instances.

Les deux services vous permettent d'accéder aux images système avec la plupart des systèmes d'exploitation courants. Pour connaître les images disponibles sur Compute Engine, consultez la liste des images publiques.

Amazon EC2 gère certaines images de système d'exploitation qui ne sont pas disponibles en tant qu'images publiques sur Compute Engine :

  • Amazon Linux
  • Windows Server 2003 (Premium)
  • Oracle Linux (Premium)

Importation d'images personnalisées

Amazon EC2 et Compute Engine vous permettent d'importer des images système existantes dans leurs environnements respectifs.

Amazon EC2 fournit un service intitulé VM Import/Export. Ce service est compatible avec différents types d'images de machines virtuelles, tels que RAW, OVA, VMDK et VHD, ainsi que différents systèmes d'exploitation, dont Windows, Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu et Debian. Pour importer une machine virtuelle, vous utilisez un outil de ligne de commande qui regroupe l'image de la machine virtuelle et l'exporte dans Amazon Simple Storage Service (S3) en tant qu'AMI.

Le processus et les conditions nécessaires pour importer des images système dans Compute Engine sont similaires à ceux d'Amazon EC2. Tout comme VM Import/Export, l'outil d'importation Compute Engine prend en charge les types d'images RAW, OVA, VMDK et VHD, ainsi que les systèmes d'exploitation Windows, RHEL, CentOS, Ubuntu et Debian. Pour importer une machine virtuelle, importez l'image dans Cloud Storage, puis utilisez l'outil de ligne de commande gcloud ou Cloud Console pour terminer l'importation de l'image dans Compute Engine. Pour obtenir plus de détails sur l'importation d'images et d'autres éléments virtuels dans Compute Engine, consultez la section Sélection d'une méthode d'importation.

Si vous créez vos propres systèmes d'exploitation personnalisés et prévoyez de les exécuter sur Compute Engine, assurez-vous qu'ils répondent aux exigences en matière de compatibilité matérielle et de noyau pour les images personnalisées.

En dehors du coût de stockage d'une image dans Amazon S3 ou Cloud Storage, ni AWS ni Google Cloud ne facturent leurs services d'importation respectifs.

Autoscaling d'instances

Compute Engine et Amazon EC2 offrent une fonctionnalité d'autoscaling, qui permet de créer et de supprimer des instances en fonction des stratégies définies par l'utilisateur. L'autoscaling peut être utilisé pour maintenir un nombre spécifique d'instances à un moment donné ou pour ajuster la capacité en réponse à certaines conditions. Les instances avec autoscaling sont créées à partir d'un modèle défini par l'utilisateur.

Compute Engine et Amazon EC2 mettent en œuvre l'autoscaling de la même manière :

  • La fonctionnalité Auto Scaling d'Amazon fait évoluer les instances d'un groupe. L'autoscaler crée et supprime des instances en fonction du plan de scaling que vous définissez. Chaque nouvelle instance du groupe est créée à partir d'une configuration de lancement.
  • L'autoscaler de Compute Engine fait évoluer les instances au sein d'un groupe d'instances géré. L'autoscaler crée et supprime des instances en fonction de règles d'autoscaling. Chaque nouvelle instance du groupe d'instances est créée à partir d'un modèle d'instance.

Trois plans de scaling sont disponibles avec la fonctionnalité Auto Scaling d'Amazon :

  • Manuel : vous indiquez manuellement à Auto Scaling d'augmenter ou de réduire le nombre d'instances.
  • Planifié : vous configurez Auto Scaling de façon à augmenter ou réduire le nombre d'instances à des heures définies.
  • Dynamique : Auto Scaling fait évoluer les instances en fonction d'une règle. Vous pouvez créer des règles basées sur les métriques Amazon CloudWatch ou Amazon Simple Queue Services (SQS).

En revanche, l'autoscaler de Compute Engine ne propose que le scaling dynamique. Vous pouvez créer des règles basées sur l'utilisation moyenne du processeur, la capacité de diffusion de l'équilibrage de charge HTTP, ou les métriques Cloud Monitoring.

Réseaux internes

Dans Compute Engine et Amazon EC2, les nouvelles instances sont automatiquement connectées à un réseau interne par défaut. En outre, vous créez un autre réseau et lancez vos instances sur celui-ci dans les deux services. Vous trouverez un comparatif complet des services de mise en réseau de Google Cloud et d'AWS dans l'article Mise en réseau.

Pare-feu

Amazon EC2 et Compute Engine permettent aux utilisateurs de configurer des stratégies de pare-feu pour autoriser et refuser de manière sélective le trafic sur les instances de machines virtuelles. Par défaut, les deux services bloquent tout le trafic entrant provenant de l'extérieur du réseau. Les utilisateurs doivent ainsi définir une règle de pare-feu pour que les paquets puissent accéder aux instances.

Amazon EC2 et Amazon Virtual Private Cloud (VPC) utilisent des groupes de sécurité et des listes de contrôle d'accès réseau (NACL) pour autoriser ou refuser le trafic entrant et sortant. Les groupes de sécurité Amazon EC2 sécurisent les instances dans Amazon EC2-Classic, tandis que les groupes de sécurité et les NACL Amazon VPC sécurisent les instances et les sous-réseaux dans Amazon VPC.

Compute Engine utilise des règles de pare-feu pour sécuriser les instances de machines virtuelles Compute Engine et les réseaux. Vous créez une règle en spécifiant la plage d'adresses IP source, le protocole, les ports ou les tags définis par l'utilisateur qui représentent les groupes source et cible des instances de machines virtuelles.

Stockage de blocs

Amazon EC2 et Compute Engine sont compatibles avec le stockage de blocs sur réseau et en local. Vous trouverez un comparatif détaillé des services de stockage de blocs sur la page Stockage de blocs.

Coûts

Cette section compare les modèles tarifaires de Compute Engine et d'Amazon EC2.

Tarifs à la demande

Compute Engine et Amazon EC2 ont des modèles de tarification à la demande similaires pour l'exécution d'instances :

  • Amazon EC2 est facturé à la seconde, avec un minimum d'une minute. Les systèmes d'exploitation premium tels que Windows ou RHEL sont facturés à l'heure, avec un arrondi à l'heure suivante.
  • Compute Engine est facturé à la seconde, avec un minimum d'une minute.

Ces deux services vous permettent d'exécuter votre instance indéfiniment.

Remises

Les remises sont appliquées de manière très différente dans Compute Engine et Amazon EC2.

Vous pouvez obtenir des tarifs réduits dans Amazon EC2 en provisionnant des instances réservées :

  • Vous devez vous engager à utiliser un certain nombre d'instances pendant un ou trois ans.
  • Le coût qui vous est facturé pour ces instances est inférieur.
  • Un engagement de trois ans entraîne des remises plus importantes qu'un engagement d'un an.
  • Plus vous réglez à l'avance, plus la remise est importante.
  • Les instances réservées sont associées à un type d'instance spécifique et à une zone de disponibilité lors de leur achat.
  • Vous pouvez changer de zone de disponibilité et échanger des instances réservées, mais seulement avec des types d'instances différents appartenant à la même famille.

Vous pouvez obtenir une remise automatique proportionnelle à une utilisation soutenue pour les instances Compute Engine :

  • Compute Engine applique automatiquement des remises à vos instances en fonction de leur durée d'activité au cours d'un mois donné.
  • Plus vous utilisez une instance au cours d'un mois donné, plus la remise est importante.
  • Les remises automatiques proportionnelles à une utilisation soutenue peuvent vous faire économiser jusqu'à 30 % du tarif standard à la demande.

Comparaison des offres FaaS

Pour les offres FaaS (Functions as a Service), Amazon fournit AWS Lambda et Google Cloud fournit Cloud Functions. Ils présentent des modèles de service similaires :

  • Il s'agit de plates-formes de calcul sans serveur qui vous permettent d'exécuter des fonctions individuelles en réponse à différents déclencheurs.
  • Vous n'êtes facturé que lorsque vos fonctions sont en cours d'exécution.
  • Ils constituent un moyen économique d’héberger des services dont les modes d’utilisation sont fluctuants.

Comparaison des modèles de service

Les termes et les concepts d'AWS Lambda peuvent être comparés à ceux de Cloud Functions comme suit :

Fonctionnalité AWS Lambda Cloud Functions
Ingestion de code Importation de fichiers ZIP, versions en ligne et de bureau de l'environnement de développement intégré (IDE), Amazon S3 Importation de fichiers ZIP, IDE en ligne, Cloud Storage, GitHub
Latence de mise à jour du code Généralement quelques secondes Généralement moins de 2 minutes
Nombre maximal d'exécutions simultanées 1 000 par région par défaut 1 000 par fonction par défaut
Taille maximale des déploiements 50 Mo compressés, 250 Mo non compressés 100 Mo compressés, 500 Mo non compressés
Déclencheurs S3, DynamoDB, Kinesis Streams et Firehose, SNS, SES, Cognito, CloudFormation, CloudWatch, CodeCommit, événements planifiés, modifications de configuration AWS, Amazon Echo, Amazon Lex, passerelle d'API (HTTP), bouton IoT, CloudFront HTTP, Cloud Storage, Pub/Sub, Firebase, Cloud Logging
Langages acceptés Node.js, Java, Python, C#, Go Node.js 6, Node.js 8, Python
Allocations de mémoire 128 Mo à 1,5 Go par incréments de 64 Mo 128 Mo, 256 Mo, 512 Mo, 1 Go, 2 Go
Délai avant expiration Entre 1 s et 15 min Entre 1 s et 9 min
Gérer les versions Intégrée Via Cloud Source Repositories
Scaling automatique Oui Oui
Logging Amazon CloudWatch Cloud Logging
Zone de déploiement Régional Régional
Modèle tarifaire Par requête, durée par incréments de 0,1 s et transfert de données. Durée facturée selon l'utilisation de la mémoire. Par requête, durée par incréments de 0,1 s et transfert de données. Durée facturée selon l'utilisation de la mémoire et du processeur.

Lancement et scaling

AWS Lambda et Cloud Functions partagent un certain nombre de fonctionnalités. Ces deux solutions proposent l'exécution de code sans serveur avec différents déclencheurs et évoluent automatiquement en cas de besoin. Elles proposent également des fonctionnalités simples de déploiement, de scaling et de reprise après sinistre. L'architecture lance un conteneur de calcul avec une copie de votre code et fait évoluer automatiquement le nombre d'instances pour gérer votre charge de requêtes. Aucune configuration ou gestion n'est requise pour le processus de scaling une fois la fonction déployée.

Google utilise une architecture de génération d'images préemptives qui réduit considérablement la latence pour les premières requêtes sur les nouvelles instances. Cela peut être un avantage important pour les applications en temps réel ou les situations où votre application doit évoluer très rapidement.

Langages et déclencheurs acceptés

Lambda est disponible depuis plus longtemps que Cloud Functions et accepte par conséquent davantage de langages et de types de déclencheurs. Cloud Functions est compatible avec les déclencheurs Firebase, les journaux de la suite d'opérations Google Cloud et Pub/Sub. Grâce à ces outils, vous pouvez déclencher une fonctionnalité Cloud Function à partir de n'importe quel autre service ou événement Google Cloud.

Limites de l'environnement d'exécution

Les plates-formes FaaS étant conçues pour être purement transactionnelles et déployant des instances à la demande, vous ne pouvez pas compter sur elles pour exécuter du code au-delà de la demande initiale. Vous devez concevoir votre application pour qu'elle soit sans état et de courte durée. Ceci s'applique à la fois à Lambda et à Cloud Functions.

  • AWS met fin à l'exécution après 5 minutes.
  • Cloud Functions met fin à l'exécution après 9 minutes.

Déployer FaaS

Amazon et Google adoptent des approches légèrement différentes pour le déploiement de FaaS. AWS Lambda prend en charge le déploiement à partir d'un fichier zip ou jar, ou via CloudFormation ou S3. En plus des fichiers ZIP, la solution GCP Cloud Functions peut être déployée à partir d'un dépôt Git, dans GitHub ou dans Cloud Source Repositories. La compatibilité avec Git permet de lier étroitement Cloud Functions à votre processus de déploiement. Vous pouvez même configurer des mises à jour automatisées basées sur des webhooks.

Coûts

Les tarifs d'AWS Lambda incluent des frais de base par requête, ainsi que des frais variables basés sur la quantité de mémoire RAM allouée et le temps de calcul. Les frais facturés par AWS Lambda pour le transfert de données sont les mêmes que les frais standards d'EC2.

Cloud Functions facture des frais variables basés sur la quantité de mémoire et le nombre de processeurs provisionnés en plus des frais applicables aux appels. Comme AWS Lambda, la solution Cloud Functions facture des frais standards pour la bande passante de sortie, mais aucun pour le trafic entrant.

Pour en savoir plus, consultez la page des tarifs de Cloud Functions. Vous pouvez estimer le coût de votre charge de travail : essayez le Simulateur de coût Google Cloud.

Comparaison des offres PaaS

Pour ce qui est des offres PaaS, AWS propose AWS Elastic Beanstalk et Google Cloud propose App Engine. Les deux services offrent des fonctionnalités similaires :

  • Vous pouvez publier des applications en envoyant votre code à un service de plate-forme géré.
  • Le service gère :
    • l'infrastructure sous-jacente ;
    • le scaling automatique ;
    • le contrôle de version d'application.

Comparaison des modèles de service

AWS Elastic Beanstalk permet de configurer et de déployer un ensemble de ressources AWS sous-jacentes, telles que des instances Amazon EC2 ou des bases de données Amazon RDS, afin de créer un environnement d'exécution adapté à votre application en fonction de la configuration définie.

App Engine utilise le même modèle. Toutefois, App Engine fournit deux environnements distincts : l'environnement standard et l'environnement flexible, chacun conçu pour des cas d'utilisation spécifiques.

  • Dans l'environnement standard App Engine, votre code est déployé dans des instances de conteneur qui s'exécutent sur l'infrastructure de Google. Comme l'environnement standard App Engine ne repose pas sur des instances de VM Compute Engine sous-jacentes, il évolue plus rapidement que l'environnement flexible App Engine. Toutefois, les options de personnalisation de l'environnement standard sont plus limitées que celles de l'environnement flexible. Vous devez ainsi choisir un environnement d'exécution parmi l'ensemble d'environnements offerts par le service.
  • Dans l'environnement flexible App Engine, votre code est déployé dans des conteneurs Docker exécutés sur des instances de VM Compute Engine et gérés par App Engine. Les environnements d'exécution proposés sont plus nombreux qu'avec l'environnement standard App Engine et vous pouvez créer des environnements d'exécution partiellement ou entièrement personnalisés. Toutefois, lors des pics de trafic les plus élevés, votre application est susceptible d'évoluer plus lentement que dans l'environnement standard App Engine. Pour déterminer l'environnement App Engine le plus adapté à vos besoins, consultez la page Choisir un environnement App Engine.

La solution Elastic Beanstalk peut être intégrée avec les services suivants :

  • Amazon DynamoDB : base de données NoSQL entièrement gérée qui peut stocker et récupérer n'importe quelle quantité de données
  • Amazon RDS : service de base de données relationnelle géré fourni par MySQL, PostgreSQL, MariaDB, Amazon Aurora, Oracle, Microsoft SQL Server
  • Autoscaling et équilibrage de charge
  • Environnements Worker Tier avec intégration SQS qui permet le traitement de tâches en arrière-plan et de tâches périodiques
  • Intégration avec d'autres services et API AWS

Les deux environnements App Engine peuvent utiliser le même ensemble de services de plate-forme, tels que les suivants :

  • Firestore : stockage persistant avec requêtes, tri et transactions
  • Cloud SQL : base de données relationnelle fournie par MySQL ou PostgreSQL (actuellement en version bêta)
  • Autoscaling et équilibrage de charge
  • Files d'attente de tâches asynchrones pour effectuer des opérations en dehors du champ d'application d'une requête
  • Tâches planifiées pour déclencher des événements à des moments spécifiés ou à intervalles réguliers
  • Intégration à d'autres API et services Google Cloud

Composants clés

AWS Elastic Beanstalk et App Engine fonctionnent sur un ensemble similaire de composants clés. Pour les développeurs, AWS Elastic Beanstalk comprend les composants clés suivants :

  • Version de l'application : itération nommée/étiquetée du code déployable envoyé par le développeur.
  • Environnement : instance d'exécution d'une version d'application spécifique déployée sur des ressources AWS.
  • Configuration de l'environnement : ensemble des paramètres qui contrôlent la manière dont Elastic Beanstalk déploie et configure les ressources AWS sous-jacentes pour une version d'application particulière associée à un environnement spécifique.
  • Application : bucket logique pour une collection d'environnements, de configurations d'environnement et de versions d'application.

App Engine comprend les composants clés suivants :

  • Version : itération nommée du code déployable envoyé par le développeur et fichier de configuration spécifiant comment déployer ce code sur App Engine pour créer un service.
  • Service : une application App Engine est constituée d'un ou de plusieurs services qui peuvent être configurés pour utiliser différents environnements d'exécution et fonctionner avec divers paramètres de performances. Chaque service comprend un code source et un fichier de configuration.
  • Fichier de configuration du service : fichier faisant correspondre les chemins d'URL avec les gestionnaires de requêtes et les fichiers statiques. Ce fichier contient également des informations sur le code de l'application, telles que l'ID de l'application et l'identifiant de la version la plus récente.
  • Instance : ressource de calcul sous-jacente sur laquelle un service est exécuté. Dans l'environnement flexible App Engine, une instance correspond à un conteneur Docker sur une instance de VM Compute Engine. Dans l'environnement standard App Engine, une instance correspond à un conteneur exécuté sur l'infrastructure de Google.
  • Application : bucket logique comprenant un ou plusieurs services. Ce bucket peut être configuré pour utiliser différents environnements d'exécution et fonctionner avec divers paramètres de performances.

Voici le comparatif général des plates-formes :

Fonctionnalité AWS Elastic Beanstalk Environnement standard App Engine Environnement flexible App Engine
Environnements d'exécution de langage acceptés Java, PHP, .NET, Node.js, Python (2.6, 2.7, 3.4), Ruby, Go Python 2.7, Java 7, PHP 5.5, Go 1.6 Python (2.7, 3.5), Java 8, Node.js, Go 1.8, Ruby, PHP (5.6, 7), .NET
Environnements d'exécution personnalisés Oui Non Oui
Autoscaling Oui Oui Oui
Version gratuite disponible Oui (version gratuite des ressources AWS sous-jacentes) Oui (28 heures d'utilisation de l'instance par jour) Non
Options de stockage Amazon S3, Amazon RDS, Amazon EFS, Amazon ElastiCache, Amazon DynamoDB Cloud Storage, Cloud SQL, Memcache, Firestore Cloud Storage, Cloud SQL, Memcache, Firestore
Rôles IAM Oui Oui Oui
Régions acceptées États-Unis, EMEA, APAC États-Unis, EMEA, APAC États-Unis, EMEA, APAC
Authentification et autorisation des utilisateurs de l'application Non (cette fonction doit être développée dans l'application) Oui, avec Firebase (plusieurs fournisseurs d'identité), Google Cloud Identity, OAuth2.0 et OpenID Oui, avec Firebase (plusieurs fournisseurs d'identité), comptes Google et G Suite, OAuth 2.0 et OpenID
Files d'attente de tâches et de messages Oui, via SQS Oui, avec Cloud Pub/Sub et l'API Task Queue Oui, avec Cloud Pub/Sub et l'API Task Queue
Mises à niveau d'application et tests A/B Mise à jour progressive avec scaling basé sur la capacité du backend, déploiement bleu/vert avec échange de trafic ponctuel. L'interrogation pondérée à répétition alternée est possible avec une approche basée sur DNS. Oui, avec une répartition précise du trafic entre les versions Oui, avec une répartition précise du trafic entre les versions
Surveillance Oui, rapport d'état, journaux d'instance et flux d'événements d'environnement Oui, avec la suite d'opérations Google Cloud (journaux de requête/réponse et d'activité) et tests de disponibilité Oui, avec la suite d'opérations Google Cloud (journaux de requête/réponse et d'activité), tests de disponibilité, métriques et alertes personnalisées pour les ressources Compute Engine sous-jacentes
Réseau Placement sur un VPC possible Aucun contrôle réseau, uniquement des points de terminaison IP exposés à Internet Placement sur un VPC possible
Tarifs Basés sur le coût des ressources AWS sous-jacentes Basés sur l'instance choisie par heure Le tarif inclut 3 paramètres :
  • Processeur virtuel par cœur/heure
  • Mémoire par Go/heure
  • Disque persistant par Go/mois
Débogage Oui, avec X-ray Oui, avec la suite d'opérations Google Cloud Oui, avec la suite d'opérations Google Cloud

Environnements d'exécution personnalisés

La solution AWS Elastic Beanstalk et l'environnement flexible App Engine vous permettent de créer votre propre environnement d'exécution personnalisé. Cette fonctionnalité vous permet d'utiliser d'autres langages de programmation, ou bien une version ou une mise en œuvre différente des environnements d'exécution standards de la plate-forme.

AWS Elastic Beanstalk gère la personnalisation via des plates-formes personnalisées, qui sont des AMI (Amazon Machine Images) contenant les fichiers binaires nécessaires à l'exécution de votre application. Vous créez des plates-formes personnalisées grâce à Packer, un outil Open Source qui permet de créer des images système identiques pour plusieurs plates-formes à partir d'une seule configuration source. À l'aide d'un modèle de configuration Packer, vous pouvez personnaliser les systèmes d'exploitation, les langages et les frameworks, ainsi que les métadonnées et les options de configuration requises pour diffuser votre application.

L'environnement flexible App Engine gère la personnalisation via des environnements d'exécution personnalisés. Pour créer un environnement d'exécution personnalisé, vous devez créer un fichier Dockerfile avec l'image de base de votre choix, puis ajouter les commandes Docker permettant de générer l'environnement d'exécution souhaité. Votre fichier Dockerfile peut inclure des composants supplémentaires tels que des interprètes en langage ou des serveurs d'applications. Vous pouvez utiliser tout logiciel capable de traiter les requêtes HTTP.

Dans les deux cas, vous devez vous assurer que tous les composants sont compatibles et génèrent les performances attendues.

AWS Elastic Beanstalk utilise Packer et permet aux utilisateurs de contrôler l'intégralité de l'image de l'OS. L'environnement flexible App Engine génère uniquement des conteneurs Docker, ce qui permet aux utilisateurs de contrôler seulement le code de l'application et ses dépendances. Les utilisateurs de l'environnement flexible App Engine ne peuvent pas contrôler des éléments tels que la version du noyau du système d'exploitation sur les VM sous-jacentes.

Autoscaling

AWS Elastic Beanstalk et App Engine proposent une fonctionnalité d'autoscaling. L'autoscaling vous permet d'augmenter ou de réduire automatiquement le nombre d'instances backend en cours d'exécution en fonction de l'utilisation des ressources de votre application.

La fonctionnalité d'autoscaling d'AWS Elastic Beanstalk peut être configurée selon les options de scaling suivantes :

  • La configuration de lancement vous permet de choisir les déclencheurs du scaling et de décrire leurs paramètres.
  • Le scaling manuel vous permet de configurer le nombre d'instances minimal et maximal, les zones de disponibilité et l'intervalle entre chaque période de scaling.
  • L'autoscaling vous permet de configurer des paramètres basés sur des métriques. Les déclencheurs compatibles sont les suivants : entrée/sortie réseau, utilisation du processeur, nombre d'opérations/octets de lecture/d'écriture sur le disque, latence, nombre de requêtes, nombre d'hôtes opérationnels/défaillants.
  • Le scaling basé sur le moment vous permet d'augmenter ou de réduire le nombre d'instances (vous définissez le nombre maximal, minimal et/ou souhaité d'instances) en fonction de vos prédictions, sur une base récurrente ou pour un événement ponctuel planifié.

L'environnement standard App Engine propose les options de scaling suivantes :

  • La configuration de lancement vous permet de choisir une option de scaling et de décrire ses paramètres.
  • Le scaling manuel vous permet de définir le nombre d'instances du service au démarrage.
  • Le scaling de base vous permet de définir le nombre maximal d'instances et la durée d'inactivité après laquelle l'instance est arrêtée, après avoir reçu sa dernière requête.
  • Le scaling automatique vous permet de définir des niveaux minimum et maximum pour le nombre d'instances, la latence et les connexions simultanées pour un service.

L'environnement flexible App Engine propose les options de scaling suivantes :

  • La configuration de lancement vous permet de choisir une option de scaling et de décrire ses paramètres.
  • Le scaling manuel fonctionne de la même manière que dans l'environnement standard App Engine.
  • Le scaling automatique vous permet de définir un nombre minimal et maximal d'instances, l'intervalle entre chaque période de scaling et l'objectif d'utilisation du processeur.

Mises à niveau d'application et tests A/B

Les procédures pour déployer ou mettre à niveau une application dans AWS Elastic Beanstalk et App Engine sont similaires :

  1. Décrivez votre application dans un fichier de configuration.
  2. Déployez la nouvelle version à l'aide d'un outil de ligne de commande.

Les deux services proposent également le déploiement via leur console de gestion.

Lors de l'utilisation d'AWS Elastic Beanstalk, l'exécution directe de mises à jour peut entraîner une brève interruption de votre application. Pour éviter les temps d'arrêt, vous pouvez effectuer un déploiement bleu/vert dans lequel vous déployez la nouvelle version dans un environnement distinct, puis permutez les URL d'environnement. Vous ne pouvez diffuser qu'une seule version active par environnement. L'interrogation pondérée à répétition alternée est possible avec une approche basée sur DNS.

App Engine vous permet de déployer des mises à jour de la version actuelle sans temps d'arrêt, en créant une nouvelle version et en basculant vers celle-ci. Vous pouvez également configurer votre application App Engine pour répartir le trafic en fonction de l'adresse IP du demandeur ou d'un cookie. Vous pouvez diffuser un certain nombre de versions par service et par application.

Débogage

En matière de débogage, la console AWS Elastic Beanstalk vous permet d'exécuter un daemon AWS X-Ray sur les instances de votre environnement de développement. Ce daemon rassemble des données sur les requêtes aux serveurs et la collaboration de l'application avec d'autres services. Vous pouvez créer une carte de service qui vous aide à résoudre les problèmes de votre application et à trouver des moyens de l'optimiser.

Dans Google Cloud, vous pouvez utiliser Cloud Debugger pour inspecter l'état d'une application App Engine quel que soit l'emplacement du code, sans utiliser d'instructions de journalisation et sans interrompre ni ralentir l'exécution de vos applications. En cas de débogage, vos utilisateurs ne sont pas impactés. Grâce au débogueur de production, vous pouvez capturer les variables locales et la pile d'appels, puis faire le lien entre ces variables et la ligne de code source correspondante. Tirez parti de Debugger pour analyser l'état de production de votre application et comprendre le comportement de votre code en production.

Surveillance

La surveillance des environnements AWS Elastic Beanstalk dans AW Management Console vous permet d'obtenir des métriques de base telles que l'utilisation du processeur, ainsi que l'entrée et la sortie réseau. Amazon CloudWatch ajoute la fonction d'état de l'environnement, ainsi que des métriques de surveillance EC2 de base pour les instances sous-jacentes. L'utilisateur peut également ajouter des alertes pour chacune de ces métriques. Toutes les instances EC2 génèrent des journaux utilisables pour résoudre les problèmes liés aux applications.

La surveillance des applications App Engine dans le tableau de bord Google Cloud Console offre une visibilité sur les paramètres tels que le nombre total de requêtes, l'utilisation du processeur et de la mémoire, la latence et le temps de disponibilité de l'instance. La suite d'opérations Google Cloud vous permet de créer des alertes pour différents paramètres et de stocker des journaux.

Réseau

AWS Elastic Beanstalk vous permet de gérer la connectivité des ressources AWS utilisées par l'environnement. Vous pouvez demander à Elastic Beanstalk de connecter des VM EC2 à un VPC spécifique et de configurer des groupes de sécurité sur ces instances. Cela permet aux applications Elastic Beanstalk d'atteindre un niveau de transparence en matière de connectivité réseau semblable à celui de l'environnement flexible App Engine.

L'environnement standard App Engine supprime complètement la procédure de configuration du réseau. Les seuls paramètres liés au réseau que vous devez utiliser s'appliquent à l'équilibrage de charge et au nom de domaine personnalisé pour l'adresse externe de l'application. Vous pouvez également utiliser le service de protection DOS à l'aide du fichier dos.yaml pour établir une liste noire de réseaux. Lorsqu'elle est déployée en parallèle à l'application, la plate-forme App Engine diffuse une page d'erreur en réponse aux requêtes provenant de plages d'adresses IP interdites.

L'environnement flexible App Engine utilise des machines virtuelles (VM) Compute Engine pour héberger l'application dans des conteneurs Docker. Vous pouvez :

  • configurer des VM gérées par l'environnement flexible App Engine pour les connecter aux réseaux VPC. Les réseaux VPC peuvent résider dans le même projet que l'application définie dans l'environnement flexible, ou être partagés entre plusieurs projets ;
  • configurer des réseaux VPC contenant des instances de l'environnement flexible App Engine, pour les connecter à d'autres destinations à l'aide de Cloud VPN ;
  • appliquer les paramètres du pare-feu aux instances de l'environnement flexible App Engine à l'aide de tags d'instances ;
  • mapper les ports réseau des instances de l'environnement flexible sur les ports des conteneurs Docker, à des fins de débogage et de profilage.

Cette flexibilité est utile lorsque vous développez des applications dans l'environnement flexible App Engine qui requièrent une connectivité transparente à d'autres services, exécutés sur Google Cloud ou ailleurs (sur site ou dans un autre cloud).

Coûts

AWS ne facture aucuns frais supplémentaires pour l'utilisation d'Elastic Beanstalk. Vous ne payez que pour les instances EC2 sous-jacentes et les autres ressources que vous utilisez.

Pour l'environnement standard App Engine, les frais sont facturés à la minute d'exécution de l'instance. La facturation commence dès le début d'une instance et se termine 15 minutes après l'arrêt d'une instance manuelle ou 15 minutes après qu'une instance de base a terminé de traiter sa dernière requête. Les instances inactives ne sont pas facturées au-delà du nombre maximal d'instances inactives défini dans l'onglet "Paramètres de performance". Il existe également un quota gratuit : 28 heures d'utilisation de l'instance gratuites par jour pour les modules de scaling automatique et 9 heures d'utilisation de l'instance gratuites par jour pour les modules de scaling de base et manuel.

Pour l'environnement flexible App Engine, des frais sont facturés pour les ressources des types de machines virtuelles que vous spécifiez. Le coût est déterminé par l'utilisation des paramètres :

  • Processeur virtuel (par cœur/heure)
  • Mémoire (par Go/heure)
  • Disque persistant (par Go/mois)

Ces frais sont facturés à la minute, avec un minimum de dix minutes d'utilisation.

Pour en savoir plus, consultez la page des tarifs de Compute Engine. Vous pouvez estimer le coût de votre charge de travail : essayez le Simulateur de coût Google Cloud.

Comparaison des offres CaaS

Pour ce qui est des offres CaaS, AWS propose Amazon EC2 Container Service (ECS) et Google Cloud propose Google Kubernetes Engine.

GKE et Amazon ECS offrent des modèles de service très similaires. Dans chaque service, vous créez un cluster de nœuds de conteneur. Chaque nœud est une instance de machine virtuelle qui exécute un agent de nœud pour signaler son inclusion dans le cluster. Chaque nœud exécute également un daemon de conteneur, tel que Docker, afin que le nœud puisse exécuter des applications en conteneur. Vous créez une image Docker qui contient à la fois les fichiers de votre application et les instructions relatives à son exécution, puis vous la déployez dans le cluster.

Amazon ECS est développé et géré par Amazon. Google Kubernetes Engine s'appuie sur Kubernetes, un système de gestion de conteneurs Open Source.

De manière générale, les termes et les concepts d'Amazon ECS peuvent être comparés à ceux de GKE comme suit :

Fonctionnalité Amazon ECS GKE
Nœuds de cluster Instances Amazon EC2 Instances Compute Engine
Daemons acceptés Docker Docker ou rkt
Agent de nœuds Agent Amazon ECS Kubelet
Groupe de conteneurs Tâche Pod
Service de dimensionnement du déploiement Service Contrôleur de réplication
Outil de ligne de commande CLI Amazon ECS kubectl ou gcloud
Portabilité Fonctionne uniquement sur AWS Fonctionne dans tous les environnements compatibles avec Kubernetes

Composants des plates-formes

Clusters

Dans Amazon ECS et GKE, un cluster est un regroupement logique de nœuds de machines virtuelles. Dans Amazon ECS, un cluster utilise des instances Amazon EC2 en tant que nœuds. Pour créer un cluster, vous devez simplement lui attribuer un nom, et Amazon ECS le crée. Cependant, ce cluster est vide par défaut. Vous devez démarrer des instances de conteneur dans le cluster afin de pouvoir lancer votre application.

Dans GKE, un cluster utilise des instances Compute Engine en tant que nœuds. Pour créer un cluster, vous devez d'abord fournir des détails de configuration de base définis sur les valeurs souhaitées, y compris les suivants :

  • Nom du cluster
  • Zones de déploiement
  • Types de machines Compute Engine
  • Taille du cluster

Une fois la configuration du cluster effectuée, GKE crée le cluster dans la ou les zones demandées.

Groupes de conteneurs

Amazon ECS et GKE regroupent des ensembles de conteneurs interdépendants ou associés dans des unités de service de niveau supérieur. Dans Amazon ECS, ces unités sont appelées tâches et sont définies par des définitions de tâches. Dans GKE, ces unités sont appelées pods, et sont définies dans un PodSpec. Dans les tâches et les pods, les conteneurs sont colocalisés et coplanifiés, et s'exécutent dans un contexte partagé, avec une adresse IP et un espace de port partagés.

Daemons de conteneur

Chaque machine de nœud doit exécuter un daemon de conteneur pour gérer les services en conteneur. Amazon ECS est compatible avec le daemon de conteneur Docker. Google Kubernetes Engine est compatible avec Docker et rkt.

Agents de nœuds

Dans Amazon ECS, chaque nœud Amazon EC2 exécute un agent Amazon ECS qui démarre des conteneurs pour le compte d'Amazon ECS. De même, dans GKE, chaque nœud GKE exécute un kubelet qui préserve l'intégrité et la stabilité des conteneurs s'exécutant sur le nœud.

Recherche de services

Amazon ECS ne fournit pas de mécanisme natif pour la recherche de services dans un cluster. Pour remédier à ce problème, vous pouvez configurer une solution de recherche de services tierce, telle que Consul, pour activer la recherche de services dans un cluster spécifique.

Les clusters GKE permettent la recherche de services via le module complémentaire Kubernetes DNS, activé par défaut. Chaque service Kubernetes se voit attribuer une adresse IP virtuelle stable tant que le service existe. Le serveur DNS observe l'API Kubernetes pour détecter les nouveaux services, puis crée un ensemble d'enregistrements DNS pour chaque service. Ces enregistrements permettent aux pods Kubernetes d'effectuer automatiquement la résolution de noms des services Kubernetes.

Planification

Amazon ECS est uniquement compatible avec son programmeur natif.

GKE s'articule autour de Kubernetes, une architecture connectable. Par conséquent, GKE est entièrement compatible avec le programmeur Open Source Kubernetes, qui peut fonctionner dans tous les environnements compatibles avec Kubernetes.

Automatisation des déploiements

Avec Amazon ECS, vous pouvez créer un script pour déployer des tâches sur chaque nœud. Toutefois, ce comportement n'est pas intégré au service.

Avec GKE, vous pouvez utiliser DaemonSet pour exécuter une copie d'un pod spécifique sur chaque nœud d'un cluster. Lorsque des nœuds sont ajoutés ou supprimés du cluster, DaemonSet copie automatiquement le pod sur les nouveaux nœuds ou récupère la mémoire sur les anciens nœuds. Lorsque vous supprimez DaemonSet, celui-ci nettoie tous les pods qu'il a créés.

Gestion des disques

Étant donné que les disques d'Amazon ECS sont propres à l'hôte, un conteneur qui repose sur un disque spécifique donné ne peut pas être déplacé vers un hôte différent.

En revanche, GKE peut installer des disques dynamiquement sur un nœud et les affecter automatiquement à un pod donné. Vous n'avez pas besoin d'exécuter un pod sur un nœud spécifique pour utiliser un disque particulier.

Gestion de l'authentification et des accès

Amazon ECS est entièrement intégré au service IAM (Identity and Access Management) d'AWS. GKE n'est actuellement pas compatible avec le service IAM de Google Cloud.

Architecture mutualisée

Dans Amazon ECS, vous pouvez mettre en œuvre l'architecture mutualisée en créant des clusters distincts, puis en configurant manuellement le service IAM d'AWS pour limiter l'utilisation de chaque cluster.

En revanche, GKE est compatible avec les espaces de noms. Les utilisateurs peuvent ainsi regrouper logiquement des clusters et indiquer un champ d'application pour accepter les clusters mutualisés. Les espaces de noms vous permettent d'effectuer les opérations suivantes :

  • Créer plusieurs communautés d'utilisateurs sur un seul cluster
  • Déléguer l'autorité sur les partitions du cluster aux utilisateurs approuvés
  • Limiter la quantité de ressources utilisable par chaque communauté
  • Ne proposer que les ressources pertinentes pour une communauté d'utilisateurs spécifique
  • Isoler les ressources utilisées par une communauté d'utilisateurs spécifique des autres communautés d'utilisateurs sur le cluster

Vérifications d'état

Dans Amazon ECS, vous pouvez détecter les échecs en utilisant les vérifications d'état d'Amazon ELB. Amazon ELB effectue des vérifications de l'état via HTTP/TCP. Pour recevoir des vérifications d'état, tous les services en conteneur, même ceux qui n'ont pas besoin d'écouter un port TCP, doivent configurer un serveur HTTP. De plus, chaque service doit être lié à un ELB, même si sa charge n'a pas besoin d'être équilibrée.

Dans GKE, vous pouvez effectuer des vérifications d'état à l'aide de vérifications de préparation et de vivacité :

  • Les vérifications de préparation vous permettent de vérifier l'état d'un pod pendant l'initialisation.
  • Les vérifications de vivacité vous permettent de détecter et de redémarrer les pods qui ne fonctionnent plus correctement.

Ces vérifications sont incluses dans l'API Kubernetes et peuvent être configurées dans un PodSpec.

Portabilité

Étant donné que l'agent Amazon ECS ne peut être exécuté que sur des instances Amazon EC2, les configurations Amazon ECS ne peuvent être exécutées que sur Amazon ECS. En revanche, GKE étant basé sur Kubernetes, les configurations de Google Kubernetes Engine peuvent être exécutées sur n'importe quelle installation Kubernetes.

Coûts

Amazon vous facture les instances Amazon EC2 et les volumes de disques Amazon EBS que vous utilisez dans votre déploiement. Le service de gestion de conteneurs d'Amazon ECS est gratuit.

Google Cloud facture les instances Compute Engine et les disques persistants que vous utilisez dans votre déploiement. En outre, GKE facture un tarif horaire pour la gestion des clusters. Ces frais ne s'appliquent pas aux clusters comportant cinq nœuds ou moins. Consultez les tarifs de GKE pour en savoir plus.

Et ensuite ?

Consultez les autres articles Google Cloud pour les utilisateurs professionnels d'AWS :