Is Marriage to Unix the Answer to Enterprise Linux?

G. Weiss
GartnerGroup

10 October 2000

In some, but not all, cases, Linux applications can benefit under the watchful eye of Unix.


Core Topic: Unix and Midrange Executive and Deployment Issues ~ Hardware & Operating Systems

Key Issue: How will users acquire, manage and dispose of Unix and midrange assets and know they have the best deal?
 

Some in the Linux community resent being closely allied to Unix, claiming Linux can hold its own. However, many key Unix vendors are beginning to declare a future in which Unix and Linux coexist. By running Linux application binaries on Unix as the host OS, vendors want to extend the life of Unix as an enterprise mission-critical environment while capitalizing on the increasing momentum of Linux applications development. We believe that users should seriously consider the "hybrid" Unix/Linux deployment model but exercise caution on how and when it makes sense (see Note 1). The other alternative is to limit Linux only to front-end Web-serving applications and run the mission-critical database and transaction processing on back-end servers on Unix or other more scalable OSs.

Note 1

Linux on Unix: Pros and Cons

Pros:

1.     Developers can leverage multiple platforms if support for application binaries exists.

2.     It offers the best of both worlds: Unix for scalable, mission-critical applications, plus new applications from a large Linux applications development pool.

3.     The transition enables a gradual Unix migration to Linux as Linux is proven in mission-critical enterprise applications.

4.     It allows in-house skills to be retained with centralized management from Unix.

5.     It enables applications to be readily ported and tested on multiple platforms when the anticipated Linux standards are published.

6.     It fits well into a multitiered application environment.

Cons:

1.     The Linux OS's potential TCO and customization benefits may be lost.

2.     Client/server applications in ERP, SCM, BI and others remain wedded to Unix and Windows.

3.     Vendor service and support models increase in complexity and may be uneven.

4.     It may not run all binaries, especially those with Linux-specific idiosyncrasies and unsupported drivers.

5.     Vendor commitments and road maps, along with frequent releases of different Linux distributions, may increase user and ISV confusion.

6.     Performance penalties may result from using an emulator such as lxrun.

7.     Not all Linux binaries may benefit from the Unix host's functionality.

8.     It still requires a partition for the Linux file system and libraries on the host.

9.     ISVs must test and validate applications on another platform.

Many users, especially high-level managers, are still skeptical of deploying Linux in mission-critical applications. The current Linux kernel version does not scale well. High availability is still in the early stages of development. Enterprise applications are scarce, and backup and recovery solutions are beckoning. The decision to substitute Linux for legacy environments will require re-evaluation of skills, development projects, service contracts, service-level agreements, internal help desk operations and partnering. To avoid or ease such a transition, a Linux-Unix affinity strategy may be advisable. The objective is to develop on inexpensive and assorted Linux platforms, and deploy to enterprise-robust Unix. Leading Unix vendors, such as Sun Microsystems, Hewlett-Packard and IBM, see this as a win-win approach for themselves at the high and low ends of the market (see Note 2). As they rush to support native Linux on Intel servers in a high-volume play, they can also extend the interest in high-end Unix by supporting runtime Linux on Unix back ends. Thus, should Linux scale to encroach on midrange and high-end Unix, vendors can be in a position to offer both a native Linux implementation (such as McKinley generation IA-64 systems) and continued support for their Unix servers (on RISC or IA-64).

Note 2

Vendor Linux and Unix Affinity Strategies

Sun: lxrun with Solaris 7 ("roll your own").

Caldera/SCO: lxrun and Linux Kernel Personality module integrated into UnixWare v.7 (beta).

IBM: Linux API compatibility within AIX with common set of applications development tools and utilities across AIX and Linux (in beta, as part of Project Monterey); NUMA-Q Dynix/ptx will support Linux binaries (1H01).

Hewlett-Packard: Linux API support on HP-UX (1H01); ABI support on IA-64 (1H01).

Dell Computer: Linux only as a native OS for Dell servers (no Unix supported).

Compaq Computer: No stated affinity strategy (ProLiant supports Caldera/SCO UnixWare).

Recommendations: Users should categorize applications by their affinity to OS environments: for example, infrastructure placements and high-volume, low-cost deployments should favor the Linux native implementation. Many traditional client/server applications for ERP, SCM and CRM will not appear from ISVs on production-ready Linux for 18 to 24 months. However, where Linux "plug-in" applications and Web servers add Web features and functions to legacy applications, enterprises should consider hosting these applications (e.g., e-commerce suites) on the Unix server. Unix hosting should be favored when it is important to have centralized management and a highly scalable environment. However, users must beware that any time multiple applications run on a single server, a performance impact could result. For optimum performance, Linux applications must be written directly to the Linux file system structures, library interfaces (glibc) and system drivers.

Note 3

ABI vs. API Compatibility

Differences exist in degrees of compatibility such that an application developed on the development platform may or may not run on a targeted platform.

ABI compatibility: Applications developed under one OS and platform (e.g., Linux on Intel) run unchanged as binaries on a target platform and OS (e.g., a Unix variant on Intel). The developer maintains one source code for all binaries. The development and target platforms have instruction set compatibility, and the target platform's host OS provides a full set of services to the re-hosted application.

API compatibility: Applications are developed to a set of programming interfaces (e.g., compiler, drivers, network) but, due to hardware and architectural differences, must be recompiled for the target platform, which must support the same APIs. If some APIs and services are not supported (e.g., peripherals, network, client and other interfaces) by the target platform, applications re-compiled to the target platform may fail to run.

Acronym Key

ABI     Application binary interface

API     Application programming interface

BI     Business intelligence

CRM     Customer relationship management

DBMS     Database management system

ERP     Enterprise resource planning

HA     High availability

ISV     Independent software vendor

OS     Operating system

RISC     Reduced instruction set computer

SCM     Supply chain management

SCO     The Santa Cruz Operation

TCO     Total cost of ownership

Bottom Line: The affinity strategy should require the vendor to create contract extensions on its Unix to include the installation and support of the Linux application under Unix, including availability guarantees and software maintenance. Compatibility should be validated and users should attempt to download a number of open-source applications as a verification test (see Note 3). The vendor should offer an option to migrate the Linux applications from the Unix environment to a separate Linux server as and when desired. The vendor should be able to demonstrate system management features such as HA/failover, backup and recovery, volume management and DBMS support from the host Unix system. Users who wish to migrate over time from a weaker Unix OS should use the affinity strategy selectively as a means of making such a transition and carefully evaluate the next version of the Linux kernel, v.2.4, which will have many more enterprise features (see Research Note T-12-0563).

Entire contents (C) 2000 by Gartner Group, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner Group disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner Group shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice. Please read the guidelines and policies for GartnerGroup copyrighted materials. Privacy statement.