Blades: Platform of the future

In a column earlier this year, I predicted that the communications platform of the future would be the blade server. My prediction is beginning to be played out on blade servers from HP, IBM and Sun. Companies that have announced communications blades for the IBM eServer BladeCenter include F5 Networks, Myricom Netilla, and Nortel .

Not to be outdone, the HP ProLiant Blade Server has a GbE2 Interconnect Switch option, which is a 24-port gigabit switch module designed by Nortel; infrastructure option blades for traffic management and load balancing from F5; and a VPN/firewall blade from Check Point. Meanwhile, the Sun Fire Blade Platform has added “specialty” blades using onboard hardware acceleration for VPN and SSL proxy functions, content load balancing, firewall security and cache features.

Cisco  has been busy focusing on transforming its existing products into competing multifunctional platforms. For some time, Cisco has been adding functionality using add-on cards for the router or LAN switch. Firewall, cache, VPN, load balancing and security cards exist for multiple versions of the Cisco router and LAN switches using IOS.

Cisco’s recently announced CallManager Express and Unity Express join its CallManager, CallManager SRST and Unity products to add VoIP within the router and LAN switch. Voice services are delivered via Cisco’s access routers, including the Cisco 1751, 1760, 2600XM, 3600- series and 3700-series routers, and the Access Gateway Module, available on the Cisco Catalyst 4500-series switch. The key ingredient in this strategy is the inclusion of voice applications  (PBX, Automated Attendant, mail) into IOS.

The third platform created by Cisco is the MDS 9000 Multilayer Intelligent Family of storage-area network directors and fabric switches. IBM has ported its TotalStorage SAN Volume Controller storage software into the Cisco MDS 9000 . This integrated solution will let customers administer volume management, data replication and point-in-time copies over the network across multiple storage subsystems.

Which approach will win out in this battle for control of the communications platform?

My opinion has not changed; the blade server will become the communications platform, for many reasons. These include cost; open, published hardware/software architecture; sophisticated third-party developer alliance programs; third-party channel sales assistance; the use of standard operating systems; scalability at low cost; the reliability of the platform; autonomic functionality; and the ability for dynamic provisioning/manageability.

Then why isn’t there a rush to replace communications platforms?

There are several reasons:

• The legacy problem of the installed base – not insignificant considering the number of LAN switches and routers installed in corporate data centers.

• Users’ relative inexperience with blade servers.

• Lack of multiple-vendor products certified for insertion in a blade server; the add-on blade has yet to become a commodity.

• The management “island” problem of policy, systems, networking and storage. Web services and other standards could address this critical issue – but only time will tell.

• Last, and most significantly, there is the issue of IOS – impenetrable by a third party, as pervasive as Microsoft’s Windows operating system and as proprietary as IBM’s legacy SNA. Unfortunately, until the industry comes to grips with the IOS issue, the blade server will remain a communications platform “work in progress.” Cisco has publicly committed to implementing the open interfaces specified in the Open Grid Services Architecture. Although initially focused on grids, these Web services interfaces one day might become the only open software portal into IOS services/applications. Use of these interfaces, also contained in servers and storage, would set a level playing field for communications functionality in the blade server.