On June 20th 2017 Google finally announced the availability of its Cloud Platform in Sydney, Australia with 3 availability zones. This is huge exciting news as Australian organisations finally get to choose between the 3 leading cloud providers with local presence: AWS, Azure and Google Cloud.

Having used AWS almost exclusively since 2008 and gained my Solutions Architect certification along the way, I have been waiting for something different which would help to bridge some of the gaps faced with other cloud providers.

Google Cloud have come a long way, they were one of the first to offer a powerful app engine PaaS, however they suffered early on from a poorly designed console UI, lack of services plus limited worldwide presence. This enabled AWS to gain a huge share of the market. Fast forward to 2017, GCP has many cool services and a completely redesigned console.

This blog post is not a personal statement telling everyone to make the switch to Google Cloud, but rather a non-exhaustive list of little things I like, from a DevOps perspective.
I hope it will benefit solutions architects such as myself, to better evangelise which provider suits best. Google Cloud does not actually have all the equivalent services of AWS but it’s inevitable to compare the two.

Console

The Google Cloud console is extremely simple, fast and non cluttered like the AWS console. Perhaps the best thing I appreciate is that I do not have to select a region first in each service. I’m sure many of you have already experienced this tummy scare moment when you load the EC2 console in AWS and see no running instances until you realise you’re in the wrong region…
Not having to select a region firsthand makes it much easier to have an overall view of all your resources.

Cloud Shell

Any DevOps engineer knows that despite all the automation tools available these days, there is always occasional manual troubleshooting required. This typically involves launching a new instance, waiting till it’s up and running, then installing tools such as Docker, AWS cli etc…
Cloud Shell is an interactive terminal directly available in the Google Console (Azure has one too), it takes a couple of seconds to be ready, has 5GB of persistence storage, and more importantly all the common tools are installed: Cloud SDK, Docker (no authentication needed with the Google Container Registry), plus the usual commands ping, telnet, curl etc…
Cloud Shell saves a lot of time for quickly managing and trouble-shooting resources.

Compute Engine

The Compute Engine does not possess all the equivalent features of EC2 but it has a couple of things I really like. Apart from their blazing speed with fast launch times for machines, it has the ability to choose custom machine types which is a big plus. You can choose your own amount of CPU and RAM if none of the machine types suit your needs.

Container Engine

The main service which actually got me to try out Google Cloud, is the Container Engine (GKE). It’s a fully managed Kubernetes cluster service. It is well known that setting up a Kubernetes cluster with H.A. is fairly complex and upgrades aren’t always smooth. Even when using tools such as Kops or Kargo, in my opinion, it relies too much on code to set up and manage a cluster. I strongly believe that not everything is code and evangelise to take more advantage of platforms.
I’ve had cases when I needed a Kubernetes cluster up and running quickly so that I could test my containers. With GKE after a couple of clicks you have your cluster ready.
AWS does not even have a proper fully managed Kubernetes scheduler, in my opinion their ECS service lacks many features required for managing and orchestrating a Docker cluster.
GKE also enables you to create additional “pools” which can have different machine types for specific container resources needs.
Finally GKE is, optionally at a cost, fully integrated with StackDriver to provide monitoring and centralised logging without needing to add any extra configuration to your kubernetes manifests at all.

Many organisations are adopting Docker micro-services with Kubernetes and I see GKE becoming an integral part of Google Cloud. Using GKE also means that your Kubernetes manifests stay agnostic with no cloud vendor lock-in.

SQL

RDS is one of AWS’s best services for a fully managed database. Google Cloud’s SQL service is very limited in features compared to RDS but it has some little things which RDS console does not offer. In SQL you can directly create users and databases via the console.
The biggest handicap of SQL is that it’s a public service, it cannot be launched inside a virtual private network. Instead you’d need to setup a Cloud SQL Proxy which provides a secure tunnel between your SQL instance and GKE or Compute Engine.

Storage

We’ve seen during S3’s recent outage in the US east region that it’s critical to have multi-region replication. When you create a bucket in AWS S3 you can choose to replicate to another region.
Google’s Storage has taken a slightly different and better approach to cross-region replication. When you create a Storage bucket, you can select to replicate within a whole geographic region (multi-regional) US, Europe or Asia. This is a much simpler and attractive approach for storing mission critical data.

Pricing

Naturally Google Cloud’s pricing is aggressive and lower than the costs of running on AWS. But the best thing about their pricing model is the degressive pricing.
On AWS you will either pay on demand or you can purchase Reserved Instances (where you need to pay upfront for 1 or 3 years). Despite the small changes you can make to the Reserved Instances, it still requires a long term commitment to a vendor and instance type which isn’t always ideal.
With Google Cloud, there is no Reserved Instances approach, for example, if you leave your machine running for a full month you automatically get 30% off. This pricing model is perfectly suited to cloud resources.

Final words

I’ve compared a couple of Google Cloud’s services with AWS and listed their advantages. There is no doubt we will be seeing all cloud providers offering similar features. At the end of the day whether you use Google or AWS or Azure or X it depends on many parameters and the problems you’re trying to solve, to which there are no immediate answers.

I look forward to seeing how Google Cloud will disrupt the Australian market.

If you need any help with cloud practice, do not hesitate to contact me.