Google Preemptible VMs and SDN

Google has announced that it is offering a new service for its cloud platform: Preemptible VMs (aka Google Compute Engine Preemptible Virtual Machines). Essentially, it functions like any other cloud-compute product, but the VM may suddenly and unexpectedly shut down at any time. Like Windows ME.

It’s somewhat similar to Amazon’s EC2 spot instances, but with fixed pricing (30% of a normal VM). This makes it easier to estimate costs.

Unlike Windows ME, however, this new service actually has a productive use: fault-tolerant, distributed compute jobs. In other words, if reliability and always-on compute isn’t really necessary for your application, why pay for it? Indeed, these Preemptible VMs cost about 30% of Google’s usual cost per VM, and are already being used for such applications as processing satellite imagery, security testing, etc. These are applications that can process information, stop, and pick up right where they left off when they get re-activated.

It has been a long time since those days in the early naughts when “reliability” and “uptime” were considered the key metrics of network health. The fact that Google now offers a product that more or less has no guarantee of reliability really shows how much other metrics, such as cost-effectiveness and elasticity, have produced an expanded, more realistic way of looking at IT.

What I find interesting about this new model of cloud computing is how it mirrors some developments in SDN. Certainly, different applications have different needs: a POS system for retailers would almost certainly need constant uptime, but batch processing the receipts at the end of the night might be an interruptible task. One of the biggest advantages of moving to SDN is being able to automatically give applications exactly the resources that they need to perform effectively with a minimum of waste. Applications that require continuous availability can be given different resources from those which are interruptible, and those interruptible applications can be halted to make room for a time-sensitive but rarely run application.

Better still is the possibility that (if not now, in the near future) SDN integrates with various cloud computing services and automagically chooses not only the best route, but also the best servers for applications based upon the most cost-effective solution that meets the application’s needs, whether that’s Google’s on-demand instances, Google’s preemptible instances, Amazon’s spot instances, or running on a server in-house.