Quelle est la différence entre Google App Engine et Google Compute Engine?

Question

Je me demandais quelle était la différence entre App Engine et Compute Engine. Quelqu'un peut-il m'expliquer la différence?

Andrei Volgin · Accepted Answer

App Engine est une plate-forme en tant que service. Cela signifie que vous déployez simplement votre code et que la plate-forme fait tout le reste pour vous. Par exemple, si votre application rencontre un grand succès, App Engine créera automatiquement plus d'instances pour gérer le volume accru.

En savoir plus sur App Engine

Compute Engine est une infrastructure en tant que service. Vous devez créer et configurer vos propres instances de machine virtuelle. Il vous donne plus de flexibilité et coûte généralement beaucoup moins que App Engine. L'inconvénient est que vous devez gérer vous-même votre application et vos machines virtuelles.

En savoir plus sur Compute Engine

Vous pouvez mélanger App Engine et Compute Engine, si nécessaire. Les deux fonctionnent bien avec les autres parties de la Google Cloud Platform .

EDIT (mai 2016):

Une distinction plus importante encore: les projets exécutés sur App Engine peuvent être réduits à zéro instance si aucune demande n’arrive. Cela est extrêmement utile au stade du développement, car vous pouvez passer des semaines sans dépasser le généreux quota gratuit d’heures-instances. Une exécution flexible ("machines virtuelles gérées") nécessite au moins une instance à exécuter en permanence.

EDIT (avril 2017):

Fonctions Cloud (actuellement en version bêta) est le niveau supérieur de App Engine en termes d'abstraction - aucune instance! Il permet aux développeurs de déployer des morceaux de code minuscules qui s'exécutent en réponse à différents événements, tels que des requêtes HTTP, des modifications du stockage en nuage, etc.

La plus grande différence avec App Engine est que les fonctions sont facturées toutes les 100 millisecondes, tandis que les instances d'App Engine ne sont arrêtées qu'après 15 minutes d'inactivité. Un autre avantage est que les fonctions de cloud s'exécutent immédiatement, alors qu'un appel à App Engine peut nécessiter une nouvelle instance - et que le démarrage à froid d'une nouvelle instance peut prendre quelques secondes ou plus (en fonction du runtime et de votre code).

Cela rend Cloud Functions idéal pour (a) des appels rares - inutile de garder une instance en direct au cas où quelque chose se produirait, (b) des charges rapidement changeantes où les instances tournent souvent et se ferment, et éventuellement davantage de cas d'utilisation.

En savoir plus sur les fonctions du nuage

Mostafiz Rahman · Answer

La différence fondamentale est que Google App Engine (GAE) est un Plate-forme en tant que service ( PaaS ) alors que Google Compute Engine () _ gce _ ) est un Infrastructure en tant que service ( IaaS ) .

Pour exécuter votre application dans GAE, il vous suffit d'écrire votre code et de le déployer dans GAE, sans autre problème. Étant donné que GAE est entièrement évolutif, il acquiert automatiquement plus d'instances si le trafic augmente et diminue les instances lorsque le trafic diminue. Vous serez facturé pour les ressources que vous utilisez réellement , je veux dire, vous serez facturé pour le Instance-Hours , Données transférées , Stockage etc votre application vraiment utilisée. Mais la restriction est que vous pouvez créer votre application uniquement en Python, PHP, Java, NodeJS, .NET, Ruby et ** Go .

D'autre part, GCE vous fournit une infrastructure complète sous la forme de machine virtuelle . Vous avez un contrôle total sur l'environnement et le runtime de ces machines virtuelles, car vous pouvez y écrire ou y installer n'importe quel programme. En réalité, GCE est le moyen d'utiliser virtuellement les centres de données Google. Dans GCE, vous devez configurer manuellement votre infrastructure pour gérer l'évolutivité à l'aide de Load Balancer .

GAE et GCE font tous deux partie de Google Cloud Platform .

