Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Virtualization: Just how far are we willing to take it?
posted on Thursday, September 18, 2008 7:26 AM

If your entire data center infrastructure is on one virtualized PC, you're doing it wrong.
Where's F5

The comparison between the power of a modern PC and a 1960's mainframe is often made in conjunction with a smug "look how far we've come" look.

But the way virtualization is headed today it's likely that mainframe holdouts will turn that smug look back on us with a blithe, "yes, you've gone all the way back to beginning."

If we're not careful, by the time we're through deploying virtual everything we're going to end up with a single PC comprising our data center. Which is pretty much like a mainframe, isn't it?

We're certainly headed that way. Virtual appliances for security, for switching, for many functions handled by network infrastructure are arriving daily. And we're lapping them up like a cat given cream.

Now I'm not going to go as far as @Beaker in his Four Horsemen of the Virtualization Apocalypse and claim that every time you deploy a piece of network infrastructure as a virtual device that God kills a kitten; but I think He just might kick one every time you deploy what is traditionally a network infrastructure function within a virtual appliance.

L2-3 switching used to be done in software, before the advent of network processors and high-speed backplanes and switching fabrics. When there were no VLANs (Virtual Local Area Network) and there were no ACLs (Access Control List) and there was nothing but forwarding of packets.

Routing used to be done in software before there were route optimizations and link load balancing and complex algorithmic configurations designed to optimize the flow of traffic in and out of a private network.

Load balancing used to be done in software before it got married to switching and figured out how to do incredibly interesting things with application traffic at high speeds and high volumes like acceleration, protocol optimization and security, and application switching.

So why are we thinking about reversing the advances in high-speed, high-volume network infrastructure by putting it back onto a platform that, while more powerful than its predecessors, is still heavily limited by the commodity hardware on which it will be deployed? Do we really want reduced capacity? Reduced performance? Limitations on concurrent connections, sessions, and users? 

Why are we thinking about creating a single point of failure and introducing what would certainly become a single bottleneck in application and network performance? It's hard enough as it is to troubleshoot a network and an application, can you imagine the difficulty in troubleshooting a completely virtualized infrastructure?

How much functionality will we attempt to cram into virtual machines before we realize that we've reversed most of the gains we made with server virtualization in the first place? Will we really not be happy until we've crammed every piece of network infrastructure back into software on a virtual appliance? Didn't we learn from the 1990s that deploying technology simply for technology's sake was a bad idea?

 

Apparently not.

Follow me on Twitter View Lori's profile on SlideShare AddThis Feed Button Bookmark and Share




Email This
  del.icio.us
      

Feedback


9/19/2008 11:33 AM
Gravatar What scares me more than bottle-necked performance and reduced flexibility is the fact that this scenario introduces a single point of failure. Now you have to worry about high availability, and to achieve that with less hardware, that hardware has to have expensive power redundancy (or UPS) and failover capabilities (meaning you now need two big expensive boxes). On the other hand, it's hard to deny the money and energy savings that can be had from consolidating functionality in virtual environments. The trick here, like in most things, is to find the appropriate balance. Virtualize applications that run well on commodity hardware while investing in specialized hardware for functionality that can see real benefits from it.
Kris Plunkett
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 1 and 1 and type the answer here: