I read several articles this morning declaring that load balancers days are numbered.  I wish this were true, and it should be true, but no amount of press can prevent organizations from continuing to resurrect the "King." Much like those who continue to hand money over at the box office to the Jason & Freddy franchises, as long as companies fork lift the old and insert the new without any forethought into what might be possible with a new platform, they will continue to deploy load balancers in load-balancing replacement projects, no matter how powerful the shiny new application delivery controllers are.cod 

The certificate of death has to come from the trenches. 

Load balancers are now a commodity to the market, but they are very much engrained in the enterprise.  It's going to take a paradigm shift at the executive level to leverage the power of what many already have in an application delivery controller.  Network and Application need to come together, and the c-level execs need to bridge the divide between the network administrators--who need to expand their skill set to climb the OSI model a few more layers, and the application developers--who need to expand their requirements gathering and development cycles to include other parties of interest. 

Mark Fabbi is spot-on with his advice for the Enterprise, (last section of the article): "Start building application delivery expertise."  This doesn't mean understand how to configure your application delivery controller.  I had a couple mentors years ago (thanks Bob & Dave) that taught me to invest more time in the technology behind a product, not the product itself, so that your skills are universal.  This is especially true with application delivery, because the ADC is but one piece of the puzzle.  It's a critical piece, but you've missed the forest for the trees if you as an application delivery specialist are relied on solely to configure "X" requirements instead of contributing thought leadership in the design and troubleshooting efforts of the applications. 

Sorry, stream of consciousness there...back to Mark's advice on attacking application delivery: I'd extend his approach by creating an application-oriented networking group comprised of application, network, system, and security architects who would cross-train each other, ensuring focused expertise in individuals and generalized expertise in all.  This team would report outside the network and application departments and all appropriate requirements would feed through them.   In the end, you have a one-stop shop for accountability.  Network and Application may not like the loss of territory, but ultimately, it's about meeting business requirements, right?

Follow me on Twitter Follow me on LinkedIn Follow me on Facebook