News

Windows: Coming to a Mainframe Near You?

• By Stephen Swoyer
• 09/08/2009

IBM likes to promote its System z mainframe as the virtualization platform par excellence, and with good reason. Not only is System z home to z/VM, the most mature hypervisor on the market, but thanks to its proprietary hardware innards and best-in-class software portfolio, it boasts what is arguably the market's most granular and manageable virtualization solution.

It doesn't, however, offer the industry's most comprehensive virtualization solution. For one thing, Big Blue supports only a few hand-picked operating environments (chiefly VSE and Linux) in addition to /OS. Conspicuously missing is support for Microsoft's Windows platform, to say nothing of other enterprise-grade operating systems such as OpenSolaris or Mac OS.

This is in spite of the fact that IBM long ago made its peace with Windows. It's an aggressive Windows OEM, supports Windows -- admittedly, not running in a virtual context -- on its System i platforms and, of course, is an ambitious player in the commodity (x64) virtualization segment. In fact, IBM's System z virtualization story is arguably inferior to that of rival Hewlett-Packard, which supports (or plans to support) many of its platforms -- HP-UX, Tru64 Unix and OpenVMS -- running in a virtual context, along with Linux and Windows. Rival Unisys lets users run Windows, Unix or Linux on top of its ES7000 or ClearPath servers, along with (in the latter case) both flavors of its proprietary mainframe operating system software.

IBM officials tend to demur when asked about the likelihood of running Windows in conjunction with z/VM. In an interview from late last year, for example, Karl Freund, vice-president of strategy and marketing for System z with IBM, said that "very few if any" mainframe customers had expressed a desire "to do that."

Freund didn't flatly rule out a Windows-on-System-z strategy, but instead positioned IBM's System x platforms, running in tandem with System z, as ideal virtual hosts for most Windows workloads. "We already have a solution to offer [mainframe customers] who want to do something like [virtualize their Windows assets]," said Freund, who, toeing IBM's oft-repeated line, likes to position System z as more of a hub -- and less of a one-size-fits-all monolith -- from which to manage and secure an enterprise-wide virtualization effort.

Vince Re, chief mainframe technologist with software giant CA Inc., likewise downplays the desirability of a Windows-on-System z strategy. He stressed that CA doesn't speak for IBM but contends that "the vast majority of [mainframe] customers just aren't interested in that." If anything, Re suggested, the ball is in Microsoft's court: Redmond can't champion the cause of Windows in the datacenter while continuing at the same time to ignore the mainframe, he maintained.

Re, like IBM's Freund, rejected the claim that the lack of a z/Windows offering somehow calls into question System z's virtualization bona-fides. "You also have to consider the cost [of running Windows workloads on the mainframe]. Linux [on System z] is mature, it's proven. You've got 10 years of development behind it, so it's at a point where [workloads] can run efficiently [on System z]," he said, adding, "Windows would be starting from scratch."

It is possible to run Windows applications, if not Windows itself, on top of a number of Unix-like operating systems, including Linux. There's the long-standing WINE Is Not an Emulator (WINE) Project that, after 15 years of development, finally shipped as a version 1.0 release last June. WINE supports most Linux distributions and all three flavors of BSD, in addition to OpenSolaris and Mac OS (via Darwine).

That's the good news. The bad news is that WINE doesn't do emulation, much less virtualization. Because most Windows applications are written for 32- or 64-bit x86 chips, they would first have to be recompiled (for System z CMOS) in order to run in WINE on top of z/Linux. There's another requisite: WINE is by no means a turnkey solution. Windows programs often have to be tweaked or custom-configured to properly run in its context.

What's more, WINE is more of a workstation-oriented offering. Past sponsors have included Corel, steward of the once-dominant WordPerfect Office productivity suite, and Google. It is, therefore, a less-than-ideal tool for workload consolidation on an enterprise scale -- at least for the kinds of adopters who would undertake to do as much on top of System z.

All Isn't Lost
There are alternatives to WINE, such as Mantissa's z/Vos which was announced just six months ago. It runs in z/VM and purports to let mainframe shops run any of several different operating environments (including Windows) on top of z/VM. z/Vos made a big splash at Winter SHARE and, once it ships, could very well amount to the best thing for Big Iron shops since zLinux itself.

