News this morning from Google, which is announcing some price changes for some of its cloud computing products.
For a little background here, Google is widely regarded as being in third place in the public cloud infrastructure wars, trailing a long way back from Amazon Web Services (AWS), the front-runner, and Microsoft Azure in second place. Indeed, the most recent Gartner analysis about the public cloud space had a few surprises (in particular the absolutely abysmal scores for both IBM and Oracle) -- one of the surprises was that Google has lost a little ground to both Microsoft and AWS, with the former seemingly moving closer to AWS over the past year.
(The Gartner Magic Quadrant, pictured above, is fascinating for anyone who covers the space. There is plenty of scuttlebutt suggesting that the MQ, delayed by months, was the subject of intense threats, cajoling and requests from poorly performing vendors, but those are, as yet, unproven allegations.)
Anyway, back to the topic at hand: Google and its cloud ambitions. Google has always seen its technical excellence, and its ability to commoditize formerly expensive services, as part of its core DNA. Today's news strongly speaks to the second one of those two skills.
To this end, the company is dropping its prices on its so-called Preemptible VMs by up to 33%. Google ascribes its ability to reduce these prices to a tuning of its algorithms and an improvement in its efficiency and analysis of usage patterns. That experience, alongside the growing scale of the Google Cloud Platform, is allowing Google to make this change.
Of course, there is also the unsaid piece, and that is that being able to stand ahead of its competitors in the ranking of the most economical vendor is also of benefit, and these particular cloud components lend themselves to price-cutting. Preemptible VMs are just like any other Google Compute Engine VM, with the caveat that they cannot run for more than 24 hours and that Google can preempt (shut down) the VM earlier if it needs the capacity for other purposes. This obviously allows the company to use its data center capacity more efficiently and share the savings with customers. The expectation being, of course, that some of those customers will be new ones, attracted to the price savings.
The whole notion of these transient VMs makes sense -- for workloads that don't require guaranteed persistence, it's a great way to leverage compute at the lowest possible price. Google explains that it has seen Preemptible VMs being used in use cases as varied as analytics, rendering, image processing, genomic analysis and financial analysis. And they're pretty easy to use -- simply adding a single flag (funnily enough, "--preemptible") in the Google cloud compute instance creates the command. The resource for the VMs themselves come out of Google's "excess" capacity and, as such, varies by location, time and day. Generally, availability is highest on nights and on weekends.
In terms of how Google decides on which preemptible VMs to can, it states that it avoids preempting too many VMs from a single customer and, given the choice, preempts VMs that were launched most recently. While this might be a bit frustrating at first, in the long run, Google suggests that this strategy helps minimize lost work across customers' clusters. And because Google doesn't bill for VMs preempted in the first 10 minutes, it saves on costs, too.
Preemptible VMs are a good idea, but that isn't really what this story is about -- rather, it is a look at whether cost savings are a primary driver for public cloud adoption and consumption. Or is added value, near-infinite scalability and an ability to abstract non-core business the primary driver?
The fact is, for all the pundits talk about added value, IT departments still generally run as a cost center, and as such, a cost saving is a powerful selling point. Whether this will make an appreciable difference to Google's standing in the Gartner Magic Quadrant remains to be seen, but as part of a broader maturing of the platform, it is a good move.
This article is published as part of the IDG Contributor Network. Want to Join?