Close Window

Print Story

Linux as a Server Operating System in the Enterprise

You may have heard statements such as Linux is inexpensive, reduces TCO and dependency on vendors, and is easy to maintain, from promoters of Linux in the enterprise. But, for those who still haven't made the jump - this article discusses implementation hurdles, cost of implementation, and a readiness checklist. If you're part of a non-technology company, this article is a must-read.

Linux has matured from the days when Linus Torvalds created the first version. Numerous for-profit and not-for-profit organizations have customized it to their needs, deployed it on appliances, and sold modified versions. Novell and Red Hat have developed significant revenue streams from Linux.

Linux has been a panacea for technology start-ups. But, outside e-commerce companies that deploy hundreds of images of the same platform, it hasn't been the breadwinner for technology product companies that are trying to sell their wares to corporations.

But, now let's get to the mature enterprise that's dependent on numerous packaged applications (SAP, Siebel, etc.), software products (Oracle, WebLogic, etc.). Each of these software providers typically has a different reference platform and it's typically not Linux. These software products are also not available on "your" flavor of Linux on the day the new software version or upgrade is generally available (GA). What does this mean to you? Either you have to wait six months for the vendor to make the product available or convince the vendor to provide you a port on "your" flavor of Linux.

I've been part of implementations where software vendors have tried to pass on ports on Red Hat Linux for SUSE Linux (or vice versa). Usually, the engineers installing/configuring the software have to waste hundreds of hours troubleshooting before they realize that the software provided was built on a different flavor of Linux.

Where To Use Linux and How To Introduce It
•  Clearly define where you want to use Linux. Start with systems that are least risky.
•  Start off on greenfield projects that have high transaction volumes and require a very large installation of hardware, such as a cluster of more than 25 servers.
•  Ensure every vendor that you purchase software from for the project has a common denominator in terms of flavor of Linux (Red Hat, SUSE, etc.). Select the common denominator as you choice of vendor-supported Linux.
•  Make sure that every software vendor supports the selected flavor as a Tier 1 platform, i.e., it's one of the operating systems on which they release the product when they GA an upgraded version, patch, etc.
•  Evaluate the hardware that you'll use to implement Linux. Make sure that the CPU selected is supported by the Linux vendor. Make sure the hardware vendor has certified your flavor of Linux as being able to run on the hardware.
•  Consider the following:
- How is high availability going to be supported?
- If SAN connectivity is needed, how is it going to be established?
- How are you going to create a certified image of the software stack and how you are going to replicate the stack on new servers?
•  Do a complete proof-of-concept of the stack - hardware, OS, clustering software, operations software (Openview, BMC Patrol agents), applications to be implemented on the platform.
•  Do stress or load tests on the proof-of-concept stack.
•  Do a TCO analysis for the stack. Remember maintenance is the biggest cost. Compare it to an alternate (such as a platform you use now). You could just do it on the software/hardware maintenance cost.

Are you ready and still convinced that you have to go the Linux route for your project?

Here are other things necessary for a successful implementation.
•  Recruit skilled Linux engineers who have exposure to the software stack. Make sure they know the flavor you've selected.
•  The less dependencies the better, i.e., fewer vendors to depend on.
•  Make sure you buy support for the Linux flavor you use. It's not worth using the Internet for support.
•  Get every vendor together at least every other week for the duration of the project to ensure implementation issues are solved in a team setting. Sometimes you may have to be the mediator for the vendors to talk to each other!
•  Create an operational support structure and processes that will resolve incidents in a timely manner.

Some Tips
•  It doesn't make sense to blindly use Linux everywhere. If you go this route, you're setting yourself up for failure.
•  Don't bite off more than you can chew!
•  Don't believe vendor promises - they never come true. Get written commitments.
•  Typical cost of ownership is significantly higher in the first few years!
•  Remember bleeding edge is not good for an enterprise whose sole purpose is something else (other than technology!).

Measuring Success
•  The TCO of a Linux-based stack should be less than the TCO of an alternate OS-based stack over a three-year period. You should get at least a 25% cost saving. If not, it isn't worth your effort.
•  The availability of applications on the Linux stack versus the availability of a similar system on an alternate OS-based stack for a consistent period.
•  You've been able to keep your system upgraded and patched and vendor support has been similar to what you'd get for software on other operating systems.

Projects/Migrations That May Backfire
If you have an application written solely in C/C++ hosted on a non-Linux environment such as HP-UX or AIX, and it uses vendor libraries; you may be in for an unpleasant surprise during migration. Don't underestimate these kinds of migrations. The unknowns are many - the compiler you typically use will not be available in the Linux you plan to implement.

If a vendor supports only one flavor of Linux, and it's not the one you've selected, be cautious. Even if you force the vendor to support your flavor of Linux, the level of support isn't going to be the same.

Customized applications written on top of application servers are a very unusual case. The application server vendor may support a flavor of Linux but the application software vendor may not. This is usually because of system calls they may make. Get everyone to support their product on the flavor of Linux you're going to implement.

Implementing Linux in your data center isn't a non-event. It's an important milestone that has to be carefully orchestrated, its value measured and then implemented. If done well, you could derive significant cost savings for some expensive systems. Large e-commerce Web sites have been popular success stories. Using Linux for the appropriate application in a well-planned implementation will drive you to success.

© 2008 SYS-CON Media Inc.