It seems simple: The recently released Mono Extension of Novell SUSE Linux Enterprise Server (SLES) 11 allows Microsoft...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Visual Studio users to generate SUSE Linux versions of their Windows applications that run on ASP.NET. So it's about Windows and Linux platform deployment -- except that it isn't. It is very possible that Mono Extension will be most useful for large enterprises looking to use cloud computing on mainframes. Confused?
Let's run through the logic. In recent years, IBM mainframes have specialized in delivering lower total cost of ownership (TCO) in large enterprises -- not to mention greater robustness and a better environmental footprint -- by consolidating Linux applications on the mainframe. Now enterprises are looking closely at the potential of cloud computing to deliver cost savings.
Cloud computing requires that users carve out groups of applications similar to service-oriented architecture (SOA) services, and virtualize them, making it possible to move the applications to large server farms run by providers such as Amazon EC2. In turn, these providers load-balance across super-scalable server farms and connect with the enterprises via the Web to deliver cost savings for each service moved out of the data center and "into the cloud."
Now, if you think about it, in an ideal world the answer would often be for cloud computing providers to choose mainframes as servers. These are super-scalable, run hundreds of apps per system, require less administration, have proven exceptional robustness and are proving their ability to deliver the major energy reductions that cloud sites will require in the next few years.
The major problem preventing this solution is that the mainframe is not well suited to support the services that cloud computing requires. That is, the mainframe doesn't handle some of these services. Over the last three years, the mainframe has added software-supporting services and Web connectivity that is comparable to a Windows, Unix or Linux server. It has proven its ability to support mission- and business-critical distributed and Web Linux applications. The one application portfolio that the mainframe does not support effectively, as of yet, is Windows.
Think of it as the intersection of three parts of the market: the large-enterprise IT user, the cloud-computing vendor and the mainframe vendor. The large-enterprise IT user wants to move applications that promise exceptional cost savings if moved to the cloud -- and that means Windows, because Windows apps have relatively large administrative costs. To maximize profit, the cloud computing vendor wants the most cost-effective platform for its customers' apps -- and that platform is often the mainframe. The mainframe vendor wants to prevent the erosion of the market for mainframes in large enterprises by supporting workloads in the cloud -- the problem is that the mainframe doesn't support Windows.
Why mainframes lack support for Windows
According to IBM sources, it all starts with Big Endian and Little Endian (cue the usual jokes). "Endian" refers to whether a computer byte is assumed to go from the largest bit address downward (Big Endian) or from the smallest bit address upward (Little Endian). When operating systems were being written, mainframe hardware was Big Endian, while Microsoft required that Windows only run on Little Endian. Moreover, IBM's virtualization technologies, which include firmware, were also optimized around Big Endian. At one point, IBM figured out how to run Windows on z/OS. However, because IBM virtualization is hard-coded Big Endian, Windows could not be virtualized on the mainframe, and only one instance of Windows took up the entire mainframe. In today's cloud environments, running one Windows app on the mainframe is highly cost-ineffective.
Until recently, in order to move applications from Windows platforms to the mainframe (or, more typically, vice versa), users would go to a porting company -- such as Microfocus, Blue Phoenix or Servoy -- to port each app separately. Some apps are easier to port from z/OS to Windows than others. Those written in COBOL, in particular; applications that depend on CICS or DB2 are also fairly straightforward. By the same logic, Windows apps that mainly depend on DB2 or IBM middleware allow fairly easy porting from Windows to the mainframe. In the typical case, however, a company may seek to port hundreds of applications between Windows platforms and the mainframe, and the task can take a year at minimum -- or far longer.
Two things have changed the nature of the task over the last five years: first, the establishment of the mainframe as a viable Linux platform, and second, the rapprochement between Microsoft and Sun that has led to new ways to move Windows apps to Linux. For example, now, if an enterprise wishes to move Windows software to the mainframe, one way is to recompile the code as Java for the appropriate version of Linux (that is, one that runs on the mainframe; not all Linux versions run on the mainframe, and therefore not all Linux applications do either).
However, many Windows apps, especially "legacy" ones, require not only recompilation but also code modification to move to any version of Linux. These apps contain hard code for specific features of the Windows environment. So, while putting Linux on the mainframe speeds up porting, moving massive services from Wintel to the mainframe is still a daunting task.
This is why SLES 11 Mono Extension is such an important step forward. Mono is an open source .NET framework that runs across multiple platforms, including SLES on the mainframe. A large proportion of today's Windows apps (by some estimates, 50% or more) depend entirely on .NET. By providing a "dual compile" for Visual Studio-developed .NET-dependent apps to Windows and SLES 11, Mono Extension allows users to create identical versions of their Windows apps running on the mainframe, without the need for code change or conversion to a different language. And, of course, Novell is steadily building expertise in handling the cases where there are a few non-.NET Windows dependencies.
Implications for mainframes in the cloud
Let us suppose, then, that you wish to take advantage of a cloud provider's mainframe capabilities. Beyond Web-servicizing your existing applications so that they can be moved onto a cloud provider's Windows platforms, there are several additional steps you can take to allow the resulting services to run on all other platforms (i.e., Linux blades, Linux servers and mainframes).
- If appropriate, rewrite the code to invoke only .NET, and not the Windows operating system. This is unlikely to be necessary if the Windows code was written to operate on the Web. For most recently written apps, even if a rewrite is necessary, it will involve only a few points in the code.
- Recompile the services using Microsoft Visual Studio.
- Use SLES Mono Extension with Visual Studio to generate a mainframe Linux version and/or versions for other Mono-supported platforms.
- Pass all versions to the cloud provider, which can then run the app on the mainframe, a Windows server or a Linux server, and the user won't be able to tell the difference. If the app is run on the mainframe, it will join other Linux apps or app instances on hundreds of mainframe virtual machines.
Infostructure Associates conclusions Cloud computing is not the only possible application of SLES Mono Extension. Users performing server consolidation on their Linux apps should also be able to take advantage of Mono Extension to extend this consolidation to some Windows apps. Possible targets for both cloud computing and server consolidation are SQL Server server-side apps, email and data serving, which are frequent and important Windows uses that typically involve high-administrative-cost scaleout.
With some additional effort, most existing large-enterprise Windows applications that are not fully .NET-dependent may be made portable to the mainframe. There are a couple of obvious possibilities: "just enough emulation," in which components in Linux emulate just those Windows features that most non-.NET-dependent Windows apps use; and rewriting the apps to be fully .NET dependent. Over the next two years, I anticipate that both of these tasks will be better supported by Novell and other vendors, so moving Windows applications to the mainframe will become straightforward in most cases.
It is also possible that z/OS will start being used as the target for ports. Mantissa Software now has a beta product called z/VOS that emulates Windows over z/OS. The wary reception this idea has received from users suggests that moving Windows apps to Linux on the mainframe will usually be preferred.
The key takeaway for users about Novell SLES Mono Extension, however, should not be the remaining barriers to full movement of all Windows apps to the mainframe. Rather, it is the indication that ways are being found so that, whatever the future of cloud computing, the mainframe will be a valued platform for high-end enterprise computing -- including Windows-type workloads.
In preparation for that day, users should investigate Mono Extension for "targets of opportunity" and assess the portability of key enterprise applications. The result of the investigation is likely to be identification of significant cost savings that will make the effort pay off in TCO terms, and in increased software-portfolio flexibility.
ABOUT THE AUTHOR: Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures. Infostructure Associates aims to provide thought leadership and sound advice to vendors and users of information technology. This document is the result of Infostructure Associates-sponsored research. Infostructure Associates believes that its findings are objective and represent the best analysis available at the time of publication.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at firstname.lastname@example.org.