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

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

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

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 cher qu'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. Ils fonctionnent tous les deux bien avec les autres parties de Google Cloud Platform .

EDIT (mai 2016):

Une autre distinction importante: les projets exécutés sur App Engine peuvent être réduits à zéro instance si aucune demande n'est reçue. Ceci 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 d'instance. L'exécution flexible (c'est-à-dire les "VM gérées") nécessite au moins une instance pour s'exécuter en permanence.

EDIT (avril 2017):

Cloud Functions (actuellement en version bêta) est le niveau supérieur d'App Engine en termes d'abstraction - pas d'instances! Il permet aux développeurs de déployer des morceaux de code de petite taille qui s'exécutent en réponse à différents événements, qui peuvent inclure des demandes HTTP, des modifications dans le stockage cloud, etc.

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

Cela rend les fonctions cloud idéales pour (a) les appels rares - pas besoin de maintenir une instance en direct au cas où quelque chose se produirait, (b) les charges changeant rapidement où les instances tournent et s'arrêtent souvent, et peut-être plus de cas d'utilisation.

En savoir plus sur les fonctions cloud

La différence fondamentale est que Google App Engine ( GAE ) est une plate - forme en tant que service ( PaaS ) tandis que Google Compute Engine ( GCE ) est une 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, pas d'autre mal de tête. Étant donné que GAE est entièrement évolutif, il acquiert automatiquement plus d'instances au cas où le trafic augmente et diminue les instances lorsque le trafic diminue. Vous serez facturé pour les ressources que vous utilisez vraiment , je veux dire, vous serez facturé pour les heures d'instance , les données transférées , le stockage, etc. que votre application a vraiment utilisé. Mais la restriction est que vous pouvez créer votre application uniquement en Python, PHP, Java, NodeJS, .NET, Ruby et ** Go .

D'un autre côté, GCE vous fournit une infrastructure complète sous forme de machine virtuelle . Vous avez un contrôle total sur l'environnement et le runtime de ces VMs car vous pouvez y écrire ou installer n'importe quel programme. En fait, 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 partie de Google Cloud Platform .

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

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

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

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

