iSeries High Availability Should Be Integrated and Invisible

When the AS/400 was announced, in 1988, its was arguably the first truly integrated system. The AS/400 wove together an operating system, a relational database, and sophisticated programming languages, and on top of that sat a wide variety of applications available from IBM as well as third parties. It was this tight integration that differentiated the box from the competition and gave the AS/400 platform the total-cost-of-ownership benefits that are the hallmark of the box.

While IBM and its high availability software partners have done much to make high availability software suitable for the OS/400 masses during the past 15 years, they have yet to deeply integrate the software to the level of transparency that DB2/400 enjoys. To be fair, with the launch of OS/400 V4R4, in early 1999, IBM and Vision Solutions worked to put some of the clustering and system mirroring functions that are used in high availability clustering right into the microcode guts of OS/400. This gave all high availability software partners access to a set of consistent clustering and mirroring APIs, from which they could build their respective software products for OS/400, DB2/400, and their applications. This initiative was a big improvement for IBM and its partners, as well as OS/400 shops that needed the software to make their AS/400s more resilient. But it is time for IBM and these partners to work together to take the next step.

High availability should be a basic and transparent feature of every eServer i5 machine, from the biggest i5 Model 595 to the smallest i5 Model 520 Express machine.

Before I get into what I mean by this, let me first say what I do not mean. I do not mean that IBM should launch its own high availability software line or acquire one from another player and bundle it onto the i5s. I like that there are half a dozen high availability software providers in the OS/400 market. The entrance of new players has created a wave of innovation and has significantly lowered the price of the software. These are very good things for OS/400 shops, and only a fool would try to stop this innovation.

What I am suggesting is that IBM and its partners work together to make the software a core differentiating feature from Linux, Windows, and Unix platforms, not an option for the top several thousand of OS/400 customers. There are a couple of ways this could be accomplished.

When I wrote a series of articles two years ago describing what my “iDeal iSeries” product line would be, I admitted that, because IBM does not charge a per user fee for access to OS/400 and DB2/400, the only way to create an entry OS/400 server was to slug it so it would support far fewer users than is theoretically possible. In many cases, as much as three-quarters of the processing capacity of a machine is idled in these entry machines. For the iDeal iSeries machines, I suggested that IBM could make use of this “shadow capacity” in these slugged OS/400 servers, and that one of the obvious ways of making use of that latent processing would be to put high availability software on the machines and cluster to a shadow partition that users would not even know was there. In the event of a failure in one partition, the shadow partition would take over processing until the problem could be fixed. The idea is to turn an OS/400 server, which is already able to deliver great reliability as a stand-alone machine, thanks to its architecture, into a highly available application platform, a platform that is clearly differentiated from Windows, Linux, and Unix platforms (which do not offer such differentiation).

When discussing the iDeal iSeries, I did not think that embedding high availability capabilities into midrange and high-end OS/400 servers was necessary, since bigger OS/400 shops typically have the budget for high availability software and mirrored systems. But I have since changed my mind. I think all OS/400 servers need this high availability capability tightly integrated and as invisible from users and system operators as is practically possible.

It is important to realize that I am not suggesting that IBM ship two physical servers that are mirrored to any customer that buys a single server. I realize that, for many customers, having two machines, often geographically separated, linked by high availability software is vital because they simply cannot have any downtime. These shops could continue buying the high availability editions of iSeries or i5 servers and the high availability software. What I want IBM to do is make high availability clustering across partitions, which, admittedly, still has a single point of failure (the i5 server itself), a basic function of the servers. This will give greater application availability to all i5 shops, which would be important to each shop and would be an important differentiator for the i5 server in the midrange market at large.

It is hard to say how much hardware sales the high availability vendors drive these days, but IBM is obviously keen on not upsetting its revenue stream or that of its high availability software partners. I have the same concerns. In the heydays of the late 1990s, when OS/400 server sales were higher and more predictable, I estimate that high availability software probably drove anywhere from $500 million to $700 million in OS/400 server sales in an overall market that pushed about $3.5 billion to $4 billion in server sales. As IBM has launched two iSeries generations (in 2000 and 2003) and the i5 machines (this year), it has radically dropped prices on hardware and has shifted a slightly larger percentage of sales to the business partner channel, and iSeries sales have been cut in half. Shipments have fallen dramatically, too, so the decline in overall iSeries sales is not attributable solely to price cuts. It is hard to say if high availability software is still driving a proportional amount of iron, or if the rate is even higher.

By deeply integrating the software in the i5 servers, IBM may only be able to sell more i5 hardware, because this differentiation makes it more appealing than alternatives. In other words, I do not think that IBM can charge a lot on the hardware side for i5 capacity dedicated to mirroring applications in logical partitions. In fact, I don’t think that IBM can charge a dime for this hardware specifically. It is sitting there right now, in these i5 boxes, and with i5 customers already being asked to pay a serious premium (as I have pointed out in many articles, the latest of which being “How i5s Stack Up to Alternatives, Revisited”) just for a basic machine for online transaction processing. This is true whether or not i5 customers use 5250 green-screen processing capacity. IBM has, in effect, already charged a premium for the i5. What I want to do, since IBM can not or will not drop the prices on the i5s further than it already has, is to justify the high price of the i5. By giving something away for free, IBM can possibly boost shipments into new accounts that see the value of high availability software functionality but can’t get permission to double up on their hardware acquisitions.

The way the software would be integrated is simple (in theory). When you buy an i5 server, you would be told that this shadow capacity has been activated to create a logical partition for mirroring your applications. You would then be presented with the option of loading the software from the six core high availability partners in the iSeries market (DataMirror, iTera, Lakeview Technology, Maximum Availability, and Trader’s) to make use of that inherent i5 high availability functionality.

If these high availability vendors created a low-cost version of their software for this purpose, the penetration rate among i5 buyers might be very high. I am not, by the way, suggesting that customers be forced to buy the software from one of these vendors. It is still an option, but one that IBM encourages by adding the basic functionality into the box and including it in the price of the i5 iron. IBM and the vendors will have to work together to integrate the software into i5/OS, to come up with the correct sales-and-support approach for this integrated solution. But if they did this, they might all see significant increases in their software sales.

Big customers that want geographically distributed machines could buy mirrored systems or one of the special iSeries or i5 high availability editions, as do now. There is no way to simplify this acquisition, and the high availability editions go a long way toward cushioning the economic blow of acquiring secondary OS/400 servers for the purpose of setting up mirrored systems. Now it is time to give the same benefits to the smaller OS/400 shops, which need high availability just as much as the largest enterprises.