Today we'll be demoing RightScale managing a deployment on Google Compute Engine during the launch presentation at Google I/O at 1:30pm (PT). With the release of Google Compute Engine, the year 2012 is becoming a turning point in the evolution of cloud computing. There are now multiple public megaclouds on the market, and public cloud computing is set to become the dominant form of business computing (mobile arguably becoming the dominant form of consumer computing). I'll come back to why I am convinced of this at the end, but first let's focus on Google Compute Engine.
We've been working for months with the team at Google building out Google Compute Engine to ensure that everything is ready for our customers to leverage it. We realized very quickly that Google Compute Engine is an all-out effort to build a world-class cloud on one of the most awesome global computing infrastructures. It also became clear that Google Compute Engine is comparable to the most successful infrastructure clouds in the market but not a clone in any way. The team at Google has leveraged the depths of Google's engineering treasure trove to bring us their take on how a cloud platform ought to look. Yes, this means that Google Compute Engine is not API compatible with any other cloud. Yes, it also means that resources in Google Compute Engine behave slightly differently from other clouds. However, to RightScale users this will not be an obstacle as our platform takes care of the API differences and our ServerTemplates accept and even leverage the more important resource differences. We actually welcome these differences.
Each time I gave feedback to the Google Compute Engine team I had to think whether if, by asking them to make it look more like another cloud, I was asking for something better in the long term or whether I was just trying to shave off a couple of hours from our implementation task at the expense of stifling innovation. Given how nascent cloud computing still is in the big picture, the last thing we need is to cut off innovation for standardization.
How does Google Compute Engine look? Familiar yet different. You get state-of-the-art machine instances with 1, 2, 4, or 8 cores, 3.75GB of memory per core, and optionally 1-2 local "ephemeral" disks. You can create private networks for your instances, attach public IP addresses via 1-1 NAT, and define firewall rules for ingress. You can further attach persistent network disks up to 1TB in size that will have snapshot backup capability very soon. All this is presented through a very clean REST API. Machine images can be constructed from scratch to produce clean never-booted images, uploaded to Google Cloud Storage and registered with Google Compute Engine.
Overall, Google Compute Engine has been a pleasure to work with, which is perhaps best summed up by RightScale customer Joe Emison who says, "[we] have found the performance of the Google Compute Engine VMs to be the most consistent of any other virtualized architecture we’ve used." Joe is VP of Research and Development at BuildFax and a long-time RightScale customer who helped us test drive Google Compute Engine. We now look forward to onboarding many more customers, and invite you to sign up for the Google Compute Engine with RightScale private beta.
One very aggressive innovation that Google Compute Engine brings to cloud computing is encryption of 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. The encryption is on a per-project basis (Google's term for an account). This is a big deal for security conscious organizations, especially those having regulatory or other mandates to encrypt all data at rest. On other clouds one solution is to run a loop-back crypto driver, but that eats into the VM's performance. I've been benchmarking the Google Compute Engine disk performance (more on that in a future post) and the encryption doesn't seem to have a noticeable impact on performance. Pretty awesome.
Another interesting feature that highlights Google's worldwide infrastructure is the fact that the private networks to which instances attach are global. This means that as Google Compute Engine's footprint stretches around the globe, customers can create private networks that connect their instances globally. This matters when you operate sites in multiple geographies and when operating disaster recovery deployments. Specifically, it makes it easier to replicate data using the private connectivity as opposed to having to traverse the public internet. Also, it makes it easier for all servers globally to connect to central resources, such as for configuration or distribution of assets. The network traffic is not encrypted, so I would still use an SSL or SSH type of pipe, but it means that the ports used for this traffic can be kept private. And, "by the way," your traffic is carried on Google's worldwide network!
Being a brand-new offering, Google Compute Engine does have its rough edges. One of them is the fact that for the time being it is subject to maintenance windows on a well-publicized schedule, which I have observed over the last 6 months. This is not a big issue for the large-scale data processing workloads that Google is initially focusing on. In addition, for modern deployment architectures that are built with redundancy and continuous deployment in mind, this can be worked into the process. In fact, it enforces a healthy relaunch of all resources on a continuous schedule. Another rough spot is that disks cannot be mounted while an instance is running, rather only at boot time. That makes it more difficult to manage backup and restore or to have the server self-mount the appropriate snapshots. Both issues are on the "fix as soon as possible" list at Google, so we look forward to improvements.
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.
Coming back to the turning point in public cloud computing, it seems clear to me that public clouds will be front and center in the future of computing as a whole. It's not even a cost argument. It's an innovation argument. The public cloud environment is not about a virtual machine. It's about a virtually unlimited scale of machines. It's about a growing portfolio of cloud services from storage, to database, to communication, to queuing, and more. Do you really want to or need to run your own replicated, redundant, scalable SQL or NoSQL data store yourself? It's also about location and connectivity: Run anywhere and connect to everything. I'm not claiming that there is no place for private clouds, but that the innovation at almost all levels of computing will happen in public clouds first and from there may trickle down to private cloud environments. Strap in your seats, the public cloud rocket is on the launch pad!