What Good Is Native .NET On Power?

November 16, 2015 Timothy Prickett Morgan

As many of you know, most of us at IT Jungle have advocated for some form of support for the Windows Server platform on Power-based systems since the advent of the PowerPC Alliance nearly 25 years ago. Back then, there really wasn’t a Windows Server platform at all, in fact, and it was not until that alliance that two things became clear: Microsoft had aspirations as a system software provider, and it intended to start down that road by making its Windows desktop operating system available on Power, Alpha, MIPS, and X86 processors.

Except for a few months in the 1990s when IBM shipped its own PCs based on Power chips instead of X86s, this ideal was never fulfilled. In the mid-1990s, the rise of Windows NT Server along with the rise of Windows 95 on the desktop and the commercialization of the Internet helped give Microsoft more money than it could count, and so the efforts to keep Windows on non-X86 platforms started to wane. Sure, Itanium chips supported Windows Server for a number of years, but eventually it all came back to the steady state of Windows Server on Intel Xeon iron. The Opteron chips from Advanced Micro Devices still exist and they run Windows Server, but the current Opterons have not been updated in several years and the next one, code-named “Zen,” is not expected until 2017. And while the Windows kernel can technically run on both Power and ARM processors–Windows ran on Xbox machines based on custom Power chips for years and Windows also runs on ARM chips used in Microsoft’s own Surface tablets–that is a far cry (but a first step) from delivering a Windows Server implementation for Power or ARM chips.

We have contemplated all kinds of methods to more closely couple Windows Server, which is by far the dominant “other” platform at IBM i shops, and IBM has even done a few of them, such as creating X86-based Windows Server add-in cards that worked like the I/O coprocessors of days gone by, except that they ran Windows Server instead of chunks of OS/400 itself. These cards were never quite cheap enough or powerful enough to be universally useful and deployed, but they did offer customers the chance to have Windows and OS/400 share storage and work across a high speed bus. IBM had a number of different options to allow it to run Windows Server application in emulation–QuickTransit is just one of them, but IBM basically bought this tech and sat on it because it was too dangerous to let out of the bag. The QuickTransit emulator could also allow Unix machines to run mainframe workloads, so that was not going to be allowed.

There were lots of different opportunities, and most of them were not capitalized on fully by IBM because it was conflicted about driving Windows Server sales–even on its own System x X86 machines–instead of driving sales of Power and mainframe platforms. IBM is no longer conflicted about its desires, and this comes about a year after Microsoft has open sourced the .NET framework that underpins its own Windows applications as well as those of its many hundreds of thousands of partners. In last week’s issue of The Four Hundred, my colleague, Dan Burger, had a chat with Tim Rowe, IBM i business architect for application development and systems management at Big Blue, about the possibilities of bringing a native .NET runtime to the IBM i. Rowe basically said IBM was considering it, but that the open source .NET implementation from Microsoft was too raw.

This is the nature of open source, but it is also the nature of some homegrown software, too. To my way of thinking, .NET could have been added–and I would argue should have been added–a long time ago, and IBM did not have to wait until Microsoft’s opened up its code. As we pointed out years ago, the Mono open source project provided a .NET runtime that was compatible with the one Microsoft embeds in Windows Server, and if IBM had embraced Mono and perhaps embedded it within IBM i using the PASE AIX runtime (which is how the TCP/IP networking and Java virtual machine stacks are brought into IBM i, and it is also how Node.js, Python, Ruby, and PHP are all made “native” on IBM i), then Microsoft might have been compelled to open source .NET a long time ago and the technology would be mature (whatever that means) or at least Mono could be replaced with Microsoft’s own .NET runtime.

