Infrastructure performance

There's a lot of FUD surrounding private cloud. Without getting in to definitions, I figured I would add a bit of noise and have some fun with infrastructure performance in the process.

Cloud vs Claude

I'm a virtualization guy -- I know that cloud can be interpreted a lot of ways, but for now I'm using it to describe Infrastructure-as-a-Service (IaaS). Public cloud means public infrastructure providers such as Amazon's EC2 or Rackspace's cloud.

From my perspective, public IaaS offerings fundamentally provide two forms of value:

1. Outsourcing of infrastructure costs (hardware, management, etc.)
2. Cloud technology as a platform (APIs, billing, image libraries, etc.)

It's clear that the value of the first item is fully realized by traditional (non-cloud) hosting and co-location services. Yet, based on how these companies are scrambling to release cloud offerings, the cloud providers must be killing these shops in the market. It follows that there must be something more than just vapor to that second point. Hourly billing alone is not driving people to choose cloud providers over traditional hosts.

Private Claude

That brings us to the definition of private cloud. It's what you get when you have cloud technology running on your own infrastructure -- no outsourcing of hardware. But WTF is cloud technology? While virtualizing your infrastructure buys you a lot of agility, there's definitely more to it than just virtualization. Here's my take.

The key difference between vanilla virtualization and cloud is automation.

Automation isn't just one thing -- there are lots of ways to automate. Automated provisioning means that you can deploy virtual machines based on standard templates with the click of a button (an or API call). Automated billing means that resources are accounted for and reports are automatically generated or fed-back into a billing system. Automated scaling means that services are architected to automatically grow and shrink their footprints over time, using infrastructure APIs.

To me, automation is a fundamental tenet of cloud technology.

So where does private cloud make sense? In environments where automation makes sense.

Automation sees return on investment when things change often: workloads, requirements, environments, usage. These environments are very common, but not in every business. Technical computing, content creation, service providers and hosting all may have demanding and unpredictable workloads but may also have strict data requirements (legal or bandwidth) that prevent them from using public infrastructure. Private cloud makes immediate sense here.

If you're not using hosted infrastructure today but are faced with dynamic workload and automation needs, then it's likely that cloud is a revolution that will change how you compute in your own datacenter.

Where do we come in?

Our technology transforms how applications interact with infrastructure, simplifying automated provisioning and scaling.

Instead of requiring virtual machine templates to be stored and maintained as complete disk images, Copper enables on-demand cloning of live, running virtual machines in real-time via a powerful API. One second you have a single server, the next you have dozens -- and each server is aware of its unique ID allowing complex, distributed services to be created easily.

You provision virtual machines in seconds. So what? I can deploy a new server on <favorite platform> in just a few minutes. That's good enough, I've never needed anything better.

The above remark is a classic (and ludicrous) response I occasionally get when I explain what our technology does. It's a total straw man. That's good enough for what you do today because you've never been able to do anything more. It's like saying that you'll never need a hover car, or that "640Kb [of RAM] ought to be enough for anybody".

Taking minutes to provision an additional virtual machine means that you need to be able to predict fluctuations in demand and provision in anticipation of load. It also means that if you want to run a large-scale parallel computation that can take as little as a few minutes given a few hundred machines then you'll probably wait many, many times the required time or most of the time and cost in your analysis will consist of deploying virtual machines instead of actually running code.

Being able to scale in seconds changes the name of the game. Software can predict and react in response to demand, in real-time. That's the basis for our upcoming hosted cloud offering, RiotCloud, and our powerful grid queueing solution GCQ.

Taking it on the road

If automation is a fundamental tenet of cloud technology, then measuring the speed at which infrastructure software reacts to programmatic automation is a logical next step. I'm a massive fan of Top Gear, despite having a complete lack of interest in cars. After realizing that this was quite normal, I thought it would be fun to do a Top Gear tribute by boasting about our raw infrastructure performance.

The below tests were performed on our test track cluster by our tame race driver infrastructure programmer, the Stig Steve, seen here. Some say that Steve's brain, if hooked up to an IPv6 backbone, is capable of routing over 50GiB per second.

Acceleration

A fun test for infrastructure software is how quickly it allows an application to scale, which is tantamount to how fast new machines can be provisioned and booted. A faster time-to-scale means smoother upgrades, fewer resources wasted transferring state and an overall more dynamic infrastructure. For example, consider scaling an analysis application (like Hadoop) to perform a time-critical computation. Our software requires zero time to create and bundle virtual machine templates (it's not necessary), so for us this is simply a matter of how quickly we can scale a running virtual machine. In fact, everything here is done within the virtual machine being scaled, showing the power of our API.

Before Steve did his thing, we were lucky enough to have Jeremy Clarkson of Top Gear take our software for a spin and give his first impressions.

Don't worry: he's fine now, just a little shaken up.
Also, that's obviously not really Jeremy Clarkson.

In the tests performed by the our tame infrastructure programmer, we found a blazing average time of just a little over 9 seconds to scale from a single virtual machine to sixty-one, making repurposing infrastructure a staggeringly fast operation. Remember, that when Copper clones virtual machines, they are already running with all the necessary application state -- 9 seconds is everything, there is no boot time.

Cornering

Although acceleration is important, a huge factor in how fast you can make it around the track is how your machine can handle corners. Application cornering is a lot like cornering in a race car: you need to slow down in one direction, then speed up in another.

The below video shows Steve apexing a nearly 180 degree corner. Our infrastructure starts off running one application with over one hundred virtual machines, destroys them all, then scales a second application out to over one hundred virtual machines. This process takes less than 20 seconds.

The fine print

These demos show the power and speed of dynamic infrastructure, but I'm glossing over a few details. When you're scaling applications (in or out), they'd better be ready for it. Although a lot of applications can be adapted, there are plenty of frameworks that fit the bill already, especially in spaces accustomed to dynamic workloads.

To give some concrete examples of what they might be, suppose that application one is for distributed data crunching (like SETI@Home or a batch processing system) and application two does distributed web load testing (like Selenium Grid). In that case, cornering might consist of putting aside the opportunistic analysis that we have our infrastructure doing in order to load test the latest website release.

When provisioning is so simple and takes seconds, we can easily imagine building new infrastructures that react and scale like never before. Applications can scale in response to load or needs in real-time. The example above, where infrastructure is taken over at the flick of a switch, could easily happen every night, every day, every hour or even every time some stupid developer (or umm... CTO) pushes code and breaks the build.

That's it folks!

In other news, we've recently released Copper 1.4.2 and updated all the guest images available include Debian 6.0, Fedora 12, Fedora 13, and CentOS 5.5. Happy updating.

I also want to add that although we're excited to work every day at changing the world with innovative virtualization software, our team's thoughts and hopes are with those affected by the tragedy in Japan.