Proprietary tech will dull blade server growth While gazing into its crystal ball, Gartner has reached a spectacular conclusion about the future of the blade server market: Proprietary hardware is a pain in the ass. The analyst house warns that although it expects blade servers to continue selling gangbusters for the next five years, a combination of rapid advancements in …
Well, it looks like none of the main blade vendors wants to blink first, so the chassis designs will probably stay very different which means the actual server blades will too. The only area I can see with some possible commonality is the switch modules, which are all coming from common vendors such as CISCO, Brocade, etc. Now, if they agreed a common standard/format for the switch modules, that would be a start, and then maybe there would be a drift towards standards over time, but I still think the idea of being able to use other vendor's blades in a different vendor's chassis is just not going to happen without some licences being bought.
Having said that, I don't see why the proprietary design nature of today's blades is such a problem seeing as it reflects the proprietary design of most x86 servers. How many components can you take from Xseries server and stick into a ProLiant? The CPUs, but you'd have to check which ones, and the the heatsinks would still have to be the proprietary designs to make sure they fitted. The disks, probably, and maybe the RAM, though you'd likely invalidate your warranty by doing so. But you can't switch the motherboards, possibly even many of the interface cards. So are blades a more proprietary issue than x86 servers? Or was it just a slow news day at Gartner when they dished out this report?
This is ESPECIALLY onerous if you are at the end of a life cycle. Imagine making a huge investment in "P" class blades, only to see the new "C" class blades supersede them next year.
Vendors will promise overlap, and then hose you in the few final months. GET ROAD MAPS from you vendors, and get promises of support IN WRITING. You will never get it, and the roadmaps you CUSTOMERS will see will likely be 6-month jobs.
Realize, though, you can get a ton of value from Blade technology, and most customers tend to select a single server vendor anyway (for spare parts advantages, sophisticated management features etc.) Nothing INHERENTLY wrong with proprietary in that sense.
If you know the "series" of enclosure, blade form factor, infrastructure etc. is nearing five years, you can bet your vendor is AT LEAST designing the next generation of incompatible successors.
If you can, get 36 month leases with "tech referesh" in mind. If you can, at all, abstract your software (Virtualization, streaming, diskless boot, etc.) you can shield yourself to some extend from hardware changes.
Virtualization reduces your servers to files on a disk making you much less dependent on what vendor supplies the hosts. "Rip and Replace" goes away, if you can live migrate from one platform to another.
Just be careful, and pick your platform wisely, as you won't be migrating from AMD to Intel or vice versa.
The statement "Major vendors such as Dell, Hewlett-Packard, IBM, and Sun Microsystems all lock in their hardware" is incorrect.
SUN's does not lock you into their proprietary "hardware": they do not lock you into a proprietary backplane (as does the other vendors in your list), offers Open-Source CPU (http://www.OpenSPARC.com/), offers 2 proprietary vendor CPU's (i.e. Intel & AMD), offers open standard I/O slots, offers their Open-Source CPU for integration into a proprietary IBM Blade Chassis, does not require proprietary KVM systems, does not require proprietary chassis management software like the other vendors in the list, and support runs Open-Source (i.e. Linux, Solaris) as well as proprietary operating systems (i.e. M.S. Windows.)
SUN is more open than the other listed Blade vendors... while not perfect, if someone does not like them, they can swap to and from 1U boxes while not changing your management or provisioning software (unless swapping TO a proprietary blade vendor, where one will have to buy special proprietary hardware software enablers, I/O cards, KVM management, management systems, etc.)
The fact that Dell, IBM, and HP are more closed is not SUN's problem.
Cost will probably dampen growth of the Blade arena more aggressively than proprietary lock-in (of vendors like IBM, HP and Dell.) Theoretically, a blade platform should be cheaper (due to component re-use), but I have yet to see this to be the case.
Your points are well made, especially the key one about demanding a vendor roadmap.
Note though: You can't do seamless live migration if the CPU flags have changed, which is likely at the tail of a three-year lease refresh.
@David Halko: your points are not well made. None of your suggested "openness" has any value once blades are deployed in the enterprise data center, no matter which vendor they came from.
You commented, "None of your suggested 'openness' has any value once blades are deployed in the enterprise data center, no matter which vendor they came from."
I would suggest you review my comment and see the statement, "if someone does not like them, they can swap to1U boxes while not changing your management or provisioning software." An enterprise architect must take end-of-life as well as non-performance risks of a platform into consideration - there is value in risk mitigation.
In essence, I provided the benefits to not choosing proprietary vendor choices. One could seemlessly swap SUN out, without a loss in the investment any proprietary hardware, software, and sub-systems (which I had listed in detail in 2 different ways.)
There are implicit benefits of not being tied to proprietary hardware, software, and sub-systems - which I did not list because I had believed they were self-evident... let me list a few:
+ reduced customer cost - If a business does not need to invest in proprietary hardware, sub-systems, and software - then this money could be invested in other areas of the business
+ increased customer flexibility - if non-proprietary equipment is used, flexibility is optimized, and the need for future vendor roadmaps is mitigated, since financial investment in proprietary solutions does not need to be depreciated over a long period of time and future architecture changes does not obsolete previously purchased equipment
+ increased supplier flexibility - if non-proprietary equipment is used, the supplier is not burdened with sacrificing future performance & features in order to fit the old proprietary pieces (i.e. backplane, cards, etc.) and more supplier options can be made available at a lower investment threshold since the supplier is building common options for multiple families of systems leveraging economies of scale
+ increased choice - since more options can be made available at a lower investment threshold by the supplier, more options will be made available upon customer request. A fine example of this was the Open Source T* CPU Series from SUN being able to be fit onto a proprietary card onto a proprietary backplane into a proprietary IBM Chassis (in my former comment.) This would have been less likely if the SUN OpenSPARC T* CPU had a proprietary bus (i.e. remember Intel putting the screws to AMD when AMD wanted to continue manufacturing CPU's that would slot into an Intel proprietary bus socket?)
+ increased I/O options - using standard I/O cards (which I had listed in my previous comment) in a blade system means off-the-shelf cards can be leveraged from former investments in the new non-proprietary (i.e. SUN) blade system implementations. Existing spares at a customer site can be leveraged for new non-proprietary blade implementations. If the new non-proprietary blade system is swapped out, then the standard I/O cards from the non-proprietary blade system (i.e. SUN) can be re-leveraged into other existing server spares or even into new systems to replace them. If the blade system is outgrown (i.e. application requires more CPU or memory capacity than a blade can offer), the I/O parts can be moved to a different (non-blade) chassis, conserving parts from the original investment, or even leveraging the I/O spares from the non-proprietary blade server investment. Furthermore, if the non-proprietary blade supplier (i.e. SUN) does not offer a card, the customer can go to a third party to get the appropriate card to meet their business requirement.
There are many reasons why Gartner indicated that the proprietary blade technology would dull server growth. Suggesting the "openness" I listed does not have any value suggests that Gartner is wrong in it's assessment.
I had also indicated that Sun is "not perfect" - I wish a vendor in the industry would open-source a blade standard and invite other vendors to join in, as had previously been done successfully with hardware & software solutions to create huge markets of choice:
+ SPARC platform (i.e. TurboSPARC, HyperSPARC, SPARC64, "Niagra", etc.)
+ OpenFirmware (i.e. SUN SPARC, Macintosh, etc.)
+ POSIX (i.e. Linux, Solaris, OpenSolaris, HPUX, AIX, AUX, MacOSX, etc.)
+ X Consortium (i.e. Hummingbird & Exceed, Linux & XFree86, Cygwin/X, MacOSX and X Windows, SUN Solaris & OpenWindows, etc.
+ Java (i.e. Eclipse, NetBeans, Tomcat, IBM VM Microsoft VM, OpenJDK, Glassfish, etc.)
+ Open Document Format (i.e. OpenOffice.org, KOffice, Google Docs, NeoOffice, Zoho, IBM Lotus Symphony and Corel WordPerfect Office X4, etc.)
+ HTTP/HTML Protocols (i.e. Server: Apache, Tomcat, IIS, Netscape, etc. ; Clients: Netscape, Mozilla, Internet Explorer, Safari, etc.)
In conclusion, I hope this clarifies the value for "openness" in the blade server market, both from an immediate value, future value, and examples of how "openness" had benefited other markets to create huge marketplaces for commodity hardware & software.
Joshua Goodall comments, "Note though: You can't do seamless live migration if the CPU flags have changed, which is likely at the tail of a three-year lease refresh."
If the implementation is not done on a proprietary platform, CPU flags should not make a different for live migration.
A fine example of this is with SUN's (soon to be E.O.L. UltraSPARC, being replaced with the APL) line of servers... being able to swap out UltraSPARC III Uniboards with UltraSPARC IV Uniboards, and later on UltraSPARC IV+ Uniboards - with better-than-linear improvements in throughput over nearly a decade. This could be done on the mid-range equipment with a restart and on the high-end equipment without ever shutting down the application.
Considering the UltraSPARC III went GA in systems shipping back in 2001 and UltraSPARC IV+ are being EOL'ed in 2009 - we are talking about a significant investment buy-back from open vendors and live migration capabilities in contrast to proprietary vendors. The old boards 2001 boards are compatible with the systems shipping today, in 2008!
One has to have selected a real open operating system, a real open firmware, and a real hardware platform in order to do live CPU/Memory/I-O board adds and removals... but that is the value proposition of Open Hardware, Open Firmware, and Open Operating Systems.
Just because proprietary system vendors and proprietary operating systems may not offer the same level of portability for a layered application product does not mean this level of portability does not exist in the marketplace at a competitive cost.
The lack of "seamless live migration... at the tail of a three-year lease" when that feature is a business requirement is the fault of a poor architect who selected a vendor's poor hardware or selected a poor vendor.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
