This is the second in a series of high level posts giving some examples of why you might choose Google Cloud Platform for your infrastructure workloads.
Infrastructure as a Service (IaaS) is still the biggest reason for any organisation to evaluate and move to public cloud. While ‘serverless’, containers and NoOps services are popular online, the reality is that most organisations are not in a position (yet) to utilise these services without large platform overhauls.
There is a lot to set Google Compute Engine (GCE) apart from other public cloud provider compute services. Not only does it make use of the Google network (see my previous post here) but it has other big differentiators too.
The minimum network throughput for any GCE instance is 1 Gbit/s. Yes, you read that right. This is only for shared CPU instances which currently includes the
g1-small instances. From there, all instance classes scale at 2 Gbit/s per core meaning any non shared instance will have a minimum of 2 Gbit/s network throughput up to around 16 Gbit/s. Compare this to instances on AWS, a
t2.micro instance will start dropping network connections at around 12 Mbit/s. Network doesn’t scale in a linear fashion either. Some instance classes get more network than others. This can add complexity to network sensitive application deployments and the infrastructure supporting them.
This additional throughput allows GCE to read instance images quicker which in turn leads to faster instance start up times and improved disk throughput. Boot times are up to 80% faster than AWS or Azure. When it comes to reactive scaling this makes a difference to your web applications and availability ensuring the fastest reaction to auto scaling events.
Due to the way GCE instances are deployed (in containers) they do not suffer from noisy neighbour syndrome. An example of noisy neighbours can be found when a large customer releases the latest season of a popular TV show. Your latency sensitive application suddenly starts seeing latency spikes across the board. You don’t see any real reason for this until you start to notice the pattern of season release vs. degraded service. This is down to the larger customer consuming the majority of resources on the underlying hardware and having a knock on effect against your resources.
GCE resources are completely segregated so never have a knock on effect the other instances running within the same proximity.
There is not much to talk about here, if you need disk performance then you will find it on GCE. While persistent SSD storage is slightly more expensive than GP2 (AWS general purpose SSD) you don’t need to worry about credit balances and get far superior performance. A GP2 volume gets three IOPS per provisioned GB. A GCE persistent SSD disk gets thirty IOPS per GB provisioned. If you have a 100 GB disk on GCE then you will get a consistent 3000 IOPS. A 100 GB GP2 volume will give you 300 IOPS and a credit balance that once consumed sees disk performance fall through the floor. If you want consistent performance in AWS, you will need to pay for Provisioned IOPS which come with a hefty price tag.
Cloud computing ideally follows a utility model where you are billed for what you use. GCE
is the only leading public cloud platform that bills per minute for compute usage. When you create an instance, you are billed for the first ten minutes and then per minute after that. This becomes quite a cost saving in large environments that are scaling up and down suddenly and for short periods of time. Both AWS and Azure bill customers for sixty minutes as soon as the instance is started. This continues when the instance ticks over to the next hour so you pay for two hours if the instance is up for 61 minutes. With GCE, you pay for 61 minutes.
Edit: Thanks to Robert Jordan who pointed out that Azure offer per minute billing with no ten minute minimum.
Edit: AWS have announced per second billing for EC2 instances (free Linux distros only) - details can be found here.
Edit: I’ve been meaning to post this for a while; GCE now bills per second with a minimum charge of one minute. You can see the announcement here.
Google have a concept called sustained usage discounts. Simply put, this means that the more you use an instance, the cheaper it becomes. When run for a full month Google apply a 30% discount to the instance bill. Customers don’t need to apply for the discount, it is automatic and applies to all instances with no limit in the number of instances the discount is applied to.
Customers can receive a further cost saving by committing to use a specific amount of resource. The resource is allocated based on CPU core count and memory and can be allocated across machines however the customer sees fit. These discounts are not tied to an instance type so if you reserve ten cores they can be distributed across ten single core machines or one ten core machine. Discounts gained are up to 57% off list price when committed over three years. However, the cost is till billed monthly which means customers don’t have a large upfront cost and benefit from future list price reductions.
This is incredibly flexible when compared to reserved instances within AWS. A reserved instance is reserved based on instance type. While the instance can now be transferred, it still requires input from somebody within the customer organisation to ensure they are making best use of the reserved instances. Reserved instances are also billed upfront meaning customers have a large outlay and will not benefit from future list price reductions.
If you want compute resources that perform to the standard detailed in the documentation then Google Compute Engine is the place to be. It is often claimed that compute is compute but that is not the case here.