Mise à jour: En mars 2014, Google a annoncé un nouveau service sous App Engine nommé machine virtuelle gérée . Les machines virtuelles gérées offrent aux applications de moteur d'applications un peu plus de flexibilité par rapport aux options de plate-forme, de processeur et de mémoire d'applications. Comme GCE, vous pouvez créer un environnement d'exécution personnalisé dans ces machines virtuelles pour l'application du moteur d'applications. Les machines virtuelles réellement gérées d'App Engine brouillent dans une certaine mesure la frontière entre l'IAAS et le PAAS.

Moshe Shaham · Answer

Pour le dire simplement: le moteur de calcul vous donne un serveur sur lequel vous avez le contrôle/la responsabilité. Vous avez un accès direct au système d'exploitation et vous installez tous les logiciels de votre choix, qui sont généralement un serveur Web, une base de données, etc.

Dans le moteur d'applications, vous ne gérez pas le système d'exploitation des logiciels sous-jacents. Vous ne chargez que du code (Java, PHP, Python ou Go) et le tour est joué - il ne fonctionne que ...

Le moteur d'applications économise des tonnes de maux de tête, en particulier pour les personnes inexpérimentées, mais présente 2 inconvénients majeurs: 1. plus cher (mais il a un quota gratuit que le moteur de calcul ne permet pas) 2. vous avez moins de contrôle, certaines choses ne le sont tout simplement pas possible, ou seulement possible d’une manière spécifique (par exemple, enregistrer et écrire des fichiers).

strangetimes · Answer

Ou pour simplifier encore les choses (car nous ne parvenons parfois pas à faire la différence entre GAE Standard et GAE Flex):

Compute Engine est analogue à un PC virtuel, où vous déploieriez un petit site Web + une base de données, par exemple. Vous gérez tout, y compris le contrôle des lecteurs de disque installés. Si vous déployez un site Web, vous êtes responsable de la configuration du DNS, etc.

Google App Engine (Standard) est comme un dossier en bac à sable en lecture seule dans lequel vous importez du code à partir duquel vous exécutez et ne vous inquiétez pas du reste (oui: en lecture seule - il existe un ensemble fixe de bibliothèques installé pour vous et vous ne pouvez pas déployer des bibliothèques tierces à volonté). DNS/Sous-domaines, etc. est tellement plus facile à mapper.

Google App Engine (Flexible) est en fait un système de fichiers complet (pas seulement un dossier verrouillé), dans lequel vous disposez de plus de puissance que le moteur Standard, par exemple. vous avez des autorisations de lecture/écriture (mais moins par rapport à un moteur de calcul). En standard GAE, vous avez installé un ensemble de bibliothèques fixes et vous ne pouvez pas déployer des bibliothèques tierces à volonté. Dans l'environnement Flexible, vous pouvez installer la bibliothèque de votre application, y compris les environnements de construction personnalisés (tels que Python 3).

Bien que GAE Standard soit très fastidieux (bien que Google le fasse simple), il évolue très bien lorsqu'il est mis sous pression. C’est fastidieux car vous devez tester et assurer la compatibilité avec l’environnement verrouillé et vous assurer que les bibliothèques tierces que vous utilisez n’utilisent aucune autre bibliothèque tierce dont vous n’êtes pas au courant et qui pourrait ne pas fonctionner avec la norme GAE. Cela prend plus de temps à mettre en place mais peut être plus gratifiant à long terme pour des déploiements simples.

alexamies · Answer

Outre les notes entre App Engine et Compute Engine, la liste ci-dessus comprend également une comparaison avec Google Kubernete Engine et quelques notes basées sur l'expérience acquise avec une vaste gamme d'applications, de la plus petite à la plus grande. Pour plus de détails, consultez la description détaillée des fonctionnalités de App Engine Standard et Flex dans la documentation de Google Cloud Platform à la page Choix d'un environnement App Engine . Pour une autre comparaison du déploiement d'App Engine et de Kubernetes, voir l'article de Daz Wilkin App Engine Flex ou Kubernetes Engine .

App Engine Standard

