Lori MacVittie

We worry about VM sprawl but what about device sprawl? Management of a multitude of network-deployed solutions can be as operationally inefficient as managing hundreds of virtual machines, and far more detrimental to the health and performance of your applications. Turning them all into virtual network appliances that might need scaling themselves? That’s even badder.

But all you hardware fanbois best not smirk too much because the proliferation of hardware network devices is only slightly less badder than the potential problems arising from virtual network appliance sprawl.  

WAIT, WHY IS DEVICE SPRAWL BAD AGAIN?

All the same reasons cited by various pundits since the virtualization craze began regarding the difficulties associated with virtual machine sprawl can be applied to virtual network appliance sprawl. For the most part it applies to hardware network device sprawl, too, for that matter.

1. Cost of IPAM (IP Address Management)

This is probably even worse than is often described by Greg Ness when it’s applied to network solutions as compared to virtual machines simply because most network solutions have at least two IP addresses assigned to them – one for management and one to do its job – if not more. There are exceptions, of course, as some solutions are deployed inline and transparently, but there are other challenges associated with such configurations as they often require port mirroring which effectively ties the solution to a specific port on a specific switch. Obviously moving it or scaling it out horizontally as a virtual machine would prove problematic for these solutions. So let’s just ignore those for the purposes of this discussion, shall we? 

2. The impact on performance

Ignoring scalability – let’s assume a virtual network appliance is equal to the task for this post – the more points at which requests/traffic must stop and be processed the more latency is incurred. If you string together enough devices – regardless of the physical implementation – you are going to degrade performance. In some cases by a few milliseconds, in others perhaps by seconds. The amount of degradation relies heavily on the volume of requests, the type of processing being performed, and the capacity of each network device. Remember that the network is only as fast as its slowest hop, and that one poorly performing network device can destroy network and application performance.

3. Cost of management, power, and training

If you deploy five different network devices to address five different needs, you incur the cost of management, power, and training for each of them. This is true regardless of physical implementation as moving a solution from hardware to a virtual appliance doesn’t change the fact that it (1) needs to be managed, (2) has an interface/commands/quirks that need to be learned, and (3) consumes power.

4. Trouble with Troubleshooting (a.k.a. Lack of Visibility)

Even if every one of the X network solutions you have deployed individually has great visibility you’re still going to run into trouble troubleshooting. That’s because what one device may or may not do to a request/traffic isn’t easy to correlate by the time it’s passed through the fifth or sixth network device. It’s not as if all these devices add metadata that describes what they did to the traffic, they just do it and pass it along. The more devices, the more complicated this process becomes.

5. Special Issue with Virtual Network Appliances: Distributed Management

Remember how you didn’t want to shell out the extra cash for the vendor-specific distributed management solution? If you’re scaling out a network solution via multiple virtual network appliances you may want to reconsider that decision. Once you get past a couple of instances you’re going to need something to help you manage them and keep their configurations in synch or you’re asking for trouble. And don’t forget about the hypervisor management system, too. You’ll need that, I’m sure.

Sprawl of any kind incurs costs per node at a fairly consistent rate. Every instance – physical or virtual – adds to the combined total cost of ownership and investment in time. Every device through which traffic must flow also incurs a performance penalty, which to the business stakeholder is probably more dangerous than the hit on your budget.

UNIFIED APPLICATION DELIVERY INFRASTRUCTURE

Unified application delivery infrastructure can’t completely eliminate every other network device because generally speaking some network devices aren’t focused on application delivery but are instead wholly focused on network security or compliance or business functions that really have very little to do with managing networks or delivering applications.

Yeah, I know. Surprised me too when I found that out. There are actually solutions that aren’t focused on network or application networks. Whodda thunk it?

But for application delivery focused solutions – acceleration, optimization, caching, application security, load balancing – the solution to the problems of network device sprawl are unification onto a single, extensible (modular) platform. And while many network folks hear “modular” and think “chassis” (and that can be one approach) I’m talking about the core system itself. The solution, not the container.

By sharing a common core networking platform, a unified application delivery infrastructure mitigates the problems associated with extra hops/stops in the flow of requests/traffic by eliminating them. Requests that need to be passed through a web application firewall before being passed to a Load balancer do so, but because the common core networking platform is shared there’s no network or network stack overhead incurred by the passing of the data.

Network sprawl really is badder than VM sprawl because it not only increases the overall cost to deliver and secure applications but it can also negatively impact the performance and reliability of applications. A unified platform affords choice in the ability to add functionality as needed, to try out functionality to see if it’s worth it, and to scale out in a more efficient way on an as-needed (on-demand) basis.

One of the reasons virtualization is so appealing is it addresses nicely the “lots of little boxes” problem that causes management headaches throughout the data center. Consolidation through virtualization was the answer to that one, at least in terms of the sprawl associated with the physical devices. Unified infrastructure addresses the same “lots of little network boxes” problem that causes similar headaches on the network and application network side of the data center by consolidating many of the application delivery focused functions onto a single, shared and extensible application networking platform.

Related blogs & articles:

• The Application Delivery Deus Ex Machina
• The Question Shouldn’t Be Where are the Network Virtual Appliances but Where is the Architecture?
• What Are the Barriers to Entry and IT Diseconomies?
• Infrastructure 2.0: The Diseconomy of Scale Virus
• Disk May Be Cheap but Storage is Not
• Infrastructure 2.0 Is the Beginning of the Story, Not the End
• Virtual Network Infrastructure: Virtually Good Enough?
• Virtualization: Just how far are we willing to take it?
• Imagine...Manageability
• Two Different Sock(et)s
• The House that Load Balancing Built
• Building an elastic environment requires elastic infrastructure