F5 Friday: Seconds Too Late and More Than a Few Bytes Short

Correcting some misperceptions regarding ADCs, virtualization, and the use of Cisco as the definitive yardstick for measuring the ADC market

A recent article penned by analyst Jim Metzler asks “Can application delivery controllers support virtualization?” A fair question, especially when one digs into the eventual migration and portability of virtual machines across disparate cloud computing deployments based on just such support. But the conclusion reached is misleading and does a disservice to the entire load balancing/application delivery controller industry.

Caveat: Having been under fire from vendors and readers alike in the past due to editorial discretion regarding content changes before publishing I must note that the misleading subhead “where application delivery controllers for virtualization fall short” was not Jim’s creation. I am, however, taking him to task for using Cisco as the “yardstick” for application delivery controller capabilities in part because it provided the rationale from which the misleading subhead was derived.

The overall suggestion of evaluating application delivery controller’s with an eye toward integration with an organization’s virtualized provisioning system of choice is a good one, but one section of the aforementioned article leaps out as inaccurate and misleading.

Where application delivery controllers for virtualization fall short [registration required]

Moving a VM between servers in disparate data centers is very challenging, and in some cases there is nothing that an ADC can do to respond to these challenges.

Cisco and VMware, for example, have stated that when moving VMs between servers in disparate data centers, the maximum roundtrip latency between the source and destination VMware ESX servers cannot exceed 5 milliseconds. The speed of light in a combination of copper and fiber is roughly 120,000 miles per second. In 5 ms, light can travel about 600 miles. Since the 5 ms is roundtrip delay, the data centers can be at most 300 miles apart. That 300-mile figure assumes that the WAN link is a perfectly straight line between the source and destination ESX servers and that the data that is being transmitted does not spend any time at all in a queue in a router or other device. Both of those assumptions are unlikely to be the case.

Using Cisco as your yardstick for application delivery controller capabilities leads to inaccurate analysis of the market and is patently unfair. When writing an article on the state of networking would you use Juniper or Extreme as your measuring stick for switches instead of Cisco? Unlikely. If you are evaluating routers, switches, telepresence or a variety of other network-focused solutions then you use Cisco as your yardstick. They are the leading provider in most things layer 2-3 and certainly it defines that industry and sets the bar for the state of the market and its capabilities. But when you start looking at layer 4-7 (application delivery) then it is Cisco’s yardstick and not application delivery controllers in general that falls short. Most of the industry has long since moved past the capabilities of Cisco’s application delivery solutions and it is not the leader in the market. Therefore using its technology as a yardstick for the rest of the players and then generalizing its inability to perform in this given scenario across the entire market is misleading. It results in an inaccurate depiction of what the market is capable of doing.

IT’S THE INTEGRATION – INSIDE and OUT

F5 handles this scenario just fine, thank you very much. While true that a simple Load balancer would likely find this scenario difficult to support, an advanced application delivery controller that incorporates WAN optimization integrated with the provisioning systems has no problem whatsoever.

I submit a variety of documentation and demonstration of such functionality for your perusal:

The reason an F5 BIG-IP has no problem with this scenario is its integration – both with the provisioning systems and internal to its core platform. F5 doesn’t just have a WAN optimization solution; it has a fully integrated WAN optimization feature set that is a part of a larger unified application delivery network. It is contextually aware of where data is coming from and going to and can apply a broad set of policies to accelerate and optimize data traversing disparate networks.

More important, perhaps, is the external integration of BIG-IP with orchestration/provisioning systems.

Between the two, an F5-VMware solution has no problems traversing WAN links because F5 not only manages the migration from one data center to another (be it cloud or traditional) but it simultaneously manages application connectivity and ensures continuity of use before, during, and after such a migration. This becomes important when addressing this next point from the article:

To support VMs moving between servers in disparate data centers, one can extend the VLAN between the VM and the ADC in the originating data center to the ADC in the receiving data center and then proceed as if the VM were being moved between servers in the same data centers. How this is done tends to be specific to each ADC vendor.

There is no arguing that migrating a virtual machine between two disparate locations is not complex; it is. There’s an entire industry of solutions cropping up to deal with managing the complex networking necessary to essentially bridge the local data center with remote cloud computing environments (CohesiveFT, for example, and I’m certain Cisco with its layer 2-3 expertise has this well in hand). But this statement focuses altogether too tightly on the network layer and fails to consider the application layer and complexity associated with that migratory process. Most ADCs cannot manage to simultaneously successfully move a virtual machine across a less-than-optimal WAN link and maintain application availability. Live migration. F5 can and does using global application delivery and application delivery controllers.

And if you don’t think that’s useful, then consider what it will take to implement dynamic cloud-bursting capability, i.e. on-demand, cross-cloud elastic scalability with live migration and no downtime.

Exactly.

You have to manage the WAN link and ensure the VM can move from one physical location to another successfully while maintaining application availability until it is complete and then distribute requests across the two live instances until such time as the secondary instance is no longer necessary based on real-time demand and then return to a single instance. All without disrupting service. Jim is right in that there is no solution today that can do that – but that’s today, not tomorrow or next week or next month. But if you’re watching the number two in the market, you’ll probably miss when number one announces it can.

It doesn’t make sense to watch number two in the market to see where it’s going, because it’s always going to be seconds too late and more than a few bytes short in delivering the solutions to the day’s most challenging problems. Most of the application delivery controllers on the market can’t support the scenario described in the article. True. But that’s just most, not all, and certainly not F5.

F5 isn’t leading the application delivery market without good reason. It’s exactly because we understand the complex relationship between applications and networking and the value of integration with the broader data center ecosystem that gives us the edge to develop the solutions necessary not just to traditional application availability and performance challenges, but to the challenges emerging from the rapid adoption of virtualization and cloud computing.