Pros

inconvénients

Généralement plus contraint que les autres environnements, les instances sont plus petites. Bien que cela soit utile pour la mise à l'échelle automatique rapide, de nombreuses applications peuvent tirer parti d'instances plus grandes, telles que les instances GCE d'une taille allant jusqu'à 96 cœurs.
La mise en réseau n'est pas intégrée à GCE
Impossible de placer App Engine derrière un équilibreur de charge Google Cloud. Limité aux environnements d'exécution pris en charge: Python 2.7, Java 7 et 8, Go 1.6-1.9 et PHP 5.5. En Java, les servlets sont pris en charge, mais pas le standard J2EE complet.

App Engine Flex

Pros

Peut utiliser un runtime personnalisé
Intégration native avec le réseau GCE
La gestion des versions et du trafic est pratique, comme en standard
Les tailles d'instance plus grandes peuvent convenir davantage aux applications complexes de grande taille, en particulier Java applications pouvant utiliser beaucoup de mémoire.

Les inconvénients

L'intégration réseau n'est pas parfaite - pas d'intégration avec des équilibreurs de charge internes ou des Clouds privés virtuels partagés
L'accès à Memcache géré n'est pas généralement disponible

Moteur Google Kubernetes

Pros

L'intégration native avec des conteneurs permet des temps d'exécution personnalisés et un meilleur contrôle de la configuration du cluster.
Incarne de nombreuses meilleures pratiques fonctionnant avec des machines virtuelles, telles que environnements d'exécution immuables et la possibilité simple de revenir aux versions précédentes.
Fournit une infrastructure de déploiement cohérente et reproductible
Basé sur des standards ouverts, notamment Kubernetes, pour la portabilité entre le cloud et sur site.
La gestion des versions peut être réalisée avec les conteneurs Docker et le Google Container Registry

inconvénients

La division et la gestion du trafic se font de manière autonome, en utilisant éventuellement Istio et Envoy
Quelques frais généraux de gestion
Un peu de temps pour mettre en œuvre les concepts Kubernetes, tels que les modules, les déploiements, les services, l'entrée et les espaces de noms
Il est nécessaire d’exposer certaines adresses IP publiques, sauf si vous utilisez Clusters privés , désormais en version bêta, mais éliminez-le, mais vous devez toujours fournir un accès aux emplacements où les commandes kubectl seront exécutées.
Le suivi de l'intégration n'est pas parfait
Bien que l'équilibrage de charge interne de niveau 3 soit pris en charge de manière native sur Kubernetes Engine, l'équilibrage de charge interne de L7 est autonome, éventuellement en utilisant Envoy.

Moteur de calcul

Pros

Facile à mettre en œuvre - nul besoin de faire appel à Kubernetes ou à App Engine, il vous suffit de réutiliser ce que vous savez de l'expérience précédente. C’est probablement la raison principale pour utiliser Compute Engine directement.
Contrôle total - vous pouvez exploiter directement de nombreuses fonctionnalités de Compute Engine et installer la dernière de vos créations préférées pour rester sur le bord de fond.
Pas besoin d'adresses IP publiques. Certains logiciels existants peuvent être trop difficiles à verrouiller si quelque chose est exposé sur des adresses IP publiques.
Vous pouvez utiliser le système d'exploitation optimisé pour les conteneurs pour exécuter les conteneurs Docker.

inconvénients

Le plus souvent, faites-le vous-même, ce qui peut s'avérer difficile en matière de fiabilité et de sécurité, même si vous pouvez réutiliser des solutions à partir de différents endroits, y compris Cloud Launcher.
Plus de frais généraux de gestion. Il existe de nombreux outils de gestion pour Compute Engine, mais ils ne comprendront pas nécessairement comment vous avez déployé votre application, contrairement aux outils de surveillance App Engine et Kubernetes Engine.
La mise à l'échelle automatique est basée sur des instances GCE, qui peuvent être plus lentes que App Engine
La tendance est d’installer des logiciels sur des instances GCE flocon de neige, ce qui peut représenter un effort de maintenance.

