|HOME||PUBLIC LIBRARY||ANOTHER PERSPECTIVE||INFOPERSPECTIVES||CONTACT|
It is hardly surprising that IBM's mainframe group wants its customers to do all their computing on System z boxes. Big Blue has been pitching this idea to customers since the days of the System/360, which was a truly general-purpose computer. But that was a long time ago, before X86 and RISC servers captured what might have remained the mainframe's turf. Now IBM seems worried that its mainframe is cornered, that it can either get more work back into its big box or suffer as its flagship systems become hospices for legacy applications.
The main reason customers have installed alternative servers to supplement their mainframes is cost. IBM has tried to make its big iron more economical. With every generation is improves the price/performance of its large systems. But IBM does not seem to have closed the value gap separating its System z products from other kinds of servers. Consequently, year after year mainframes get a smaller slice of the total server hardware market. For IBM, this slowing in hardware growth (and, for the past six months, an actual decline rather than lower growth) has not prevented increases in related revenue from software and services. Still, this outcome is not satisfactory. And, with a new generation of mainframes in the wings, the one that will use Power chips that are closely related to those in those in IBM's System p servers, this looks like the time for IBM to make a big move.
New processor chips are only one of three heavy weapons in IBM's technology arsenal, and they might turn out to be the least important of the three for now. Big Blue's two other big guns are virtualization and the use of specialty processing engines. Specialty processing engines enable IBM to break up workloads into categories that have different software charges (or no software charges at all). Virtualization lets IBM create relatively independent processing environments of different shapes and sizes; this sizing allows users to better manage system resources and it also allows a mainframe to manage and meter software resources for which charges are related to usage.
Virtualization and specialty engines can be used together, but so far IBM has not brought all the fruits of its virtualization technology into play for all specialty engines. Generally, specialty engines must be used in units that correspond to physical engines, even if these units are subsequently chopped using virtualization software. In the case of the IFL engine that runs Linux, IBM supports z/VM as a way to slice up Linux capacity but it does not yet allow a customer to assign a fraction of a physical engine to use as an IFL while the rest of that engine is used for another purpose, or not at all.
The picture can be complicated and confusing. But it is easier to understand if you view mainframes the way IBM's marketing executives do. What they see is a system that encounters quite a lot of sales resistance from customers who feel it is overpriced, mainly because mainframe software costs so much. To make matters more complicated, a lot of the software users think is too costly comes from third parties, not from IBM. So any pricing scheme IBM might offer to offset user resistance might not have much of an impact unless independent software vendors also participate.
IBM has told industry analysts that customers asked what issues inhibit mainframe growth cite software costs nearly two-thirds of the time. They mainly blame third party software fees, but about a fifth of these users say IBM's charges are a sticking point. Another ten percent of so of mainframe users say the nature of the third party software they use imposes limitations on growth; users may not want to upgrade to newer versions or it may be that for many packages the ISVs have simply frozen development, so newer, more powerful versions just don't exist.
By comparison, even though mainframe equipment is expensive, only about 15 percent of users IBM studied say that hardware costs are high enough to inhibit growth.
What IBM has not done, to put their finding in perspective, is provide comparable data about growth plans and growth inhibitors from users of other platforms, including X86 servers, Unix boxes, and midrange systems like the IBM System i.
Still, it is clear that IBM has been concerned about the high costs of mainframe computing, and that is why it introduced specialty engines in the first place and why it prices them in a way that it hopes will encourage growth.
Currently, IBM charges $95,000 per engine on z9BC systems and $125,000 per engine on z9 EC machines. Once a user buys a specialty engine, it survives an upgrade. So if customer bought one for a z900 and then moved to a z990 and later a z9 EC, the price of the first engine is the only price the user would have paid. IBM moves the engine, or more accurately turns on an equivalent engine, whenever a customer upgrades. Because successive generations have faster engines for standard and specialty use, the user ends up getting more specialty MIPS with the upgrade at no additional cost.
Even so, it's not as simple as this headline. For instance, IBM insists that users of a zAAP Java engine have at least one standard engine for each zAAP. With each generation the standard engine is potentially faster (depending on a customers choice of governing microcode), potentially more costly than its predecessor, and potentially the basis of higher software charges even when more work is offloaded to the zAAP. A similar arrangement governs the zIIP database engine. There is no similar restriction on the use of IFL Linux engines.
In addition to various configuration rules, IBM sometimes insists that users of specialty engines run current or recent versions of related software. For example, a customer that wants to offload some database work to a zIIP has to be running DB2 9 or DB2 8 with a load of patches.
IBM describes virtualization as a two-flavor scheme, with hardware partitioning at the foundation and z/VM software partition a layer or two above the iron. That description is simple and clear but without some specific knowledge and experimentation is it not always obvious what kind of virtualization is best in every situation. Setting up and then managing virtual environments can be complicated. A mainframe user that sees virtualization as a way to unplug a zillion small servers and their associated snake pit of network apparatus will find that this assessment is absolutely correct . . . but it does not guarantee that a substitute in the form of some mainframe IFLs, z/VM and related components is any easier to set up and run. Chances are the customer will in the end come out ahead, but there may be alternatives to a one-box mainframe solution that are similar to the IFL and z/VM model but even easier and less costly to build and maintain.
While IBM is moving its mainframe virtualization and specialty engine technologies ahead, the company's other server groups are not sitting around just watching all this. IBM has teams of developers working on virtualization and related technologies for its p, i, and x lines, too.
Today the System p can be as powerful as a mainframe for many tasks and in some cases it is possible to make it even faster than the biggest big iron. With partitioning and virtualization that are steadily improving (even if they are not yet quite up to the levels IBM offers on mainframes), lower costs for equivalent processing power, and better adherence to many standards that affect such applications as Internet communications and commerce, a System p complex sitting in a glass house with a mainframe might be a more cost-effect solution than a mainframe alone. The System p might be a less costly database engine than a mainframe, even a mainframe with a zIIP, and it might also be a lot easier to manage. Similarly, even though there is no special engine deal on a p box that's similar to the one IBM offers for an IFL, the list price of a p engine might well be a lot less than that of an equivalent IFL. Moreover, for shops that don't need a whole IFL, a Linux partition on a System p might provide more than enough power for, say, email, at a lower cost.
A similar situation exists when a mainframe is used in conjunction with a large X86 or X64 machine, one that, like the System p, can support virtualization even if it does not yet have all the bells and whistles a mainframe can provide.
IBM's mainframe marketing folk might prefer users who see only two extreme choices - the mainframe with special engines versus a mainframe and a huge farm of X86 or Sun or AIX boxes - but the two box alternative, which lives in an attractive middle ground, might be the best choice for some customers.
IBM can change all the rules as it rolls out its next generation of System z hardware, but it is unlikely to do anything too radical at first. IBM will initially want to bring out new machinery under a set of rules that are familiar to customers. IBM does not want to introduce the z6 or z10 whatever it calls its next round of mainframes in a way that leads to a big delay in sales as users puzzle out a vastly different set of economic considerations. But once the new iron is out the door, it would not be surprising to discover that IBM can adjust the pricing and the technology of its specialty engines and its virtualization schemes to yield a significantly more attractive total package.
Still, users should not expect too much. The whole idea behind the specialty engines and virtualization is about finding a way for IBM to make the mainframe more attractive for new applications, but keep it very costly (and profitable) for legacy workloads that customers cannot easily move or abandon. IBM wants to keep its mainframe users on big iron and off alternatives, but it is not about to give much of a break in matters where it holds all the aces.
And if customers with System p, System x, and System i boxes think they are in for any special breaks as IBM enhances Power 6 chips and related virtualization technologies, they ought to think again. They are not more likely to find IBM generous than are mainframe shops. The only thing in their favor is that the competition is stiffer outside the mainframe arena. That means all IBM customers can sometimes get a break, but they shouldn't thank IBM. They should thank H-P or Sun or Dell, because it's their pressure that makes IBM more likely to bend in the customer's favor.
Nonetheless, whatever the real reason IBM decides to offer improved technologies and more favorable pricing, there is no question that Big Blue is going to be pushing pretty hard to get its next generation of large systems off to a quick start.
— Hesh Wiener February 2008