Introducing HTTP Load Balancing and SSD Persistent Disk

This is Google using the power of their private network. A single IP routed to your closest data center which can be done because your traffic enters their network at the closest POP and they can then route internally. Currently, you have to do this using anycast DNS – Google is making this a really simple product to get completely automated geographic redundancy/local serving of content. Dyn charge a lot for this product.

Softlayer has a similar product called Global IP where traffic enters their extensive network at the local POP. You can then reroute the IP to any of your servers but it’s not load balanced and is really just another IP. Still a good product which we use to power all our services for automated failover. But Google just one-upped them.

Think AWS elastic IP, but Softlayer allow you to route to any server in any DC. And Google allow you to automatically route to a pool of servers in a location closest to the user.

Google, Amazon, and Azure appear to have shaped their clouds after their internal needs first. This has lead to peculiarities in their pricing and feature sets. Amazon, for example, is fine with scaling out to an extreme degree, and so their storage options, particularly their provisioned IOPS options, are rather expensive. Their network and storage infrastructure is likely the oldest and with the lowest turnover rate, so they're the most expensive to get performant storage on.

Google probably has the highest server turnover rate, and my wager is that they recently switched to new SSDs to reduce failure rates in their datacenters. My guess is that their compute servers are now swimming in excess IOPS, and so they are clearly the cheapest if you want very fast storage. This reminds me of Facebook purchasing massive quantities of SSDs for their own datacenters.

Microsoft has very peculiar needs. Azure grew out of servicing internal Microsoft IT needs first, so it is stuck with some quirks. You don't provision IOPS, you create disks, which you attach to VMs. There are no IOPS tunable options for their PaaS, only IaaS VMs. They use software RAID (Linux or Windows) to turn multiple disks into higher speed storage. Their storage backend can only be described as weird[1], because whatever you think the actual disk layout looks like from your VM's perspective, it doesn't look anything like that on the storage layer. They partition data into chunks (disks) which get written to a distributed, log-structured file system on JBODs. Every 1GB extant is made immutable once full, and they use erasure encoding to distribute the data such that they can sustain 2 failures with only 33% disk overhead. The result is that writes are cheap (almost all writes are sequential) and the backend does a bunch of compute work to make reads fast (with caching of metadata and the erasure encoding, I'm guessing).

[1] - http://snia.org/sites/default/files2/SDC2013/presentations/G...

[2] - http://research.microsoft.com/pubs/179583/LRC12-cheng%20webp...

Google's SSD price is $0.325/GB/mo with 30 IOPS (flat rate). AWS's EBS with provisioned IOPS are SSD backed, and cost $0.125/GB/mo, with $0.10 per IOPS.

To get 30 IOPS on AWS would cost $3.125 - almost 10 times as much as at Google. If you're doing more than 2 IOPS, you're better off with GCP.

> HTTP Load Balancing changes the game for how developers interact with network resources. HTTP load balancing can easily scale to support more than 1 million requests per second with no “warm up.”

> And while other providers count each and every IOPS and charge extra for them, SSD persistent disk includes IOPS in the base price with no extra charges or fees, making cost completely predictable and easy to model.

Between Google's price cuts, and releasing features directly addressed at Amazon AWS feature/pricing deficiencies, Google is coming out swinging.

Google vs Amazon's ELBs:

https://aws.amazon.com/articles/1636185810492479#pre-warming

"Amazon ELB is able to handle the vast majority of use cases for our customers without requiring "pre-warming" (configuring the load balancer to have the appropriate level of capacity based on expected traffic). In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing."

Google vs Amazon charging for IOPS:

"And while other providers count each and every IOPS and charge extra for them, SSD persistent disk includes IOPS in the base price with no extra charges or fees, making cost completely predictable and easy to model."

Cloud platforms are exciting to me because it seems every new feature presents an opportunity to break out a spreadsheet to figure out performance/$.

I'm going to consider 3 cases:

CDN: 1TB of storage, 1000 IOPS required. (a cache or "smart"/ACLed CDN)

DB: 20GB of storage, 5000 IOPS required. (a moderately sized database)

Hybrid: 500GB of storage, 2500 IOPS required. (some composite of the two)

A summary of pricing right now for storage IOPS:

  (US East)
                            $/GB  $/IOPS    CDN      DB    Hybrid
  Google Cloud Platform    0.325  $0.011   $ 325   $  54   $ 163
  Amazon EC2/EBS           0.125  $0.100   $ 225   $ 502   $ 313
  Microsoft Azure          0.050   n/a     $  50   $   1   $  25
  Microsoft Azure (w/vm)   0.050   n/a     $  85   $ 278   $ 164

Here's how they are currently priced:

Google: pay for the GB, get a fixed IOPS/GB.

Amazon: pay for the GB, pay for the IOPS.

Microsoft: pay for the GB, get 500 IOPS/disk, with a maximum of 16 disks. (but you can't attach that many disks unless you pay for a larger instance size, too)

Microsoft (w/VM): I've included the cost of the compute instance in this summary. I used an A1 VM for CDN, A4 for DB, and A3 for Hybrid, at $35, $277, and $139 monthly, respectively.

CDN

Google: $325 for 1TB/30,000 IOPS.

Amazon: $225 for precisely 1TB/1,000 IOPS.

Microsoft: $50 (using 2 500GB disks)

Microsoft (w/vm): $85 (an A1 VM is required to use two disks)

DB

Google: $54 for 167GB/5,000 IOPS.

Amazon: $502 for 20GB/5,000 IOPS.

Microsoft: $1 for 20GB/5,000 IOPS (using 10 2GB disks)

Microsoft (w/vm): $278 (an A4 VM is required to use 9-16 disks)

Hybrid

Google: $162.50 for 500GB/15,000 IOPS.

Amazon: $312.50 for 500GB/2,500 IOPS.

Microsoft: $25 for 500GB/2500 IOPS (using 5 100 GB disks).

Microsoft (w/vm): $164 (an A3 VM is required to use 5-8 disks)

EDIT: I forgot to add a disclaimer. I am a student at the University of Northern Iowa. I am not affiliated with Amazon or Google. I am a Microsoft Partner, however. I was not paid or asked to write this post, and have never been directly paid by Microsoft to produce any writing, benchmark, or whatever, etc, etc. IANAL, etc. I have received standard gifts from them from attending conferences.

The combination of this HTTP Load Balancing announcement, and May 23rd's announcement of CoreOS support are super exciting. I've been working on setting up a similar docker-based multi-AZ autoscaling setup on EC2, but getting it up and running has required integrating a lot of separately moving parts. If Google can simplify this process via a few simple gcutil commands and a cloud-config YAML file, it would be a hugely compelling offering.

Exciting developments on the load balancing front. Is anyone able to decipher whether this can be used to load balance external (non-google) services? It looks like the input parameter is simply an external IP, but I haven't looked that closely yet.