Absent z/Vos, there's another compelling solution. Industry veteran Wayne Kernochan, a principal with consultancy Infostructure Associates, highlights Mono, an open source project first conceived by the former Ximian Inc., to create a version of Microsoft's .NET framework capable of running atop Linux, several flavors of BSD, Mac OS and Windows itself. Six years ago, Novell acquired Ximian and became Mono's steward; then, just months later, Novell acquired German Linux pioneer SuSE.

That chain of events paved the way for the Mono of today, which runs in z/Linux.

More precisely, Kernochan explained, Novell markets a Mono Extension for its SuSE Linux Enterprise Edition (SLES) 11, which runs on System z. This combination -- namely, of SLES 11 and Novell's Mono Extension -- makes it possible for SuSE shops to run .NET applications on top of System z. And that, Kernochan maintains, makes for an intriguing proposition.

Unlike IBM's Freund and CA's Re, Kernochan isn't afraid to take IBM to task for its disinclination to accommodate -- much less support, in a virtual context -- Windows workloads on the mainframe.

"How significant is this [the development of Mantissa's z/Vos and the maturation of Novell's Mono]? Well, since the advent of Linux on the mainframe...lack of support for Windows has been a glaring gap in IBM's ability to support workloads on the mainframe," he wrote. "The technical difficulties involved have, according to IBM, prevented System z from giving users a general-case way to support Windows workloads."

Kernochan isn't persuaded by this, however. After all, he noted, where there's a will -- or, more precisely, where there's a profit motive -- there's a way. In this regard, Kernochan points to Big Blue's own TCO estimates, which he said demonstrate that "putting 20 or more Windows apps on the z10 tends to pay off more rapidly and with more cost savings than putting the same number of Unix or Linux apps on the mainframe." He sees other potential benefits, too.

"[T]he improvements in app robustness and security from moving Windows applications to the mainframe, although less than before Microsoft improved these in Windows Server 2003 and 2008, are still typically more substantial than those from moving a comparable Linux application," he said.

The upshot, Kernochan said, is that most of the traditional barriers to running Windows applications on top of System z have ceased to exist. Via Novell's Mono Extension, it is possible to actually run .NET-native applications in the context of SLES-on-System z; there's also the possibility of doing full-blown Windows emulation on top of System z, via Mantissa's z/Vos.

The irony, of course, is that mainframe shops have gone from having no viable options to having two for running their Windows applications on System z.

"At first glance, Mantissa seems like the best option: all Windows apps can simply move right over to mainframe virtual machines running Linux, with no change," Kernochan said, stressing, however, that Mantissa is still relatively new and that "some of these [Windows] apps are highly tuned for a fat-client environment and do not yet run on VMWare/.NET, requiring extensive modifications for virtualization scale-out and performance tuning."

What's more, Kernochan added, Windows 7 is also imminent, which means that z/Vos -- and a host of Windows applications -- will have to be tweaked to support the new OS. "Careful tire-kicking and experience may reveal that these problems are not significant; but until then, Mantissa will be the best bet only for specific I-need-to-move-everything cases."

For his part, Kernochan favors the Mono approach, pointing to the availability of several .NET-to-mainframe customer testimonials from Novell. "Linux apps over .NET are reasonably well-understood, so the likelihood of performance, security or robustness problems is low. Novell, for one, has experience in user portation via Mono, so the services to support moving these apps to the mainframe are already available," he said.

"Enterprise ASP.NET apps are more likely to depend solely on .NET, so in many cases the contents of a Windows server can simply be moved without (or with minimal and straightforward) code changes."

Just how easy is it to move .NET applications from Windows to System z? Kernochan doesn't sugarcoat the matter, saying that between 25 to 50 percent of .NET applications could be ported with minor tweaking or refactoring, a figure that, when viewed in context, he sees as encouraging. "Porting Windows apps to the mainframe is now much more doable," he said, adding that such a strategy "also constitutes a good idea right now because it can save major amounts of TCO and improve Windows-app robustness and security."

The takeaway, Kernochan concluded, is that Windows-on-System z is going to happen -- regardless of whether IBM or Microsoft want it. "The action item for large enterprises with cost concerns and larger numbers of Windows apps, therefore, is to identify those apps that are completely or almost totally dependent on .NET, choose a tool to port those apps to Linux on the mainframe, choose a target Linux on the mainframe, and then port the apps."