Google App Engine vs. Kubernetes Engine
What's the difference between Google App Engine and Kubernetes Engine? Ranging from manageability to deployment, we will cover several distinctions.
Organizations are moving towards containerisation for their workloads. While containers give several benefits, it’s important to choose suitable container orchestration according to our requirements and use cases to get full benefit of the container ecosystem.
Kubernetes and Google App Engine are very well-known systems for running containerized workloads.
In this article, we’ll discuss comparisons in the offering of Kubernetes and Google App Engine.
Introduction:
- Kubernetes is a production grade open-source container orchestration service for automating deployment, scaling and managing containerized workloads and services.
- Google App Engine is a managed service by Google Cloud Platform for build and run applications in the form of containers.
Manageability (Administration):
- Google App Engine is a fully-managed service that doesn’t worry about underlying infrastructure. Setup for Google App Engine can be done by UI in Google Cloud Platform, or by simple commands. App engine scales seamlessly according to traffic. Not much expertise is needed to start with Google App Engine and work with it in production.
- By contrast, we can deploy either a self-managed Kubernetes Cluster or spin up a cloud provider managed cluster like Google Kubernetes Engine, Amazon Elastic Kubernetes Service, or Azure Kubernetes Service, etc. While spinning up a Kubernetes cluster with a managed service is easy, proper expertise is needed to run both a self-managed or Cloud provider managed Kubernetes cluster in production, and to scale them according to requirement. Similarly, there are nearly zero maintenance activities needed while using Google App Engine. While in Kubernetes, we might need maintenance activities in both self-managed, and Cloud provider managed Kubernetes clusters, like Kubernetes version upgrade, etc.
Cloud Agnostic:
- Google App Engine is a fully managed service by Google Cloud and you need to write code in the Google App Engine way to fully utilize it. However, it can cause issues while migrating your services from Google App Engine to other platforms, or other Cloud providers. It would need a lot of code changes, and would never be easy for a large-scale application.
- On the other hand, while running your workloads in Kubernetes, either in a self-managed cluster, or in a Cloud provider managed cluster, you can easily migrate your workloads without any code changes. As soon as your Kubernetes cluster is up in another cloud provider, you can start migrating your workload easily.
Monitoring And Logging:
- Being a fully-managed service, you don’t need to worry about setup monitoring and logging for your services in Google App Engine. Google App Engine offers Stackdriver and Logging service for monitoring and logging requirements of your workloads.
- In Kubernetes, you need to deploy both monitoring and logging solutions according to your service requirement. There are many good open source solutions available like Prometheus, Fluentd, Fluent Bit, and Graylog for fulfilling monitoring and logging requirements. In addition to open source solutions, you can also choose commercial or cloud provider solutions, which can be easily integrated with Kubernetes Engine.
Cost:
Kubernetes is an open-source container orchestration service and there’s no need to purchase an extra license for it. If we compare the underlying infrastructure cost for both Kubernetes Engine and Google App Engine with 20 CPU and 75 GB of memory, then Google App Engine costs approximately USD $1,156.69, while Kubernetes costs just USD $485.45.
This is a very basic estimate for Google Cloud and includes only CPU and Memory cost, it does not account for other resource costs like Network Traffic, disk space, etc.
Stateful Applications:
Google App Engine doesn’t support stateful applications unfortunately - it’s built for stateless applications exclusively. By contrast, with Kubernetes, you can deploy both stateless and stateful applications in the form of containers.
Deployment Time:
- Google App Engine takes more time in deployment - sometimes it can take several minutes for deployment to complete in Google App Engine. This deployment time includes both building Docker Image and deploying them on the underlying VM.
- In Kubernetes, Deployment can be done in just a few seconds (or minutes) once the docker images are available. In both the cases, deployment time also depends on your deployment strategy and scale of application.
Internal Service Deployment:
Google App Engine provides flexibility to spin up underlying Virtual Machines in specific subnetworks, and assign specific network tags to them. Using these subnetwork and network tags, you can ‘whitelist’ your service based on requirement and treat them as an internal service. However, this might become unmanageable after more services are introduced and would require internal-only access. On the other hand, in Kubernetes Engine, you can easily manage both your internal and external services, and scale them as needed for your architecture.
Underlying Infrastructure Security:
- Being a fully-managed service, Google App Engine exposes your service and takes care of underlying infrastructure security. In addition, you can add firewall rules, and restrict your service to particular, specified networks.
- In Kubernetes, you’ll need to take care of the security of your Kubernetes cluster. While managed clusters can reduce this work, you’ll still need to take care of the underlying infrastructure security, and follow best practices to avoid any possible security breaches.
Learning Curve:
- Getting started with Google App Engine is easy, and anyone can start working with it immediately after reading a few tutorials.
- By contrast, Kubernetes Engine has a steep learning curve, is a little bit difficult to get started with, and takes time to fully understand conceptually, but ultimately has large scalable payoff.
Deployment Demo:
In this Demo, we will deploy a simple python application in both Google App Engine and Kubernetes.
Kindly replace your-project with your actual project in required commands.
Google App Engine Deployment:
Step 1: Create a Google App Engine application.
You can skip this step if you already have one in your project.
$gcloud app create --project="your-project" --region="asia-south1"
vikassmacbook:~ vikassaini$ gcloud app create --project="your-project" --region="asia-south1"
You are creating an app for project [your-project].
WARNING: Creating an App Engine application for a project is irreversible and the region
cannot be changed. More information about regions is at
.
Creating App Engine application in project [your-project] and region [asia-south1]....done.
Success! The app is now created. Please use `gcloud app deploy` to deploy your first app.
Step 2: Create Application app.py and respective deployment file app.yaml.
app.py
from flask import Flask
flask_app = Flask(__name__)
@flask_app.route('/')
def hello_world():
return 'Hello World'
app.yaml
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /.*
script: app.flask_app
libraries:
- name: flask
version: 0.12
Step 3: Deploy Application in Google App Engine
Run below command to deploy application in Google App Engine.
gcloud app deploy ./app.yaml --project="your-project" -q
vikassmacbook:appengine vikassaini$ gcloud app deploy ./app.yaml --project="your-project" -q
Services to deploy:
descriptor: [/Users/vikassaini/blog/examples/appengine/app.yaml]
source: [/Users/vikassaini/blog/examples/appengine]
target project: [your-project]
target service: [default]
target version: [20200420t220922]
target url: [https://your-project.el.r.appspot.com]
Beginning deployment of service [default]...
╔════════════════════════════════════════════════════════════╗
╠═ Uploading 1 file to Google Cloud Storage ═╣
╚════════════════════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://your-project.el.r.appspot.com]
You can stream logs from the command line by running:
$ gcloud app logs tail -s default
To view your application in the web browser run:
$ gcloud app browse --project=your-project
After this step, your application has been deployed in Google App Engine. You can access your application by target url printed in output or you can also run below command to access your application.
gcloud app browse --project="your-project"
Kubernetes Deployment:
Step 1: Create a Kubernetes cluster
You can skip this step if you already have one. We will use one node single zone cluster for demonstration.
gcloud beta container clusters create "kubernetes-cluster-01" \
--zone "asia-southeast1-a" --machine-type "n1-standard-1" \
--num-nodes "1" --no-enable-stackdriver-kubernetes \
--project "your-project"
Step 2: Connect to your Kubernetes Cluster and Create app.yaml
gcloud beta container clusters get-credentials "kubernetes-cluster-01"
--zone "asia-southeast1-a" --project "your-project"
Create app.yaml
apiVersion: v1
kind: Namespace
metadata:
name: example
---
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: example
name: flask-app-deployment
spec:
replicas: 1
selector:
matchLabels:
app: flask
minReadySeconds: 20
template:
metadata:
labels:
app: flask
spec:
containers:
- name: flask-app
image: sainivikas/blog-example-flask
command: ["flask", "run", "-h", "0.0.0.0", "-p", "80"]
---
apiVersion: v1
kind: Service
metadata:
namespace: example
name: flask-app-service
spec:
selector:
app: flask
ports:
- name: port-80
protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
Step 3: Create Deployment in Kubernetes Cluster
kubectl apply -f app.yaml
You will get output like below after running the above command, It will create a Namespace, Deployment and service as defined in our deployment yaml.
vikassmacbook:kubernetes vikassaini$ kubectl apply -f app.yaml
namespace/example created
deployment.apps/flask-app-deployment created
service/flask-app-service created
After this step, your application has been deployed in Kubernetes. You can check all resources running in your example namespace by running below command.
kubectl get all -n example
vikassmacbook:kubernetes vikassaini$ kubectl get all -n example
NAME READY STATUS RESTARTS AGE
pod/flask-app-deployment-746bd9fcc-js545 1/1 Running 0 21s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/flask-app-service ClusterIP 10.10.30.6 80/TCP 20s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/flask-app-deployment 1/1 1 0 21s
NAME DESIRED CURRENT READY AGE
replicaset.apps/flask-app-deployment-746bd9fcc 1 1 1 21s
Kubernetes Deployment also includes some preprocessing of Creating and uploading Docker Image which we have skipped and focused on deployment part only.
You can find used files of this demo in this repo.
TL;DR
- We containerized our workload using both Google App Engine and Kubernetes Engine.
- Google App Engine is a fully-managed service, where users don’t have to worry about underlying infrastructure, and is easy to start. While Kubernetes Engine needs special expertise to manage production workload, and takes time to fully understand the concepts, but has greater scalability.
- As a managed service, Google App engine provides monitoring, logging and security benefits. In Kubernetes Engine, we can deploy either Open Source tools for these, or can integrate Cloud or Commercial offerings.
- It’s easy to manage and differentiate both internal and external services on scale in Kubernetes.
- While providing many benefits as a managed service, Google App Engine’s cost is very high compared to Kubernetes Engine.
- Google App Engine doesn’t support stateful applications. In Kubernetes Engine, we can deploy both stateless and stateful applications.
- Migrating services from App Engine to other platforms is not straight forward. We can migrate our Kubernetes cluster without any code change.
While both Kubernetes and Google App Engine have their benefits and limitations, there’s no universal ‘correct’ answer for choosing between the two - this will completely depend on the requirement and use case of the organization.
Feel free to get in touch if you have any questions or helpful suggestions. Happy Reading :)