Ten Features that make Google Compute Engine (GCE) better than AWS
Last year when Google announced its IaaS offering in the form of GCE, I asked if Amazon should be worried. 18 months later, Google Compute Engine became generally available and it certainly looks like a credible, worthy and innovative competitor to AWS. There have been many new players entering the crowded IaaS market and some of them are well-established enterprise vendors like Microsoft, HP and IBM. But most of those offerings have limited capabilities. Forget about competing with AWS, they look like what Amazon EC2 was in 2008. But GCE is different in its approach. Instead of focusing on feature parity with Amazon EC2, Google has focused on filling the gaps that exist in Amazon EC2. Longtime AWS customers bring up these issues in various forums. GCE addresses them in a graceful way in a bid to attract existing customers of AWS.
Here are ten features of GCE that make it better than AWS.
1. Pricing & sub-hour billing – Amazon EC2 charges the usage of instances by hour. Even partial hours are rounded of to an hour. GCE machine types are charged a minimum of 10 minutes. After 10 minutes, instances are charged in 1-minute increments, rounded up to the nearest minute. Initial comparison indicates that GCE’s compute and storage costs are cheaper than Amazon EC2.
2. Load Balancer needs no pre-warming – Amazon’s Elastic Load Balancer (ELB) is not designed to handle sudden spikes. Customers need to request AWS to pre-warm the ELB to get it ready to handle the expected load. This requires a subscription to AWS support. GCE’s Load Balancer doesn’t require pre-warming. It scales instantly to support spiky traffic. Refer to Compute Engine Load Balancing hits 1 million requests per second! for more details.
3. Persistent Disks that can be connected to multiple VMs – GCE’s Persistent Disks (PD) can be mounted read-write by one VM or read-only by many VMs. Amazon EBS can be only attached to one instance at a time. This forces the customers to implement a shared storage to synchronise static content across instances. Refer to the report Five features Amazon Web Services must fix for more details of this scenario.
4. Better Block Storage- GCE’s Persistent Disks (PD) support up to 10TB which is 10 times of the supported size of Amazon EBS. Unlike Amazon EBS, GCE’s PD includes the price of I/O. It means no more guess work and more predictable pricing for the customers. This is certainly a game changer! Refer to The new Persistent Disk – faster, cheaper and more predictable for Google Compute Engine post for more details.
5. Integrated networking – Amazon Virtual Private Cloud (VPC) came two years after Amazon EC2 went live. Networking on Amazon EC2 came as an afterthought, which makes it difficult for customers with large deployments running on EC2 migrate to VPC environment. Networking is a first class citizen on GCE. Customers can create a virtual network, private, public subnets, firewalls, routes, gateways, ACLs even before launching the first VM. Unlike Amazon VPC, this is not a separate service but an integral part of GCE. Refer to the Networking and Firewalls section of GCE documentation.
6. Better network throughput – GCE Network I/O across regions is much faster than AWS. Though Google doesn’t officially acknowledge it, it is clear that they leverage their global network which is the backbone of Google’s infrastructure. In contrast, AWS uses public Internet for communicating between the regions. This capability of GCE makes it possible to setup interesting scenarios including synchronous database replication between regions.
7. Multi-Region images – Though Amazon EC2 recently added the feature of cross-region AMI copy, customers still need to explicitly initiate the copy of the AMI. In GCE, every OS image is a global resource which means that Google maintains a global repository of images including the custom images that are bundled by the customers. Refer to Resource Overview section of GCE documentation for more details.
8. Persistent IP addresses – Amazon EC2’s Elastic IP needs to be re-associated after each stop & start operation on the VMs. GCE also allows customers to promote an already assigned temporary IP (Ephemeral IP) to a Reserved IP. This helps customers in retaining the initial DNS records that were created with the temporary IP. On Amazon EC2, the EIP has to be associated with the VM at the time of booting. Refer to Instances and Networks for more details on the Reserved IP Addresses on GCE.
9. Faster boot times & auto restart of VMs – GCE’s VM boot time is at least 5X faster than Amazon EC2. According to Sebastian Stadil , “VMs are deployed and started with impressive speed (and we’ve extensively used 10 clouds). It routinely takes less than 30 seconds to login as root after making the insert call to launch a VM.” Google Compute Engine can be set to automatically restart an instance if it is taken offline by a system event, such as a hardware failure or scheduled maintenance event, using the automaticRestart setting. This will enable auto-healing of instances. Refer to Instances – Google Compute Engine – Google Developers for more details.
10. Live migration – Every cloud provider has to perform maintenance to its host servers and datacenters. This may result in scheduled downtime for the cloud provider forcing customers to reboot their VM to complete the process. Amazon EC2 Maintenance Help Page documents this process. This article, Widespread Amazon EC2 Cloud Instance Reboots Spark Questions, Concerns highlights the issue of forced EC2 instance reboots. GCE handles this through a graceful live migration of VMs from one host to another making it transparent to the customers. Refer to Regions & Zones – Google Compute Engine – Google Developers section of GCE’s documentation for more details.
So, Should Amazon be worried about GCE? Do let us know your views.
Edit: Point 8 was corrected by replacing reboot with stop and start operation.