Introduction
Google Cloud offers many possible deployment platforms, and the choice is not always immediately obvious. Let me give you a high-level overview of how you could decide on the most suitable platform for your application.
Compute Engine & Managed Instance Group
It is Google Cloud’s infrastructure as a service or IaaS offering.
Compute Engine is a great solution when you need complete control over your operating systems, or if you have an application that is not containerized – an application built on a microservice architecture or an application that is a database.
Instance groups and autoscaling, as shown on this slide, allow you to meet variations in demand on your application.
Managed instance groups create VMs based on instance templates. Instance templates are just a resource used to define VMs and manage instance groups. The templates define the boot disk image or container image to be used, the machine type, labels, and other instance properties like a startup script to install software from a Git repository.
The virtual machines in a managed instance group are created by an instance group manager. Using a managed instance group offers many advantages, such as auto healing to recreate instances that don’t respond and creating instances in multiple zones for high availability.
If you need instance groups in multiple regions, use a global load balancer and if you have static content, simply enable cloud CDN.
Google Kubernetes Engine (GKE)
Google Kubernetes Engine, or GKE, provides a managed environment for deploying, managing, and scaling containerized applications using Google infrastructure.
The GKE environment consists of multiple Compute Engine virtual machines grouped together to form a cluster. GKE clusters are powered by the Kubernetes open source cluster management system. Kubernetes provides the mechanisms with which to interact with the cluster.
Kubernetes commands and resources are used to deploy and manage applications, perform administration tasks and set policies, and monitor the health of deployed workloads.
The diagram below shows the layout of a Kubernetes cluster.
A cluster consists of at least one cluster control plane and multiple worker machines that are called nodes. These control plane and node machines run the Kubernetes cluster orchestration system.
Pods are the smallest, most basic deployable objects in Kubernetes. A pod represents a single instance of a running process in a cluster. Pods contain one or more containers, such as Docker containers, that run the services being deployed. You can optimize resource use by deploying multiple services to the same cluster.
Cloud Run
Cloud Run, allows you to deploy containers to a Google-managed Kubernetes cluster. A big advantage is that you don’t need to manage or configure the cluster.
The services that you deploy must be stateless, and the images you use must be in Container Registry. Cloud Run can be used to automate deployment to Anthos GKE clusters.
You should do this if you need more control over your services, because it will allow you to access your VPC network, tune the size of compute instances, and run your services in all GKE regions.
App Engine
App Engine is a fully managed serverless application platform supporting the building and deploying of applications. Applications can be scaled seamlessly from zero upward without having to worry about managing the underlying infrastructure.
App Engine was designed for microservices. For configuration, each Google Cloud project can contain one App Engine application, and an application has one or more services. Each service can have one or more versions, and each version has one or more instances.
App Engine supports traffic splitting, so it makes switching between versions and strategies, such as canary testing or A/B testing, simple.
The diagram below shows the high-level organization of a Google Cloud project with two services, and each service has two versions. These services are independently deployable and versioned.
Following is a typical App Engine microservice architecture. The backend of this application is a variety of Google Cloud storage solutions, with static content, such as images stored in Cloud Storage, Cloud SQL used for structured relational data, such as customer data and sales data, and Firestore used for NoSQL storage, such as product data.
Firestore has the benefit of being able to synchronize with client applications. Memcache is used to reduce the load on the data stores by caching queries, and Cloud Tasks are used to perform work asynchronously outside a user request or service to service request. There’s also a batch application that generates data reports for management.
Cloud Function
Cloud Functions are a great way to deploy loosely coupled, event-driven microservices. They have been designed for processing events that occur in Google Cloud. The functions can be triggered by changes in a Cloud Storage bucket, a Pub/Sub message, or HTTP request.
The platform is completely managed, scalable, and inexpensive. You do not pay if there are no requests, and processing is paid for by execution time in 100 millisecond increments.
This graphic illustrates an image translation service implemented with Cloud Functions.
When an image is uploaded to a Cloud Storage bucket, it triggers an OCR Cloud Function that identifies the text in the image using Google Cloud Vision API. Once the text has been identified, this service then publishes a message to a Pub/Sub topic for translation, which triggers another Cloud Function that will translate the identified text in the image using the Cloud Translation API.
After that, the Translator Cloud Function will publish a message to a file write topic in Pub/Sub, which triggers a Cloud Function that will write the translated image to a file. This sequence illustrates a typical use case of Cloud Functions for event-based processing.