posted on Monday, January 11, 2010 3:21 AM
If you’re just trading “specialized” hardware for “dedicated” hardware you’re losing more than you’re gaining.
Apparently I have not gotten the memo detailing why specialized hardware is a Very Bad Thing(TM) . I’ve looked for it, I really have, but I cannot find it anywhere. What I did find was any number of random press releases announcing how “virtual version X” of some network or application infrastructure solution was now virtualized and hey, you don’t specialized hardware to run it. These random press releases neglect, I might add, to mention that there's very little difference between the requirement for "specialized hardware" and "dedicated hardware" in terms of cost of ownership, maintenance, and operational costs.
But Lori, you say, incredulous that I am apparently in so much denial I can’t see that the beauty of virtual infrastructure is that there is no longer a need for dedicated hardware.
Hogwash and horsepuckey, I say. Apparently I’m not the one in denial.
RISK, REVENUE, and RELIABILITY
The concept that you can share hardware for infrastructure is certainly a true one but the reality is that most organizations are never going to do it. Ever. Not to pick on Cisco here, but did you ever wonder why it was that AON didn’t ever pan out? It was an awesome concept, in my opinion, and one that’s been more successful implemented on other Cisco platforms, like AXP (Application Extension Platform), because no router jockey, and thus by extension no organization, was going to potentially compromise their core routing 
infrastructure by allowing other code and functionality to co-exist with it. At least none that hoped to keep their jobs, anyway. That the concept has panned out better on other platforms is no surprise because those platforms are less critical to business continuity and revenue generating business processes. Juniper’s recent re-launch of “the network”, too, points to an increasing interest – at least from the vendor world – for more open, programmable network infrastructure. Whether Juniper will be more successful on its core routing platforms than Cisco remains to be seen, but I’m betting they’ll see the pattern of behavior that Cisco has, which is to say: no developed code on critical network infrastructure.
And it isn’t just third-party developed applications that give organizations and network teams pause. A unified application delivery platform is highly “pluggable” and can be provisioned to execute a variety of application delivery functions (acceleration, security, optimization, etc…) and yet there are a large number of organizations who stand fast and prefer to provision only critical, core functionality such as load balancing on such platforms as a means to ensure application availability. They don’t want anything to potentially interfere with that process. Period.
Some pieces of infrastructure – particularly those that are part of the network – are so critical (and so very underappreciated) – that they simply cannot be exposed to the kind of risk that comes from “sharing” resources in any model. If revenue is generated on-through-over or continuity requires the availability of network component X then the availability and reliability of X cannot be compromised in the name of following the latest hype/trend/etc.. or saving a few bucks a year.
That means, ultimately, that most virtualized infrastructure – if it ever exists – would simply end up replacing “specialized” with “dedicated” and incur approximately the same costs for power, space, and cooling as the physical version. Management costs remain the same, after all, because it’s not like moving from physical to virtual changes the product or its management interfaces. Virtual versions of infrastructure aren’t any more automatable than their physical counterparts, and they’re likely managed from the same, dedicated management systems that have always managed them.
This belief that critical network functions are suddenly going to become virtualized and co-exist with other pieces of infrastructure or applications, heaven forbid, is misguided. It ignores the fact that if not for the stability and reliability of all that “specialized” hardware that we wouldn’t be able to focus on building out virtual application infrastructures in the first place. That without the stability and reliability of tried and true, proven hardware solutions “cloud” in any shape or form wouldn’t be a possibility because we couldn’t trust the network enough to deploy critical business applications anywhere but on our own desktops.
TWO STEPS FORWARD, THREE STEPS BACK
Proponents of dropping specialized hardware like compression and SSL acceleration hardware point to the constant increase in raw processing power of general purpose CPUs and use it as a reason why the specialized hardware is no longer necessary. What they neglect to mention is that the same improvements in processing power also benefit the specialized hardware, making its increase in performance and raw compute power rise along with that of than general purpose compute power. Those improvements and subsequent performance benefits to applications are lost when moving from specialized (purpose-built) to dedicated/shared (general purpose) compute platforms.
There are real benefits and reasons for infrastructure vendors to provide virtual versions of their solutions: testing, developer integration, solution creation, secondary data centers, first hit’s free marketing, etc… For non-critical infrastructure, i.e. the business could continue to run and generate revenue if it was not available, virtual solutions and shared hardware are indeed a good way to decrease costs, shrink the data center footprint, and scale out on a moment’s notice. But for critical network and application network infrastructure - the components in the network that are so tightly coupled to the business’ ability to execute on a daily basis and generate revenue - it just seems foolhardy to share hardware or otherwise risk compromising the availability and reliability of those core functions. If the outages of Amazon and Google over the past year have taught us anything it’s that reliability is as important if not more so to the organization as decreasing costs.
That ultimately means you’d simply replace “specialized” with “dedicated” and in the process lose whatever performance or functional benefits are associated with the “specialized” hardware. That tradeoff may not be nearly as beneficial to the organization – or its users and customers – as is put forward by marketing hype around virtualized infrastructure solutions.
Related blogs & articles:
Technorati Tags:
MacVittie,
F5,
hardware,
virtualization,
infrastructure,
application delivery,
network,
software,
business,
amazon,
google
