Difference between Google App Engine Flexible and Google Container Engine?

Question

Specific to Docker based deployment, what are the differences between those two? Since Google App Engine Flexible now also supports Dockerfile based deployment and it is also fu

Answer 1

The main benefit apart from what is mentioned in Javier's answer is that using Kubernetes makes your application portable and independent of the underlying cloud platform. If you ever want to move your application to AWS, Azure, on-prem etc. you can do that with very few changes if you're using Kubernetes, while if you're on App Engine Flex, it'll require a lot more changes.

Another difference is if you want to create lots of different micro-services with complex structure, Kubernetes is more suited to that, instead of App Engine. It's not impossible to implement micro-service architecture in App Engine too. You can certainly use different yaml files, but those doesn't give you a lot of flexibility and any complex application will ultimately need to be ported.

Also, if you want to have stateful containers, you can't do that with App Engine Flex.

Kubernetes being an open-source project has more vibrant community than App Engine. Google is more focused on Kubernetes than App Engine and updates to Kubernetes are more frequent than App Engine.

But that doesn't mean App Engine is any less powerful. I have worked on complex applications serving hundreds of thousands (probably a million now) of users with App Engine (Both standard and flexible environment) and we never thought of migrating it out of GAE. I mean, if it can handle the traffic of Pokemon Go, it can certainly handle your app's too.

Performance wise someone did a comparison here. The summary results are as follows -

An important difference between the services is that App Engine Flex biases automation to Google’s control whereas Kubernetes Engine requires more oversight by the customer. Kubernetes Engine is evolving more rapidly and is adding more powerful automation.

A subtle difference is that Flex uses containers as a means to an end. Customarily, users of Flex could ignore that containers are being employed because this is done behind the scenes. Kubernetes Engine — as the name suggests — is predicated on containers and is explicitly designed as a tool that facilitates the management of services built from containers. With Flex, a service is always n-containers of one type. With Kubernetes Engine, a service comprises m-pods and the pods may themselves comprise p-containers.

• It is practical to migrate an App Engine Flex deployment to GKE
• In this case (!) Flex achieved greater throughput than GKE.
• The increased velocity appears due to the rapidity with which App Engine
  is able to signal auto-scaling events; GKE scales pods promptly
  within an existing cluster of nodes but slightly more slowly to scale up the number of nodes.
• App Engine and GKE share fundamental GCP resources including the HTTP/S Load-Balancer service and Managed Infrastructure Groups auto-scaling.
• For the same load, using the same VM size (1 vCPU and 1GB RAM): App Engine Flex scaled to 6 containers on 6 instances VMs (1 instance/VM ); GKE scaled to 10 pods (1 container/pod) on 3 VMs (50%).