I’ve been a big fan of Google Cloud Platform from the beginning, and they aren’t even paying me to say that. A lot of critics place GCP far enough behind AWS and Azure that most people haven’t bothered to consider the “third option,” but this leaves much of the story untold.
We engineers love to compare hard numbers, and the number we compare the most in the cloud space tends to be the number of services. AWS has 10 million services to date, and will always win in this category. AWS also considers SNS, SQS, and Kineses to be three separate services, as opposed to, I don’t know, designing a single service that can handle those needs? Picking quality over quantity, in my personal opinion, is Google Cloud’s differentiator. Google Cloud will never offer hundreds of services because it focuses on doing the things it does well, whether that be in terms of performance, ease of use, or flexibility. It’s clear Google hired quality Product people where other cloud providers did not.
Spinning up a VPS is kind of like a “hello world” for gauging cloud providers. We can learn a lot about the dumb decisions (or lack thereof) embedded in a vendor’s philosophy by how they chose to design the most simple task imaginable. Let’s see what we’ve got here.
In the blue corner, weighing in at 1 CPU and 3.75 RAM, we have our challenger: Google Compute Engine. In the opposing corner, weighing in at 4gb RAM and 2 CPUs we have the defending champion: Digital Ocean. If we were going by numbers alone, it would seem like Digital Ocean has a clear advantage of winning this matchup.
We’re going to deploy the same site on both machines and compare their performance rankings. How will we do this? With Google’s Lighthouse, of course! Now, using a Google tool to benchmark a Google product is hardly fair, but let’s be honest: the load time of a site shouldn’t theoretically change to any degree noticeable by humans just by changing clouds, right? Website load times are far more dependent on execution than VPS host…
Let’s start with Digital Ocean, where we’re hosting hackersandslackers.com. Not great, but not terrible:
Here’s the same site being hosted on Google Cloud, on a machine with theoretically lower specs:
Jesus! 10 points is a lot for no changes whatsoever. All other metrics stayed the same across the board, which reinforces the fact that no other aspects are at play. Ten points also seems like a suspiciously clean bump. I’m not saying the results are rigged, but it’s worth asking whether or not Google silently favors their own customers. If Google does in fact favor sites running on their infrastructure, what are the SEO implications of boosted ratings? Most people would pay a premium to be 10% better in the eyes of Google’s algorithm, so these results are significant regardless.
Let’s do our best to see how Compute Engine pricing stacks up:
|PROVIDER||NAME||# OF CPUS||RAM||HD||PRICE / MONTH|
|Azure||DS1 v2||1||3.75||32GB SSD||$51.10|
Making these comparisons is difficult to do accurately. We’ve already seen how the quality of RAM or CPU can vary between cloud providers, so these numbers are not 1-to-1. To make matters worse, AWS considers VPS storage to be a completely separate product (wow).
From what we know, this price chart actually looks pretty strong for Compute Engine. GCP machines are substantially cheaper than their equivalent Azure machines. The EC2 instances would actually cost more than what we see listed after adding disk space, which means we’re essentially paying for an extra CPU.
Does in Fact Compute
Google Cloud gives us a lot of options for customizing our Compute Engine. There are two ways of selecting a machine size: by selecting from the list of preconfigured VMs, or by tweaking the specs of our machine by using the custom option.
Here are the preconfigured choices we have:
Picking from a cookie-cutter machine has a notable advantage: when we do so, we’re able to select which CPU we want. This allows us to explicitly specify that we’d like a Skylake processor:
When customizing a machine we have the very cool ability to select precisely the number of cores and RAM we want via some nifty sliders. The disadvantage to doing this is we lose the ability to reserve a CPU type. Thus, we almost certainly get a lower quality CPU than we would otherwise:
OS and Boot Disk
There are no shortage of Linux distros to pick from on GCP (and Windows, if you’re into that):
The size and type of our instance’s boot disk are always up to you, which is a great feature. I highly suggest taking this chance to create an instance with more than 10GB… I learned the hard way that maxing out a server’s boot disk bricks your machine.
In case you’re following along, make sure you check Allow HTTP traffic and Allow HTTPS traffic before continuing (assuming you want public traffic). You could change this later, but save yourself the headache of troubleshooting this later.
Once your instance is created, you should immediately be able to SSH into your server via GCP’s browser client.
Point DNS to Your Instance
Let’s see what’s involved in pointing a domain to Compute Engine. Edit the server you just created and go to the network interface section to add a static IP:
A massive advantage that GCP has over AWS is the ease with which we can configure important network stuff. We’re able to do things like assigning IP addresses without jumping between multiple screens, configuring security groups, navigating subnets, creating CIDR blocks, or whatever. Even though all of that is possible, Google surfaces the things we want in the places we might expect them to be, like directly on our VPS edit screen.
Google handles DNS via its “product” Cloud DNS, which handles all the things you’d expect to do with domain name records. To set up a domain we need to create a DNS zone for the domain we’ll be pointing to Google Cloud’s nameservers:
With a DNS zone created, you’ll be able to see Google’s nameservers to point your domain to (look for the Registrar setup link up in the upper right-hand corner). The nameservers should look like this:
Adding DNS Records
Now we can add some DNS records! Create an A record and point it to the static external IP of your Compute Engine:
VPC & Firewall Settings
The last thing worth highlighting is the way Google handles VPC settings. Find the Firewall Rules page to get a taste of how easy it is to manage incoming & outgoing traffic rules:
Selected Create a Firewall Rule and check out the process for setting this up:
- Targets – This will be where our traffic routes. We want to route to our instance, which is a specified service account.
- Target service account – Referring to the above, this is where we select the computer instance we want to hit.
- Target service account scope – Select “in this project”.
- Source Filter – Once again, select the specified service account.
- Source service account scope – Select “in this project”
- Source service account – This is where we say where the traffic is coming from. It’s coming from the App engine, as this is where we specified our DNS.
- For IPs and ports, well, do what you want. It’s your server.
The process of setting up a firewall rule is so straightforward that you probably missed an important fact: we did all of this painlessly on a single screen. Streamlining this process can be considered an achievement when we look at the horrendously low bar set by other cloud providers when it comes to networking configuration. As much as I’d love to rip into AWS on this, insulting Amazon’s horrendous UX almost seems distasteful at this point.