Google Compute Engine Ignores VMware, Microsoft Users
Google's new cloud infrastructure service is geared to Linux workloads running in KVM. What does that mean for VMware, Microsoft, and Citrix users?
What's harder is comparing the CPU power that comes with each instance. Google is introducing the Google Compute Engine Unit (GCEU)--a new unit of measure for virtual machine CPUs--to an already varied and confused field. The virtual CPU of Compute Engine’s base server consists of 2.75 GCEUs.
Google documentation says a GCEU has a defined physical equivalent: If a GCEU is multiplied by 2.75, it's equal to the minimum power of one Intel Sandy Bridge core thread. (Warning: Google documentation thinks the acronym GCEU should have a shorter and cooler version, GQ. It uses both. Amidst already confusing terms, we're given an acronym for an acronym.)
Craig McLuckie, lead product manager, sensing the confusion inherent in the definition, imposed his own description in an interview Thursday: The base server has the rough equivalent of half a Sandy Bridge core; it commands one of the two threads that run simultaneously on the chip, and in some cases it will be able to make use of more than half the chip's resources. As a minimum, it always has the use of one thread, he said. A GCEU is also meant to be a rough equivalent to Amazon's unit of measure of virtual server CPU. That's an EC2 Compute Unit or ECU, which is defined as a single core of a 2007 Intel Xeon running at 1 GHz. Sandy Bridge is a more powerful 2011 chip.
McLuckie said Compute Engine will be accessible to developers and customers through public APIs, the same as Google App Engine is. And he said Google will strive to deliver consistent performance from its service.
An early user, Hamza Kaya, software engineer of Invite Media, said his firm must process 400,000 ad requests a second and was doing so on a well-known IaaS provider. Tests indicated it could run its operation more efficiently on Compute Engine. In two weeks, it was able to move its operations into the Google cloud, where it found each server was processing an average of 650 ad queries per second instead of the previous 350. In each case it commissioned eight-CPU servers, but found it needed 140 in Compute Engine compared to 284 from its previous supplier.
Invite Media systems need to make calls to backend database servers. When those calls take 10 seconds or more, they are interrupted and repeated as a connection error. Its connection error rate dropped from 5% of queries down to 0.5%, said Kaya.
It's too early to say whether the Compute Engine's approach to networking, pricing, and server resource assignment will prove a winning combination in the marketplace. Google has lagged the market in putting together an infrastructure offering and now must find a way to get back in the race. It was only last November that it took its predecessor platform-as-a-service, Google App Engine, out of the experimental preview phase after three years of operation.
But few dispute that Google can bring a decade of experience in search engine operations to the endeavor. It will need to simplify some of the complex messages it appears wedded to in explaining the service. And it will need to find more compelling ways to describe what its infrastructure can do on behalf of an established business. But the growing appetite for plain infrastructure-as-a-service still gives it a chance to do exactly that.
Expertise, automation, and silo busting are all required, say early adopters of private clouds. Also in the new, all-digital Private Clouds: Vision Vs. Reality issue of InformationWeek: How to choose between OpenStack and CloudStack for your private cloud. (Free with registration.)
InformationWeek Elite 100Our data shows these innovators using digital technology in two key areas: providing better products and cutting costs. Almost half of them expect to introduce a new IT-led product this year, and 46% are using technology to make business processes more efficient.
The UC Infrastructure TrapWorries about subpar networks tanking unified communications programs could be valid: Thirty-one percent of respondents have rolled capabilities out to less than 10% of users vs. 21% delivering UC to 76% or more. Is low uptake a result of strained infrastructures delivering poor performance?