At GoogleIO today, Google announced the limited launch of its Infrastructure as a Service product, Google Compute Engine. This comes as no surprise, the move has been rumored for months and Google does undeniably have some of the largest scale infrastructure on earth alongside the smarts to run it amazingly effectively – a potent combination that shoud result in them having the ability to deliver IaaS as well as anyone else. Delivering IaaS however is not just about the technology, it’s also about convincing customers as to the credibility of the service and building an ecosystem of providers around the core. Here’s an analysis of where GCE is at day one (with the caveat of course that these things change very rapidly and I’d expect Google to innovate quickly on the offering).
Ten second summary – if Google wants to really broaden where Google Compute Engine goes, and its broader success, they need to build out the product, clarify the way it’s built, increase the ecosystem and most importantly prove to the marketplace that they’re serious about this project.
Lack of detail
Google has been a bit limited on details at launch. The product is in limited trials. There is no word on what kind of VM format the product uses and beyond the message that there is a “very clean REST API” (in fairness the developer page does have a degree of information about the API), we don’t know what that looks like or how broad the API is. That said, Google does have a very extensive history of building robust and broad APIs so this should not be too much of a concern. The chart below shows the options that are available at lunch;
It will however limit short term adoption as enterprises require a little more certainty before jumping on board. Perhaps for this reason Google is pushing the launch as ideally suited for short-term compute intensive workloads where portability and long term robustness are less important than brute strength. According to Google;
The initial version of Google Compute Engine is designed to run high performance, computationally intensive virtual compute clusters in the Google Cloud. It can also be used as a generalized computing resource in combination with other Google Cloud technologies such as Google App Engine or Google Storage
In terms of the details we have the information that GCE has multiple availability zones, but none in the EU or Asia Pacific. In terms of how Google is pitching the offering, they say that GCE will offer users the ability to;
- Maintain and store data in persistent block storage
- From a VM image, mount persistent block storage (persistent disk) that maintains state beyond the life cycle of the VM instance. Data on persistent disks are retained even if your virtual machine instance suffers a failure or is taken offline. Persistent disk data is also replicated for additional redundancy.
- Manage network access to your virtual machines
- Use your virtual machines alone or connected together to form a compute cluster
- Connect your machines to the Internet with a flexible networking solution that offers static and ephemeral IPv4 addresses for your instances.
- Use an easily configurable firewall to set up network access to your instances.
- Create an internal network of virtual machines or set up access to external traffic by setting up customizable firewall rules.
- Connect your VM instances to each other and to the Internet with our fully encapsulated layer 3 network. Our network offers strong isolation to help protect your instances from undesired access.
- Locate other instances in your project using DNS lookup of VM names.
- Use a variety of tools and OAuth2.0 authentication to manage your virtual machines
- Access your virtual machine instances through the Compute Engine console, RESTful API, or through a simple command line tool.
- Take advantage of OAuth 2.0 to authenticate to the RESTful API to create and delete virtual machine instances, disks, and other resources. Also, leverage OAuth 2.0 to seamlessly integrate with other Google Cloud services such as Google Cloud Storage.
- Use service account identities to authenticate your instances to other services, and remove the need to push keys into VM instances.
Interestingly, according to RightScale, with GCE customers can encrypt data at rest both for local ephemeral drives as well as for network attached drives. In the case of the network attached disks the encryption happens on the host before it is put on the network, so it’s also encrypted in transit. This will be a boon for security conscious organization who need encryption both at rest and transfer.
Build the Ecosystem
Google has built a reasonably strong ecosystem for initial launch – from management and deployment partners (RightScale, OpsCode and Puppet Labs)
According to the RightScale post about the launch (RightScale are a launch integration partner) the offering is not API compatible with any other cloud. While many in the community are talking about the war between the API standards (with the AWS defacto standard on one side and OpenStack on the other) the existence of management providers such as RightScale sitting over infrastructure makes this something of a non-issue. Interestingly enough another management vendor, enSTratus, was not involved in this launch at all – that’s certainly interesting for those of us who hold enStratus up as an indicator. MapR is partnered with GCE to offer its Hadoop distribution for GCE users, which in itself is kind of poetic since Google themselves pioneered MapReduce for their own internal search. WIth GCE, Hadoop is coming back to Google infrastructure.
The Google situation is slightly more interesting however since Google themselves offer a number of disparate offerings that are synergistic with GCE. As Thorsten Von EIcken from RightScale said in his post;
In the big picture, the most significant and perhaps most profound reason for Google Compute Engine’s existence is the synergy with other Google cloud services. Currently Google offers Cloud Storage, Big Query, App Engine, and Cloud SQL as independent services. But if you look under the covers of App Engine there are services for message queues, push channels to browsers and mobile devices, NoSQL data stores, email, and more. All this starts to add up to as impressive a portfolio of cloud services as anyone can offer and up until today it was missing just one thing: a compute engine to tie it all together.
Price, SLA and Support
Google is promising pricing around 50% of other IaaS vendors – that’s eminently compelling, assuming the service is robust and fully featured (early days yet). However cost isn’t everything – the key thing for enterprise customers is whether or not a service has support attached and is backed by an SLA. In the case of GCE, Google asserts that GCE has an SLA behind it but in an ironic twist, the link to the SLA detail page is dead. As for support – Google is going to offer paid support for GCE customers but only via a discussion with the Google sales team – that will gives prospective customer cause for concern – Google needs to be very clear about the cost, availability and the breadth of the support offering.
Pricing of the various GCE components is detailed in the diagram below;
First a caveat – this is day one and no cloud product can be expected to be 100% sorted from day one. Google has an amazing economy of scale when it comes to infrastructure and those economies should be able to deliver IaaS on a very price competitive basis. That said, delivering enterprise grade solutions backed by clear SLAs and excellent service is probably something that Google struggles with – hence their focus on project based workloads that are all about bashing massive amounts of compute at a problem. In fact at their launch Google told of the Institute for Systems Biology who went from a 1,000-node internal cluster to a 10,000-node Compute Engine deployment, reducing the time to find associations within a genome from 10 minutes to “a few seconds.” That’s compelling for that particular use case, but if Google wants to really broaden where GCE goes, and its broader success, they need to build out the product, clarify the way it’s built, increase the ecosystem and most importantly prove to the marketplace that they’re serious about this project.
(Cross-posted @ The Diversity Blog - SaaS, Cloud & Business Strategy)