Having said all of that, what does native .NET for IBM i get the companies that currently run Windows Server applications and IBM i applications? Having a single development environment for both platforms would be interesting, to be sure, but how many companies are really coding their own .NET applications that also have IBM i applications? As far as I know, the bulk of IBM i shops that have embraced Windows Server–and it is north of 85 percent of IBM i shops based on very old data from Big Blue–are running compiled applications from Microsoft such as SQL Server, Exchange Server, SharePoint Server, and so on. Now, if bringing .NET native to IBM i means that Microsoft will then be able to compile these applications of its own to run on Power-based machines without having to do a full system port, that would be great. But that is not what it means. What native .NET means is that customer applications coded in a .NET language and speaking to the iron through a .NET framework will be able to run in this .NET environment.

While this is great, and wonderful for very large shops with a mix of IBM i and Windows applications, it doesn’t do what IBM wants, which is get more applications and databases running on Power Systems machines. This is the issue. As IBM learned during the OS/2 Warp fiasco, where it was trying to emulate Windows inside of its own OS/2 operating system to have a larger addressable market, the emulated code was clunky and offered poor response time compared to the actual Windows, and IBM was always playing catch up with its support. This experience, no doubt, is why IBM has avoided running Windows Server in emulation mode. (Microsoft might have sued the pants off of IBM had it done so, too.) What Microsoft wants is for .NET to span its own server platform and various client devices and become a common runtime for all of them, and that means supporting Linux and iOS on the clients; the company doesn’t seem to care about supporting alternate server platforms with .NET, but given that it has open sourced .NET, there is nothing to stop anyone from doing it.

Let’s say that native .NET comes to IBM i. Will anyone use it now? Is there demand for Windows-style programming and languages, or is there demand for actual Windows Server that in turn runs all kinds of applications? I am not sure what the answer is, and if there is hesitancy from IBM, it is because maybe it is not sure, either.

In fact, I think IBM might be right that in the future, there will be more demand for Linux than Windows. Yes, Windows applications will stick around for decades. We all, perhaps more than others, realize this because Windows is now the dominant proprietary and legacy platform in the low-end, midrange, and parts of the enterprise, and databases and applications take a very long time to change. Decades, sometimes.

Let me give you an example. Very roughly speaking, if you look at X86 server shipments for the past decade, about 75 percent have been for Windows and about 25 percent for Linux. Together, these platforms drive 99 percent of overall server shipments, but only about 80 percent of the revenues for systems. So there are a tiny amount of non-X86 machines driving a few billion dollars a quarter in sales. Not tens of billions, as Unix, mainframe, and proprietary minicomputers did a decade ago. But Linux is by far the preferred platform for supercomputing, and has been for years. For certain kinds of analytics workloads (often ones that depend on Java like Hadoop and Spark) Linux is also preferred. In financial institutions, all of the modeling and trading systems run on Linux. All new switching environments are being based on Linux. Here’s an even funnier one: I was talking to Mark Russinovich, chief technology officer for Microsoft’s Azure cloud, a few weeks back, a year ago, about one in five instances running on the Azure public cloud, which is created from Windows Server, and it rose in the past year to be one in four; for those customers who are managing VMs on Azure using sophisticated tools, it is one out of two or three already, and it could stabilize at half of instances or keep going the other way.

So maybe what we need more than anything is native Power Linux that is functionally equivalent to X86 Linux and delivers better price/performance. This, of course, is what IBM is actually trying to do.

To play devil’s advocate, so much software is running atop Windows Server that it is hard to ignore that as a possible target to boost sales of Power Systems. If IBM can demonstrate equivalent price and better performance than Xeon servers, socket for socket, running Linux workloads like Hadoop and Spark analytics or Postgres or Redis databases, then maybe it can run Windows-based server apps better, too. What I know for sure is that native .NET could not hurt, just like adding Java, PHP, Perl, Python, Ruby, and Node.js have not. I also know that IBM should have done all of this–little endian support for Linux in Power chips, equivalent pricing to X86 iron, and wide language and runtime support–a decade or more ago. The Power Systems platform has to have things at the same time as X86, when they are raw and maturing. Saying that the technology is not mature enough misses the point. Experimentation by real users is how the technology gets mature. And putting such things on the platform shows that IBM is serious to the new breed of programmers who will be running the show when the current top dogs retire.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search