Google Cloud Platform (GCP) offers a myriad of services, one particular set of services is its compute stack that contains, Google Compute Engine (GCE), Google Kubernetes Engine (formerly Container Engine) (GKE), Google App Engine (GAE)and Google Cloud Functions (GCF). These services all have pretty cool names, but can get somewhat confusing with regards to their function and what makes them unique from each other. This article is somewhat intended for those who are new to cloud concepts, in particular cloud services and GCP.

1. The Compute Stack

The compute stack can be viewed as a layered abstraction over what a computer system can provide. This stack moves up from “bare metal” referring to the actual hardware components of the computer all the way to functions, which represent the smallest unit of computation. What’s important to note about the stack is that services are aggregated as you move up the stack e.g the Apps section shown in Figure 1 below, must contain all the underlying components of Containers, Virtual Machines (VMs) and Bare Metal, similarly the VMs component must contain Bare Metal underneath to work.

Figure 1: The Compute Stack | Image retrieved from Google Cloud

This model as shown by Figure 1 (left), is core to describing the offerings from cloud providers. As some may only provide e.g Containers as a Service, and below, where others may provide all the ones shown in Figure 1.

[If familiar with cloud services, skip to section 3 to see the GCP equivalent]

[If wanting a summary of Cloud Services only, skip to section 2.4]

2. Cloud Services

The world of cloud computing is very diverse. Cloud providers offer several services tailored to the various requirements of customers. You may have heard of terms such as IaaS, PaaS, SaaS, FaaS, KaaS and all the letters of the alphabet followed by “aaS”. Although a weird naming convention, they form a collection of cloud provider services. I will state that there are 3 core “as a Service” offerings that cloud providers almost always provide. These are IaaS, PaaS and SaaS, which stand for Infrastructure as a Service, Platform as a Service, Software as a Service respectively. It’s important to visualize the cloud services as layers of services provided. What this means is that as you go either up/or down the layer, you as a client traverse different service options that either add to or take away from the core offering. It is best viewed as a pyramid, as shown in Figure 2.

Figure 2: The “aaS” pyramid | Image Retrieved From Ruby Garage

2.1 Infrastructure as a Service (IaaS)

This is the lowest level a cloud provider can offer and involves a cloud provider supplying the bare infrastructure these include middleware, Network Cables, CPUs, GPUs, RAM, Persistent Storage, Servers and Base Operating System Images e.g Debian Linux, CentOS, Windows etc. If you ask a cloud provider for an IaaS offering this is what you should expect to get. You as a customer are in charge of putting the pieces together to run your business. The degree of what you have to work with may vary from vendor to vendor, but typically, you are just given the hardware and OS, and the world is yours. Examples of IaaS are AWS Elastic Compute, Microsoft Azure and GCE.

Some people may not like the fact of having to install OS images, and deal with networking/load-balancing, or having to care about what kind of CPU is ideal for their workload, this is where we move up the pyramid to PaaS.

2.2 Platform as a Service (PaaS)

Platform as a Service involves a cloud supplier only offering a specific platform that users can build applications on. It is an abstraction above IaaS, meaning the cloud-vendor will handle all the details of CPU types, memory, RAM, storage, networking etc. As shown in Figure 2, you as the client have a moderate amount of control over the actual platform since the cloud-provider handles all the details of the infrastructure for you. You request the platform of choice, and build on it. Examples of PaaS are Heroku

For some, this may still be a bit too high level as the may not necessarily want to build on top of a specified platform, but rather consume a set of services directly from the cloud provider. This is where SaaS comes in.

2.3 Software as a Service (SaaS)

SaaS forms the most common services cloud providers supply. They are tailored for end users and are accessed primarily through websites e.g. Gmail, Google Docs, Dropbox etc. With regards to Google Cloud, there are several offerings outside their compute stack that are SaaS. These include Data Studio, Big Query etc.

2.4 Cloud Service Summary

Figure 3: A summary of core cloud offerings | Image courtesy of Amir at Blog Specia

Figure 3(left): Summarizes the core cloud offerings.

3. Google Cloud Platform Compute

Given our dive into typical cloud provider offerings in section 2, we can match how Google Cloud offers them.

Figure 4: Google Compute Engine (GCE) Icon

3.1 Google Compute Engine (GCE) — IaaS