Hassan Azimi · Answer

App Engine donne aux développeurs la possibilité de contrôler les cœurs de Google Compute Engine, ainsi qu'un frontal orienté Web pour les applications de traitement de données de Google Compute Engine.

D'autre part, Compute Engine offre une gestion directe et complète du système d'exploitation de vos machines virtuelles. Pour présenter votre application, vous allez avoir besoin de ressources, et Google Cloud Storage est idéal pour stocker vos actifs et vos données, quelle que soit leur utilisation. Vous obtenez un accès rapide aux données avec l'hébergement dans le monde entier. La fiabilité est garantie avec une disponibilité de 99,95%, et Google offre également la possibilité de sauvegarder et de restaurer vos données, et, croyez-le ou non, le stockage est illimité.

Vous pouvez gérer vos actifs avec Google Cloud Storage, les stocker, les récupérer, les afficher et les supprimer. Vous pouvez également lire et écrire rapidement sur des feuilles de données plates conservées dans Cloud Storage. BigQuery est le suivant dans la gamme Google Cloud. Avec BigQuery, vous pouvez analyser d’énormes quantités de données. Nous parlons de millions d’enregistrements, en quelques secondes. L'accès est géré via une interface utilisateur simple, un transfert d'état représentationnel ou l'interface REST.

Le stockage de données n’est pas un problème, comme vous pouvez le penser, et peut atteindre des centaines de tuberculose. BigQuery est accessible via un hôte de bibliothèques clientes, y compris celles de Java, .NET, Python, Go, Ruby, PHP et Javascript. Une syntaxe de type SQL appelée NoSQL est disponible. Elle est accessible via ces bibliothèques clientes ou via une interface utilisateur Web. Enfin, parlons des options de base de données de la plateforme Google Cloud, Cloud SQL et Cloud Datastore.

Il y a une différence majeure. Cloud SQL est destiné aux bases de données relationnelles, principalement MySQL, alors que Cloud Datastore est destiné aux bases de données non relationnelles utilisant noSQL. Avec Cloud SQL, vous avez le choix entre l'hébergement aux États-Unis, en Europe ou en Asie, avec 100 Go de stockage et 16 Go de RAM par instance de base de données.

Cloud Datastore est disponible gratuitement pour un maximum de 50 000 instructions de lecture/écriture par mois et de 1 Go de données stockées également par mois. Il y a des frais si vous dépassez ces quotas, cependant. App Engine peut également fonctionner avec d'autres membres moins connus et plus ciblés de la plate-forme Google Cloud, notamment les points de terminaison Cloud pour créer des backends d'API, l'API Google Prediction pour l'analyse des données et la prévision des tendances, ou l'API Google Translate pour les sorties multilingues.

Bien que vous puissiez faire beaucoup de choses avec App Engine, cela risque de prendre de l'ampleur si vous tenez compte de sa capacité à travailler facilement et efficacement avec ses autres services de la plate-forme Google Cloud.

noob · Answer

Comme expliqué précédemment, Google Compute Engine (GCE) est l'infrastructure en tant que service (IaaS) tandis que Google App Engine (GAE) est la plate-forme en tant que service (PaaS). Vous pouvez vérifier le diagramme suivant pour mieux comprendre la différence (tiré de et mieux expliqué ici ) -

Google Compute Engine
GCE est un service important fourni par Google Cloud Platform (GCP) car la plupart des services GCP utilisent des instances GCE (VM) situées sous la couche de gestion (il est difficile de déterminer lequel ne le fait pas). Cela inclut App Engine, les fonctions de cloud, le moteur Kubernetes (moteur de conteneur précédent), le cloud SQL, etc. Les instances GCE constituent l'unité la plus personnalisable. Elles ne doivent donc être utilisées que si votre application ne peut pas s'exécuter sur d'autres services GCP. La plupart du temps, les utilisateurs ont recours à GCE pour transférer leurs applications sur site vers GCP, car des modifications minimes sont nécessaires. Plus tard, ils peuvent choisir d’utiliser d’autres services GCP pour des composants distincts de leurs applications.

