In recent years the possibility of supporting complex network functionality in the form of a “virtual appliance” has become reality.  The idea is to create software versions of traditionally “hardware-based” platforms, such as firewalls and load balancers (and their offspring Application Delivery Controllers), running as a VM atop whatever hypervisor.  I can see the appeal.  However, I’m convinced that the virtual appliance approach doesn’t work in the long-run.

For many of these appliances the conversion from hardware to virtual appliance isn’t hard; it’s not uncommon for network appliances to be based on off-the-shelf hardware with customized faceplates, so converting the software to a VM is straight-forward enough.  But therein is exposed a fundamental problem: in large part these off-the-shelf platforms don’t scale well.  Vendors have been able to take advantage of the latest off-the-shelf hardware for their appliances, which can perform at multi-gigabit speeds, because many enterprise applications don’t require anything near that capacity.  But any application that requires scale beyond the IO capacity a single server will be disappointed by a virtual appliance.

To illustrate the point, imagine a virtual appliance running as a VM capable of forwarding 1G of traffic but attempting to support a dozen VM servers each capable of generating the same 1G of traffic.  A dedicated, and possibly hardware-based, approach is obviously a better performing alternative.  Now imagine a Cloud service provider’s environment, where the datacenter traffic is the sum of all these applications densely packed into compute clusters.  Clearly a multi-tenant network appliance must be hardware-based to meet the aggregated demand.

Even if that demand is to be divided amongst many virtual appliances (i.e. a multi-instance approach rather than multi-tenant) we have a problem: topology.  Most often the network service needs to be in-line with traffic flows to work effectively.  For instance a firewall needs to see and control traffic flows, which is traditionally accomplished by being embedded within a network gateway.  For the most part, network topology is defined by the Cloud service provider and the customer has no control of it.  And even if the customer could control or manipulate topology, it is horribly inefficient to bounce traffic around inside the cloud on its way in or out, hurting performance.  This “amplification” of traffic is often inevitable inside a datacenter, but can be optimized by placing network services closer to the core switches and/or backbone routers.

In other words, network services are best provided by the provider of the underlying infrastructure.  Networks built to support these features will work better than trying to hack-together a service layer on top of an unintelligent Cloud network.

At least, this is true for now.  Look for my next post, which will discuss the future of network services around hypervisor- and network-embedded capabilities.

Yesterday I read an interesting blog post about a new product from EMC. The benefit of the product is that it enables very fast long-distance VM (virtual machine) mobility. But at the core, it’s a storage replication engine that focuses on “Distributed Cache Coherency”.

The VM mobility is impressive. To quote the blog post:

At EMC World today we vMotioned 100 VMs between clusters in 4 minutes and 500 in 20 minutes. That’s 2.4 seconds per VM. Across the equivalent of 100KM.

Clearly this wouldn’t be possible if the VM had to go through a typical “VMotion”, which involves (in simplified terms) pausing the VM, writing active memory to a file, moving the disk image and memory file to a remote server, and resuming the VM. The pausing and resuming aren’t time consuming but the movement of data across a network can be the source of significant delay. That’s where EMC does a little “cheating”. (or magic, depending on your point of view)

I don’t have first-hand knowledge of the platform. But I would guess that they’re keeping data mostly in-sync all the time, using background replication, so that the VM doesn’t need as much copied over the network at the point of migration. Even more importantly, they don’t even have to copy all of the data across the network before starting to use it. The platform copies a much smaller directory structure that points to the local drives for local data or the remote drives for data that hasn’t been copied yet. Upon accessing remote data it gets copied into local storage, which has a negative impact on performance. But the performance hit only affects that block at that moment; accessing any already-replicated blocks will run at native speeds.

Here is a diagram borrowed from the EMC posting to illustrate the idea:

As I said above, this is just my guess. The article goes into enough detail to get a rough picture of what happens. But I’m looking forward to hearing more details about this platform. I’m especially interested in hearing about conflict resolution. The article touches on this by saying:

The key is that VPLEX doesn’t solve the “what if two updates to the same block occur at the same moment?” problem (this is the core of the “did you solve the speed of light problem” question). The key is that MANY use cases ensure a single “writer” (single host writing to block at any given time), we don’t have to solve the “speed of light” problem (working on it In the VMware use case, for example a single ESX host is the “writer” for a VM at any given moment, and a vMotion is an atomic operation – at one moment, one host is writing to a set of blocks, and then at next moment, another host is writing.

But the devil’s advocate in me still has to ask: but, what if?!? I’m sure I’ll have the chance to ask EMC someday soon. But regardless of their answer, I’m happy to see a platform like this one. EMC is uniquely positioned (given their relationship with / ownership of VMware etc) to make the assumptions and develop the tools that we’re going to need for any reasonable future in the cloud.