iBoot: An old idea kicking around again

The more things change, the more they stay the same. For a great example, take a good look at IBM's latest development, iBoot.

Even though IBM is second to none in technological innovation, iBoot is, in fact, just an incremental improvement of an extremely old idea: remote storage. The only new thing I see is the iSCSI standard--and that's not even particularly interesting.

When I was the Technical Director at PCWeek Labs in the early 90s, diskless workstations that booted DOS/Windows from the network were commonplace in the market if not in client locations. True, the process wasn't really a standards-based affair, since it relied on proprietary boot ROM chips on the network card. But, it effectively amounted to the same thing as this "new" IBM stuff. Diskless workstations, in the form of X terminals, are an even older idea in the UNIX world.

Then in the mid-90's, in response to the silly Java Network Computer craze (hard to believe anyone ever fell for that), Microsoft came out with their own silly Network PC idea. Once again, this was basically a diskless workstation, but it was based on some new software utilities--the Zero Administration Kit--that were interesting, but ultimately unimportant. Other remote boot solutions, such as Intel's Preboot eXecution Environment (PXE), are widely implemented in systems, but not widely used. PXE does have some interesting uses--for example Microsoft's Remote Installation Services (RIS) use it to automate remote OS installations. Most of these remote boot systems, including PXE, rely on a FTP server to transfer the boot image to the client.

Five years have gone by, so I guess it must be time to resurrect the remote storage idea. Perhaps this is related to IBM's recent decision to sell off the lower end of its hard disk business. iBoot makes sense if you want to sell higher-end, server-based disk space as opposed to low-margin client disk space. In fact, IBM's iBoot page makes copious mention of the benefits of SANs and other expensive storage technologies that one would need with an iBoot-based network.

But to be fair to iBoot, there are cases where it makes sense--especially compared to other remote boot technologies. One interesting example is blade servers. If you really need to make your servers as compact as possible then it makes sense for them to share storage--but only in a blade situation where the "network" connection from the server to its storage is likely to be very fast.

Arguably, if you're doing your computing on a client, it makes sense to take advantage of the client's local storage, which is extremely cheap and fast. Although there are certain advantages to storing data on a server, where it can be centrally backed up and shared among multiple clients, but there are also costs--namely, the need to shift all your disk traffic to the LAN. Do you really want to do that? Imagine rush hour at the office around 9:05 a.m., when everyone boots up, logs on, and loads applications. I have visions of the George Washington Bridge with both decks backed up 5 miles into New Jersey...

Remember, whenever this idea makes the rounds, the inspiration is always management and cost-related. In the Network Computer vs. Network PC war, the rallying cry was TCO (then a relatively new term). The idea was that by streamlining client management you could lower overall costs. And of course this idea has a lot of merit, but there are good and bad ways to go about it.

If your goal is to simplify administration of users and applications (client systems only), the answer is not a hybrid of local computing and central storage. Instead, you would want to move to a true server-based computing architecture. You can even do it gradually, and it's old, proven technology. Microsoft's Windows Terminal Services and the more advanced Citrix MetaFrame XP (based on Terminal Services) move both processing and storage to the server. You can run applications on these servers while retaining a conventional PC/LAN architecture, or you can dump your PCs altogether and run Citrix or Terminal Services dumb terminals--Winterms. In either scenario, the load on your network will be less than with this iBoot business.

IBM doesn't have any actual product plans based on iBoot yet. When they do, it might become a nice enhancement to server blades, or a tool for certain Linux-based businesses. But no new protocol can make remote storage appropriate for circumstances where it's not, and that would be most.

What's your take on IBM's iBoot? Speak your mind in our TalkBack forum, or send a message to Larry.