Ultimately a highly-scalable, high-performance architecture will rely on choosing the right form factor in the right places at the right time.

Scale is not just about servers, and for corporate data centers and cloud computing providers looking to realize the benefits of rapid elasticity and on-demand provisioning scale simply must be one of the foundational premises upon which a dynamic data center is built. And that includes the infrastructure.

This isn’t the first time I’ve touched upon this subject, but it’s a concept that needs to be reiterated – especially with so many pundits and analysts looking for the next big virtualization wave to crash onto the infrastructure beachhead. I’m here to tell you, though, that the devil is in the details. Virtual network appliances (VNAs) are certainly one means to achieving elastic scalability of infrastructure services but just as scale is not just about servers it’s also not just about form factor. It’s about the right form factor in the right place and, ultimately, at the right time.

First consider the scalability needs of aggregation points within an architecture. These are points at which high volumes of requests/traffic are essentially directed at one infrastructure solution, i.e. a Load balancer for application traffic, a router for network traffic. At these points in your architecture it would almost certainly be a bad idea to introduce a virtual network appliance because such solutions are much more constrained in terms of capacity than their hardware counterparts. This is due to inherent limitations on the virtualization platform, the network interfaces, and the operating system (if it is in the mix).

Where a single hardware load balancer can sustain millions of TCP connections, a virtual version of the same solution will unlikely be able to reach half of that capacity. The differences between hardware and software solutions are minimal, but among those differences are the way in which the different implementations interact with the network and available bandwidth. As we discussed in another post on a similar subject, scalability also becomes problematic because deploying multiple, cloned instances of any solution as a means to achieve higher capacity limits requires the use of virtualization, a la load balancing.

These high-volume, high-capacity strategic points of control are simply not good candidates for virtualization as a means to achieve scalability. There are two options for scaling these hardware solutions – use an extensible chassis based solution that can accommodate expansion of capacity through acquisition of additional “blades” or take advantage of the fact that most are equipped with specialized “clustering” that allows multiple devices to work in parallel while still ensuring reliability through fault-tolerance mechanisms.

This makes it appear, at first glance, that there is no room for virtualized infrastructure. Au contraire, mes amis! There are several key points within the architecture where scalability through virtualization is actually an excellent method because of the inherent characteristic of virtualization that turns a “network connection” between multiple virtual instances of applications/infrastructure on single physical server into something more akin to that of a high-speed internal interconnect. Much like a bus internal to the hardware, this “virtual bus” reduces the impact of the network on communication between components.

When you deploy multiple virtual machines on the same physical hardware, they communicate through virtualized network interfaces. Those interfaces ultimate utilize underlying physical network connections and thus act in a manner similar to that of physically interconnected devices. When all the relevant components reside on the same physical machine, however, the communication never actually ends up “on the wire.” That is, the communication between web and application servers deployed as virtual instances on the same hardware never leaves the physical machine and thus does not incur any of the normal network latency associated with communication between tiers in an application architecture. Thus, deploying a virtual instance of a load balancer as the means by which the application server tier is assured availability and scale can improve application performance because no network latency is incurred during normal web transaction processing. All the communication stays on the physical server and occurs in the virtualization layers.

Obviously this architecture is particularly well-suited to the VNAs for which proxying behavior is core within a two or three-tier application architecture: load balancing, caching, and application offload services, because it eliminates the out and back traversal of the network that would otherwise be required to accomplish such tasks.

The level of scalability needed by a component is highly dependent on the location of its functionality in the overall network architecture. Aggregation points inherently require high-volume, high-capacity solutions through which massive volumes of traffic/requests can be directed. But internally, in what is essentially becoming networks within networks, scalability can be accomplished using VNA equivalents of traditional hardware solutions.

Interestingly, this style of hybrid application delivery architecture may aid in the move toward more complete packaging of “applications” between cloud computing environments and data centers. If all necessary components are packaged together and intended for deployment on a single, physical server then moving them becomes possible. This is obviously not the case with physical solutions which cannot be assured to be available in cloud computing environments and would likely be financially prohibitive to deploy in a traditional co-location style arrangement, if cloud providers allow such an arrangement (some do – by the way).

While speeds and feeds will remain important in the design of network and application delivery networks, new architectural strategies will be required to scale environments in which both server and network appliance virtualization will be used. It’s not an automatic 1:1 replacement strategy that will achieve the scalability and flexibility desired; on the contrary it will take a good understanding of the pros and cons of both virtual and hardware network appliances to determine where best each will fit in a scalable, highly performant network architecture – whether in the local data center, or in “the cloud.”

UPDATE/RESOURCE: Eric Siebert pointed out that traffic flow in and between the physical network and the virtual network is highly dependent on the configuration of multiple components. This is a great post by Eric detailing the flow of traffic based on configurations.