Google App Engine vs Google Kubernetes Engine: What are the differences?
Google App Engine: Build web applications on the same scalable systems that power Google applications. Google has a reputation for highly reliable, high performance infrastructure. With App Engine you can take advantage of the 10 years of knowledge Google has in running massively scalable, performance driven systems. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow; Google Kubernetes Engine: Deploy, manage, and scale containerized applications on Kubernetes, powered by Google Cloud. Container Engine takes care of provisioning and maintaining the underlying virtual machine cluster, scaling your application, and operational logistics like logging, monitoring, and health management.
Google App Engine belongs to "Platform as a Service" category of the tech stack, while Google Kubernetes Engine can be primarily classified under "Containers as a Service".
Some of the features offered by Google App Engine are:
- Zero to sixty: Scale your app automatically without worrying about managing machines.
- Supercharged APIs: Supercharge your app with services such as Task Queue, XMPP, and Cloud SQL, all powered by the same infrastructure that powers the Google services you use every day.
- You're in control: Manage your application with a simple, web-based dashboard allowing you to customize your app's performance.
On the other hand, Google Kubernetes Engine provides the following key features:
- Docker support - Improve the predictability of your deployments with Docker containers. Containers make it easy to deploy applications across environments.
- Better ops - Give ops a better system, starting with a managed compute cluster. Container Engine takes care of provisioning and maintaining the underlying virtual machines and operational logistics like logging, monitoring, and health management.
- Declarative management - Use declarative syntax to define your application requirements. Container Engine will actively manage your application, ensuring your containers are running and scheduling additional as needed.
"Easy to deploy" is the primary reason why developers consider Google App Engine over the competitors, whereas "Powered by kubernetes" was stated as the key factor in picking Google Kubernetes Engine.
According to the StackShare community, Google App Engine has a broader approval, being mentioned in 482 company stacks & 345 developers stacks; compared to Google Kubernetes Engine, which is listed in 184 company stacks and 50 developer stacks.
What is Google App Engine?
What is Google Kubernetes Engine?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Google App Engine?
What are the cons of using Google Kubernetes Engine?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
So, the shift from Amazon EC2 to Google App Engine and generally #AWS to #GCP was a long decision and in the end, it's one that we've taken with eyes open and that we reserve the right to modify at any time. And to be clear, we continue to do a lot of stuff with AWS. But, by default, the content of the decision was, for our consumer-facing products, we're going to use GCP first. And if there's some reason why we don't think that's going to work out great, then we'll happily use AWS. In practice, that hasn't really happened. We've been able to meet almost 100% of our needs in GCP.
So it's basically mostly Google Kubernetes Engine , we're mostly running stuff on Kubernetes right now.
#AWStoGCPmigration #cloudmigration #migration
We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.
We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An
upgrade-operator process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.
The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.
With Cloud Endpoints you can create and deploy mobile backend in one hour or less. And it is free (until you need extra scale). I would not recommend to use Java - python is faster and has all new appengine features.
Pros: everything is in one place: task queue, cron, backend instances for data processing, datastore, mapreduce. Cons: you cannot easily move your code from GAE. Even with special 3rd party services.
Since it is mostly backed by Kubernetes, GCE looks really promising. I did run into some fuzzy bugs as I did expect with Alpha.
I recommend giving it a lab-test-try and engage in discussion about Kubernetes.
With Cloud Endpoints you can create and deploy mobile backend in one hour or less.
PaaS for back-end components, including external data ingestion APIs, front-end web service APIs, hosting of static front-end application assets, back-end data processing pipeline microservices, APIs to storage infrastructure (Cloud SQL and Memcached), and data processing pipeline task queues and cron jobs. Task queue fan-out and auto-scaling of back-end microservice instances provide parallelism for high velocity data processing.
checking a swap require a lot of cpu resource, roster normally come out same day of month, every month, at a particular time. Which make very high spike, our flag ship product, iSwap, with the capability looking swap possibility with 10000 other rosters base on user critieria, you need a cloud computing give you this magnitude of computing power. gae did it nicely, user friendly, easy to you, low cost.
App engine fills in the gaps in the increasingly smaller case where it's necessary for us to run our own APIs.
Very easy to make cloud computing of ML models , and use containers like Kubernetes.
used this when setting up the kubernetes infrastructure for a client.
Cloud instances to run our app, Cloud MySQL , Network Load Balancer