GCE is Google’s IaaS offering. With GCE you have the liberty of creating Virtual Machines, allocating CPU and Memory, Kind of Storage e.g. SSD or HDD, as well as the amount of storage. It’s almost like you get to build your own computer/workstation and handle all the details of running it.

In GCE you can select micro instances that are 0.3-Cores and 1 GB of RAM, to monstrous 96-Core CPUs with over 300GB RAM. You are also at liberty to create custom size VMs for your workloads.

For those who are interested, these are the VMs you can build. Follow this link

3.2. Google Kubernetes Engine (GKE) — (Caas/Kaas)

Figure 5: Google Kubernetes Engine (GKE) Icon

GKE is a unique compute offering by GCP that is an abstraction over Compute Engine. GKE may be categorized more generally as Container as a Service (CaaS) offering, sometimes coined Kubernetes as a Service (KaaS), which allows customers to easily run their Docker containers in a fully managed Kubernetes environment. For those not familiar with containers, Containers help modularize services/applications, so different containers can hold different services e.g a container can host the front-end of your web app, and another container can host the back-end of your web-app. Kubernetes performs the automation, orchestration, management and deployment of your containers. More information here.

3. Google App Engine (GAE) — (PaaS)

Figure 6: Google App Engine (GAE) Icon

As mentioned in section 2.2, PaaS sits above IaaS, but in GCP case it can be seen as an offering above GKE too. GAE is Google’s dedicated PaaS, and as they say it best “Bring your code, we’ll handle the rest”. This ensures customers that use GAE do not have to deal with the underlying hardware/middleware but can already have a pre-configured platform ready to go; all they need to do is provide the necessary code required to run it. GAE automatically handles scaling to meet load and demand from users, meaning if your website that sells flowers suddenly hits a spike cause Valentine’s day is approaching. GAE will handle the scaling up and down of the underlying infrastructure to meet demand and ensure your website doesn’t crash because of the increased demand. This means you pay exactly for the resources what your application requires at any given point.

GAE uses Kubernetes or a version of it under the hood to handle all this so you don’t have to. GAE is best suited to companies that are not interested inthe underlying infrastructure and only care about getting their app out there in the best way that they can.

In my opinion, GAE is the best place to start if you’re a developer with a great idea, but do not want to handle the underlying toil of configuring servers, load-balancing and all other time-consuming devops/SRE work. Over time you can explore GKE and GCE, but this is just my opinion.

Disclaimer: AppEngine is used for web applications, not mobile apps.

Checkout

3.4 Google Cloud Functions — (FaaS)

Figure 7: Google Cloud Functions (GCF) Icon

After analyzing the previous offerings I hope you noticed a trend. The higher up the GCP Compute ladder you go, the less underlying tech you need to worry about. This pyramid culminates with the smallest possible unit of compute, a function as shown in section 1.

GCF is a relatively new GCP offering that is still in its beta phase (as of the time this article was written). Cloud functions allows specific functions that a developer has written to be triggered by some event. They are event-driven and are the underpinnings of the buzzword “serverless” i.e no knowledge of servers. Cloud functions are very simple and have many different uses that require an event-driven mindset. E.g. Each time a new user signs up, a cloud-function can be triggered, to alert the developers. In a factory, once a certain sensor hits a certain point, it can trigger a cloud-function that does some processing of the information, or notifies some attendant etc.

Conclusion

In this article we have spoken about different cloud offerings e.g. IaaS, PaaS etc, and how Google’s Compute stack fulfills these different tiers. We have seen that the layers of abstraction as you move from one service category to another e.g. IaaS to Paas, involves requiring less knowledge of the underlying one.

For businesses, this provides crucial flexibility that will not only meet their operational goals, but also satisfy other key areas such as security, and cost. To summarize,

Compute Engine — allows you to create your own virtual machine by allocating hardware specific resources e.g. RAM, CPU, Storage. It is also very hands on and low level.

Kubernetes Engine — Is a step up from Compute Engine, and allows you to use Kubernetes and Containers to manage your application, allowing it to scale when need be.

App Engine — Is a step up from Kubernetes Engine and allows you to focus only on your code, whilst Google handles all the underlying platform requirements.

Cloud-Functions — Is the final step in the compute pyramid, and allows one to write a simple function that when triggered, uses all the underlying infrastructure to compute and return a result.

Thanks for reading!

Twitter: @martinomburajr

If you have time, checkout the following Google Cloud Next talk that has inspired this article.