Ou pour le rendre encore plus simple (car parfois nous ne parvenons 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 unités de disque installées. 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 téléchargez du code à exécuter et ne vous inquiétez pas du reste (oui: en lecture seule - un ensemble fixe de bibliothèques est installé pour vous et vous ne pouvez pas déployer Bibliothèques tierces à volonté). DNS / sous-domaines, etc. est tellement plus facile à cartographier.

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

Bien que la norme GAE soit très lourde à gérer (bien que Google la rend simple), elle évolue très bien lorsqu'elle est mise sous pression. C'est encombrant car vous devez tester et garantir la compatibilité avec l'environnement verrouillé et vous assurer que toute bibliothèque tierce que vous utilisez n'utilise aucune autre bibliothèque tierce que vous ignorez et qui pourrait ne pas fonctionner avec la norme GAE. Il faut plus de temps pour le configurer dans la pratique, mais peut être plus gratifiant à long terme pour des déploiements simples.

En plus des notes App Engine vs Compute Engine ci-dessus, la liste comprend également une comparaison avec Google Kubernete Engine et quelques notes basées sur l'expérience avec un large éventail d'applications, de petite à très grande. Pour plus de points, consultez la description de haut niveau de la documentation Google Cloud Platform des fonctionnalités d'App Engine Standard et Flex sur 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 .

Norme App Engine

Avantages

• Très économique pour les applications à faible trafic en termes de coûts directs et également de maintenance de l'application.
• La mise à l'échelle automatique est rapide. La mise à l'échelle automatique dans App Engine est basée sur les classes d'instances légères F1-F4 .
• La gestion des versions et la répartition du trafic sont rapides et pratiques. Ces fonctionnalités sont intégrées à App Engine (Standard et Flex) en mode natif.
• Gestion minimale, les développeurs doivent se concentrer uniquement sur leur application. Les développeurs n'ont pas à se soucier de la gestion des machines virtuelles dans un environnement fiable, comme dans GCE, ou de se renseigner sur les clusters, comme avec GKE.
• L'accès à Datastore est rapide. Lorsque App Engine a été publié pour la première fois, le runtime était colocalisé avec Datastore. Plus tard, Datastore a été divisé en tant que produit autonome Cloud Datastore, mais la colocalisation d'App Engine Standard avec Datastore demeure.
• L'accès à Memcache est pris en charge.
• Le sandbox App Engine est très sécurisé. Par rapport au développement sur GCE ou d'autres machines virtuelles, où vous devez faire votre propre diligence pour empêcher la prise en charge de la machine virtuelle au niveau du système d'exploitation, le sandbox App Engine Standard est relativement sécurisé par défaut.

Les inconvénients

• Généralement plus contraint que les autres environnements Les instances sont plus petites. Bien que cela soit bon pour une mise à l'échelle automatique rapide, de nombreuses applications peuvent bénéficier d'instances plus importantes, telles que des tailles d'instance GCE 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 runtimes pris en charge: Python 2.7, Java 7 et 8, Go 1.6-1.9 et PHP 5.5. En Java, il existe une certaine prise en charge des servlets, mais pas la norme J2EE complète.

App Engine Flex

Avantages

• Peut utiliser un runtime personnalisé
• Intégration native avec le réseau GCE
• La gestion des versions et du trafic est pratique, identique à la norme
• Les tailles d'instance plus importantes peuvent être plus adaptées aux grandes applications complexes, en particulier aux applications Java qui peuvent utiliser beaucoup de mémoire

Les inconvénients

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

Google Kubernetes Engine

Avantages

• L'intégration native avec les conteneurs permet des exécutions personnalisées et un meilleur contrôle sur la configuration du cluster.
• Incarne de nombreuses meilleures pratiques de travail avec des machines virtuelles, telles que des environnements d'exécution immuables et une capacité facile à revenir aux versions précédentes
• Fournit un cadre de déploiement cohérent et reproductible
• Basé sur des standards ouverts, notamment Kubernetes, pour la portabilité entre les clouds et sur site.
• La gestion des versions peut être réalisée avec les conteneurs Docker et le Google Container Registry

Les inconvénients

• La répartition et la gestion du trafic se font par vous-même, en exploitant éventuellement Istio et Envoy
• Certains frais de gestion
• Un certain temps pour accélérer les concepts Kubernetes, tels que les pods, les déploiements, les services, les entrées et les espaces de noms
• Besoin d'exposer certaines adresses IP publiques, sauf si l'utilisation de clusters privés , désormais en version bêta, élimine ce besoin, mais vous devez toujours fournir un accès aux emplacements à partir desquels les commandes kubectl seront exécutées.
• La surveillance de l'intégration n'est pas parfaite
• Alors que l'équilibrage de charge interne L3 est pris en charge nativement sur Kubernetes Engine, l'équilibrage de charge interne L7 est à faire soi-même, en tirant éventuellement parti d'Envoy

Moteur de calcul

Avantages

• Facile à monter en puissance - pas besoin de monter en puissance sur Kubernetes ou App Engine, il suffit de réutiliser tout ce que vous savez de l'expérience précédente. C'est probablement la principale raison d'utiliser directement Compute Engine.
• Contrôle complet - vous pouvez exploiter directement de nombreuses fonctionnalités de Compute Engine et installer les dernières de toutes vos fonctionnalités préférées pour rester à la pointe du progrès.
• Pas besoin d'adresses IP publiques. Certains logiciels hérités peuvent être trop difficiles à verrouiller si quelque chose est exposé sur des adresses IP publiques.
• Vous pouvez utiliser le système d'exploitation optimisé par conteneur pour exécuter des conteneurs Docker

Les inconvénients

• Surtout à faire soi-même, ce qui peut être difficile à faire de manière adéquate pour la fiabilité et la sécurité, bien que vous puissiez réutiliser des solutions à partir de divers endroits, y compris le lanceur de cloud.
• 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, comme le font les 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 les instances GCE de flocon de neige, ce qui peut être un effort pour maintenir

Comme déjà expliqué, Google Compute Engine (GCE) est l'Infrastructure as a service (IaaS) tandis que Google App Engine (GAE) est Platform as a Service (PaaS). Vous pouvez vérifier le diagramme suivant pour mieux comprendre la différence (extrait 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) sous la couche de gestion (vous ne savez pas laquelle ne fait pas). Cela inclut App Engine, Cloud Functions, Kubernetes Engine (Earlier Container Engine), Cloud SQL, etc. Les instances GCE sont l'unité la plus personnalisable et ne doivent donc être utilisées que lorsque votre application ne peut pas s'exécuter sur d'autres services GCP. La plupart du temps, les gens utilisent GCE pour transférer leurs applications sur site vers GCP, car cela nécessite un minimum de modifications. Plus tard, ils peuvent choisir d'utiliser d'autres services GCP pour un composant distinct de leurs applications.

Google App Engine
GAE est le premier service proposé par GCP (bien avant l'arrivée de Google dans le cloud). Il évolue automatiquement de 0 à un nombre illimité d'instances (il utilise GCE en dessous). Il est livré avec 2 saveurs environnement standard et environnement flexible.

L'environnement standard est vraiment rapide, passe à 0 instance lorsque personne n'utilise votre application, monte et descend en quelques secondes et dispose de services et de bibliothèques Google dédiés pour la mise en cache, l'authentification, etc. La mise en garde avec l'environnement standard est qu'elle est très restrictive car il fonctionne dans un bac à sable. Vous devez utiliser les runtimes gérés 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 runtimes personnalisés car il utilise des conteneurs Docker. Ainsi, si votre runtime n'est pas disponible dans les runtimes fournis, vous pouvez toujours créer votre propre dockerfile pour l'environnement d'exécution. La mise en garde avec cela est, cela nécessite d'avoir au moins 1 instance en cours d'exécution, même si personne n'utilise votre application, plus la montée en puissance et la réduction en quelques minutes.

Ne confondez pas GAE flexible avec Kubernetes Engine, car le dernier utilise Kubernetes réel 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 s'appuie 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.

App Engine donne aux développeurs la possibilité de contrôler les cœurs de Google Compute Engine, ainsi que de fournir une interface 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, quels qu'ils soient. Vous bénéficiez d'un accès rapide aux données grâce à l'hébergement dans le monde entier. La fiabilité est garantie à 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 fiches techniques plates conservées dans Cloud Storage. Ensuite, dans la gamme Google Cloud, BigQuery. 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, ou un transfert d'état représentatif ou une interface REST.

Le stockage des données n'est pas, comme vous pouvez le soupçonner, un problème et évolue jusqu'à des centaines de To. BigQuery est accessible via une multitude de bibliothèques clientes, y compris celles pour Java, .NET, Python, Go, Ruby, PHP et Javascript. Une syntaxe de type SQL appelée NoSQL est disponible, 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, tandis que Cloud Datastore est destiné aux bases de données non relationnelles utilisant noSQL. Avec Cloud SQL, vous avez le choix d'héberger 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 sans frais pour jusqu'à 50 Ko d'instructions de lecture / écriture par mois et 1 Go de données stockées également par mois. Il y a cependant des frais si vous dépassez ces quotas. App Engine peut également fonctionner avec d'autres membres moins connus et plus ciblés de la plate-forme Google Cloud, y compris les Cloud Endpoints pour créer des backends API, Google Prediction API pour l'analyse des données et la prévision des tendances, ou l'API Google Translate, pour une sortie multilingue.

Bien que vous puissiez faire beaucoup avec App Engine par lui-même, il s'agit de montées en flèche potentielles lorsque vous tenez compte de sa capacité à travailler facilement et efficacement avec ses autres services de plate-forme Google Cloud.

Si vous connaissez d'autres services populaires:

Google Compute Engine -> AWS EC2

Google App Engine -> Heroku ou AWS Elastic Beanstalk

Fonctions Google Cloud -> Fonctions AWS Lambda

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

• Compute Engine : Si vous êtes bricoleur ou avez une équipe informatique et que vous souhaitez simplement louer un ordinateur sur le cloud qui a un système d'exploitation spécifique (par exemple Linux), vous optez pour le Compute Engine. Vous devez tout faire par vous-même.

• App Engine : si vous êtes (par exemple) un programmeur python et que vous souhaitez louer un ordinateur préconfiguré sur le cloud avec 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 avec d'autres services externes, vous optez pour l'App Engine.

• Conteneur sans serveur (Cloud Run) : si vous souhaitez déployer l'image exacte de votre environnement d'installation local (par exemple: python 3.7 + flask + sklearn) mais que vous ne voulez pas traiter avec le serveur, la mise à l'échelle, etc. Vous créez un conteneur sur votre ordinateur local (via Docker), puis déployez-le sur Google Run.

• Microservice sans serveur (fonctions cloud) : si vous voulez écrire un tas d'API (fonctions) qui font un travail spécifique, vous allez pour Google Cloud Functions. Vous vous concentrez uniquement sur ces fonctions spécifiques, le reste du travail (serveur, maintenance, mise à l'échelle, etc.) est fait pour vous afin d'exposer vos fonctions en tant que microservices.

Au fur et à mesure que vous approfondissez, vous perdez une certaine flexibilité mais vous ne vous inquiétez pas des aspects techniques inutiles. Vous payez également un peu plus mais vous économisez du temps et de l'argent (partie informatique): quelqu'un d'autre (google) le fait pour vous.

Si vous ne voulez pas vous soucier de l'équilibrage de charge, de la mise à l'échelle, etc., il est essentiel de diviser votre application en un groupe de services Web "sans état" qui écrit tout ce qui persiste dans un stockage séparé (base de données ou stockage d'objets blob). Ensuite, vous découvrirez à quel point Cloud Run et les fonctions Cloud sont géniaux.

Personnellement, j'ai trouvé que Google Cloud Run était une solution géniale, une liberté absolue de développement (aussi longtemps qu'apatride), l'exposer en tant que service Web, ancrer votre solution, la déployer avec Cloud Run. Laissez Google être votre informatique et DevOps, vous n'avez pas besoin de vous soucier de la mise à l'échelle et de la maintenance.

J'ai essayé toutes les autres options et chacune est bonne à des fins différentes, mais Google Run est tout simplement génial. Pour moi, c'est le vrai sans serveur sans perdre en souplesse de développement.

Les services cloud offrent une gamme d'options allant des services entièrement gérés aux services moins gérés. Des services moins gérés donnent plus de contrôle aux développeurs. La même chose est la différence dans le moteur de calcul et d'application également. L'image ci-dessous donne plus de détails sur ce point

Google Compute Engine (GCE)

Machines virtuelles (VM) hébergées dans le cloud. Avant le cloud, ceux-ci étaient souvent appelés serveurs privés virtuels (VPS). Vous les utiliseriez de la même manière que vous utiliseriez un serveur physique, où vous installez et configurez le système d'exploitation, installez votre application, installez la base de données, gardez le système d'exploitation à jour, etc. Ceci est connu sous le nom d'Infrastructure- en tant que service (IaaS).

Les machines virtuelles sont plus utiles lorsque vous avez une application existante exécutée sur une machine virtuelle ou un serveur dans votre centre de données et que vous souhaitez la migrer facilement vers GCP.

Google App Engine

App Engine héberge et exécute votre code, sans vous obliger à gérer le système d'exploitation, la mise en réseau et de nombreuses autres choses que vous auriez à gérer avec un serveur physique ou une machine virtuelle. Considérez-le comme un runtime, qui peut automatiquement déployer, versionner et faire évoluer votre application. Cela s'appelle Platform-as-a-Service (PaaS).

App Engine est particulièrement utile lorsque vous souhaitez un déploiement automatisé et une mise à l'échelle automatisée de votre application. À moins que votre application ne nécessite une configuration de système d'exploitation personnalisée, App Engine est souvent avantageux par rapport à la configuration et à la gestion des machines virtuelles à la main.