Google App Engine
GAE est le premier service proposé par GCP (longtemps avant que Google ne se lance dans le cloud). Il passe automatiquement de 0 à un nombre illimité d'instances (il utilise GCE en dessous). Il vient avec 2 saveurs Standard Environment et Flexible Environment.

L’environnement standard est très rapide: jusqu’à 0 cas où personne n’utilise votre application, il évolue en quelques secondes et dispose de services et de bibliothèques Google dédiés à la mise en cache, à l’authentification, etc. car il fonctionne dans un bac à sable. Vous devez utiliser des exécutions gérées pour des langages de programmation spécifiques uniquement. Les ajouts récents sont Node.js (8.x) et Python 3.x. Les anciens runtimes sont disponibles pour Go, PHP, Python 2.7, Java etc.

L'environnement flexible est plus ouvert car il vous permet d'utiliser des exécutions personnalisées, car il utilise des conteneurs Docker. Ainsi, si votre environnement d'exécution n'est pas disponible dans les environnements d'exécution fournis, vous pouvez toujours créer votre propre fichier docker pour l'environnement d'exécution. Le bémol avec cela est qu'il faut avoir au moins une instance en cours d'exécution, même si personne n'utilise votre application, de plus, la mise à l'échelle en plus et en moins demande quelques minutes.

Ne confondez pas GAE flexible avec Kubernetes Engine, car ce dernier utilise Kubernetes et offre beaucoup plus de personnalisation et de fonctionnalités. GAE Flex est utile lorsque vous souhaitez des conteneurs sans état et que votre application repose uniquement sur les protocoles HTTP ou HTTPS. Pour les autres protocoles, Kubernetes Engine (GKE) ou GCE est votre seul choix. Vérifiez mon autre réponse pour une meilleure explication.

Ali Khosro · Answer

Je vais l'expliquer d'une manière qui a du sens pour moi:

Compute Engine: Si vous êtes un bricoleur ou si vous avez une équipe informatique et que vous voulez simplement louer un ordinateur sur le cloud avec un système d’exploitation spécifique (par exemple, Linux), vous optez pour Compute Engine. . Vous devez tout faire vous-même.
App Engine: Si vous êtes (par exemple) un programmeur python et que vous souhaitez louer un ordinateur préconfiguré sur un nuage fonctionnant sous Linux avec un serveur Web en cours d'exécution et le dernier python 3 avec les modules nécessaires et certains plug-ins à intégrer à d'autres services externes, vous choisissez App Engine.
Serverless Container (Cloud Run): Si vous souhaitez déployer l'image exacte de votre environnement de configuration local (par exemple: python 3.7 + flask + sklearn) mais vous ne souhaitez pas traiter le serveur, la mise à l'échelle, etc. Vous créez un conteneur sur votre ordinateur local (via docker), puis vous le déployez dans Google Run.
Serverless Microservice (Fonctions Cloud): Si vous souhaitez écrire un ensemble d’API (fonctions) effectuant un travail spécifique, vous devez utiliser Google Cloud Functions. Vous vous concentrez uniquement sur ces fonctions spécifiques, le reste du travail (serveur, maintenance, mise à l'échelle, etc.) est effectué pour vous afin d'exposer vos fonctions sous forme de microservices.

Au fur et à mesure que vous avancez, vous perdez un peu de flexibilité mais vous ne craignez pas les aspects techniques inutiles. Vous payez également un peu plus, mais vous gagnez du temps et de l’argent (partie informatique): une autre personne (Google) le fait pour vous.

Pour moi, Google Cloud est mon département informatique et DevOp. Je développe sur ma machine, crée un conteneur via docker, le déploie dans Cloud Run et ne me préoccupe pas de la mise à l'échelle et de la maintenance. À travers, j'ai essayé toutes les autres options et chacune est bonne pour un but différent.