IT Management

Expanding a bit more on the topic from my last column (April/May), the surprising introduction of z/VM as a strategic element of the z10 announcement opens a great deal of discussion on the impact of Linux as both an application enabler and as a way to approach a more appliance-oriented way of thinking about system deployment. What I mean by appliance is this: a complete system—operating system, patches, and application—all rolled into a single, deployable container, and deployed as a single object—all batteries included.

The application enabler part of the Linux discussion is pretty easy to see in the growing number of commercial and non-commercial applications packages that are being ported from other environments such as Solaris and AIX to Linux on System z. The availability of a system that has common Application Program Interfaces (APIs) and interfaces on commodity and System z hardware provides a stable and compelling argument for a real “write-once, compile anywhere” application (a promise that, so far, Java hasn’t really delivered on very well—someday it might be instructive to ask your applications people how many Java implementations they actually support. The answer may surprise you.). The 800-pound gorilla enterprise applications such as SAP and Oracle are good examples, but we also see applications written for the LAMP (Linux, Apache, MySQL, PHP) software stack moving up the food chain to the bigger iron, gaining sophistication and polish as they appeal to more complex problems.

I think it’s the other approach—appliances—that probably have more mileage in the longer term. If we approach the idea of a total replacement from a vendor for an application, separating code from data by design, we gain some very interesting advantages from a support and maintenance perspective. First, the idea of taking a complex application out of the box and having it immediately minimally functional (can’t be perfect, but we can make educated guesses about good configuration) is a winner from a usability standpoint. Most big package implementations fail not because the software is badly written, but in the implementation—assembly of many pieces from multiple vendors using new techniques and skills that all have to work right the first time or the inertia of not generating gratuitous change will set in. An appliance is pre-integrated, with all the patches and service applied by someone who intimately understands both the problem and the process.

Second, the basic design principle of “never modify vendor stuff ” is becoming more important as IT staffs shrink or age. The “component replacement” culture of the Windows world—if it doesn’t work, upgrade parts until it does—is both pervasive and well-understood by the less skilled. Packaging in an appliance format—often a Linux guest with pre-installed software—is calculated to produce both easier deployments and a “live demo” version that often can be used directly from the install media for testing or (in some rare cases) for real production use.

By putting together a unified, tested whole that’s the “application appliance,” a software vendor or developer can attack the development cost by basing the code on Linux, and also manage support costs—you always know exactly what operating system and patch levels are present in a customer system, and total replacement is less tedious than inventing (and operating) a formal patch process for the code.

Now, this does imply that application designers (this means you, IBM …) must be more disciplined about separating IBM code from operating system code, and both kinds of code from data. Most enterprise apps are surprisingly sloppy about this, which can be a problem with appliance deployment—you end up with bits of data in your code and vice versa—not a good scenario for total replacement service—but with patience and thought, these things can be worked out.

So where’s the link to Linux? In our case, the combination of a general-purpose operating system such as Linux into the appliance approach lets a vendor create a complete virtual machine that’s closer to “ready to work” than ever before. The cost of the additional operating system software is negligible, and you can test and support both application and operating system as one, particularly if you think of it as a starter system image (the starter system that Sine Nomine created for Novell is a good example) that one can grow from. I think we’ll see more of this type of thing in the near future, and it’s a good trend.