Différence entre Google App Engine Flexible et Google Container Engine?
Spécifiques au déploiement basé sur Docker, quelles sont les différences entre ces deux? Étant donné que Google App Engine Flexible prend désormais également en charge le déploiement basé sur Dockerfile et qu'il s'agit également d'un service entièrement géré, il semble que ce soit l'option préférée plutôt que de configurer le déploiement de Kubernetes sur Container Engine, n'est-ce pas?
Quels sont les cas d'utilisation où il est préférable d'utiliser Google Container Engine plutôt que App Engine Flexible?
Ce sont des choses différentes. App Engine Flexible se concentre sur le développement d'applications - c'est-à-dire que vous avez une application et que vous souhaitez être déployé et géré par Google). D'un autre côté, Kubernetes consiste davantage à avoir sa propre infrastructure. Évidemment, vous pouvez également déployer des applications dans Kubernetes mais, comme c'est votre "propre" infrastructure, vous êtes le seul à gérer directement le comportement de l'application et de celle-ci (créer des services, créer des politiques d'évolutivité, RBAC, politiques de sécurité ...) .
En ce sens, Kubernetes est plus flexible dans ce que vous pouvez réaliser. Cependant, en tant que développeur, vous ne serez peut-être pas du tout intéressé par l'infrastructure, mais uniquement par le fait que votre application fonctionne et évolue. Pour ce type de profil, App Engine Flexible est plus adapté.
Si, de l'autre côté, vous souhaitez gérer une infrastructure de conteneur complète (plus de profil SRE), Kubernetes est fait pour vous.
Le principal avantage en dehors de ce qui est mentionné dans réponse de Javier est que l'utilisation de Kubernetes rend votre application portable et indépendante de la plate-forme cloud sous-jacente. Si vous souhaitez déplacer votre application vers AWS, Azure, sur site, etc., vous pouvez le faire avec très peu de modifications si vous utilisez Kubernetes, tandis que si vous êtes sur App Engine Flex, cela nécessitera beaucoup plus changements.
Une autre différence est que si vous souhaitez créer de nombreux micro-services différents avec une structure complexe, Kubernetes est plus adapté à cela, au lieu d'App Engine. Il n'est pas impossible non plus d'implémenter une architecture de microservices dans App Engine. Vous pouvez certainement utiliser différents fichiers yaml, mais ceux-ci ne vous donnent pas beaucoup de flexibilité et toute application complexe devra finalement être portée.
De plus, si vous souhaitez avoir des conteneurs avec état, vous ne pouvez pas le faire avec App Engine Flex.
Kubernetes étant un projet open-source, la communauté est plus dynamique qu'App Engine. Google est plus concentré sur Kubernetes que sur App Engine et les mises à jour de Kubernetes sont plus fréquentes que sur App Engine.
Mais cela ne signifie pas qu'App Engine est moins puissant. J'ai travaillé sur des applications complexes desservant des centaines de milliers (probablement un million maintenant) d'utilisateurs avec App Engine (environnement standard et flexible) et nous n'avons jamais pensé à le migrer hors de GAE. Je veux dire, s'il peut gérer le trafic de Pokemon Go, il peut certainement aussi gérer votre application.
En termes de performances, quelqu'un a fait une comparaison ici . Les résultats sommaires sont les suivants -
Une différence importante entre les services est que App Engine Flex oriente l'automatisation vers le contrôle de Google, tandis que Kubernetes Engine nécessite plus de surveillance de la part du client. Kubernetes Engine évolue plus rapidement et ajoute une automatisation plus puissante.
Une différence subtile est que Flex utilise des conteneurs comme moyen d'atteindre une fin. Habituellement, les utilisateurs de Flex peuvent ignorer que des conteneurs sont utilisés car cela se fait en arrière-plan. Kubernetes Engine - comme son nom l'indique - est basé sur des conteneurs et est explicitement conçu comme un outil qui facilite la gestion des services construits à partir de conteneurs. Avec Flex, un service est toujours composé de n conteneurs d'un type. Avec Kubernetes Engine, un service comprend des m-pods et les pods peuvent eux-mêmes comprendre des p-containers.
- Il est pratique de migrer un déploiement App Engine Flex vers GKE
- Dans ce cas (!) Flex a atteint un débit supérieur à GKE.
- La vitesse accrue apparaît en raison de la rapidité avec laquelle App Engine
est capable de signaler des événements de mise à l'échelle automatique; GKE redimensionne rapidement les pods
dans un cluster de nœuds existant mais légèrement plus lentement pour augmenter le nombre de nœuds.- App Engine et GKE partagent des ressources GCP fondamentales, notamment le service d'équilibrage de charge HTTP/S et la mise à l'échelle automatique des groupes d'infrastructures gérées.
- Pour la même charge, en utilisant la même taille VM (1 vCPU et 1 Go de RAM): App Engine Flex mis à l'échelle à 6 conteneurs sur 6 instances VM (1 instance/VM); GKE mis à l'échelle à 10 pods (1 conteneur/pod) sur 3 VM (50%).
Si vous cherchez à exécuter votre application 24h/24 et 7j/7, GKE propose également plus de vCPU et de ressources RAM à un prix inférieur par rapport à App Engine également. Vous pouvez réduire davantage vos coûts de fonctionnement si vous exécutez vos applications avec VM préemptives (jusqu'à 80% moins cher que les VM normales), sur Kubernetes, votre application sera redémarrée avec quelques secondes de temps d'arrêt.
Un autre avantage de GKE est que vous pouvez exécuter plusieurs applications dans le même cluster tandis qu'App Engine vous facture par application déployée.
PS: je gère plusieurs sites sur un cluster GKE. Faire cela sur App Engine me coûtera quelques fois plus que ce que je paie actuellement.