|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Thursday, 12 April 2001||Author: Brenden Bixler|
|Published to: daily_feature/Linux.com Feature Story||Page: 1/1 - [Std View]|
A Linux Success Story
Preaching Linux to the Enterprise is much more difficult than convincing a friend to switch distributions because your friend already understands the power of Linux. The following is a detailed account of how one dot.com business leveraged the flexibility and freedom of Linux to pursue a non-proprietary solution that would support a large, transactional-based online marketplace.
My employer, Company X, decided to incorporate a series of site enhancements based on customer suggestions that would enable us to secure our position as a leading online marketplace for cargo negotiation services. The existing site had been constructed as a proprietary Java application running on Sun Solaris servers and an Oracle database. We were already sold on the portability merits of Java, but wanted to re-write our application using standards-based Java code that included our new functionality. Furthermore, we needed to convert the existing site to a transactional-based website that integrated with Verisign payment libraries.
Therefore, our reliance on Java and Oracle led to the natural assumption that Sun hardware would fulfill our needs. We purchased an expensive Sun Enterprise 250 server and I assumed the role of system administrator. Our environment consisted of the Apache web server for normal page requests, and the Tomcat servlet engine to serve the JSP / Servlet pages.
I was very surprised to learn that the GCC and other helpful GNU tools that I had come to rely upon were not readily accessible on the Solaris platform. Any Linux distribution I had run in the past had included them by default, while Solaris required a separate install of each tool after the OS was installed. In fact, a basic Solaris installation required a great deal of post-configuration to yield a capable operating system.
Actual performance of the environment was disappointing, given the cost of the hardware, and despite existing time allocated towards the Sun equipment, the decision was made to migrate the application to the Linux platform and to return the Sun box. Pricey tech support calls and unforgiving Sparc hardware further contributed to the transition. We selected Red Hat as our distribution based on its support options, acceptance in the enterprise, and its familiarity by most of the techs that we were working with.
Moving to Linux couldn't have been easier. We initially selected a development environment on a Cobalt RaQ3 running Red Hat 6.2. The machine was simple to administer, and it ran flawlessly. However, we eventually abandoned this machine because it was underpowered. Linux afforded us the flexibility and cost effectiveness of the PC architecture, so we elected to build a custom machine that could ultimately be co-located.
Once the latest machine had been installed in the rack, it was again my duty to configure the environment. The video card on this custom server was integrated on the motherboard and therefore created problems trying to run the X-server on Red Hat 6.2. We decided to stay with Red Hat and I re-installed the server with Red Hat 7. This time, the install completed successfully and I was left to update the server with all the necessary patches and bug fixes - simplified with RPM package management - a Red Hat calling card.
Performance gains had been significant when we originally moved to the RaQ3, but nothing like those the custom server afforded. We were blown away with its speed! It even installed some niceties by default such as OpenSSH, enabling both local and national developers to work together securely.
The environment was quickly reproduced and we were well on our way, or so we thought. We discovered shortly after installation that Oracle does not officially support Red Hat 7, which explained our talented DBA's inability to configure Oracle on the server. After speaking with a technical representative from Oracle who confirmed this problem, we were left to implement a solution discovered by an Australian developer. Anyone who has been in the Linux community can speak of the incredible support and the general goodwill that is found in newsgroup or website postings. The Australian's excellent and free diagnosis and subsequent solution enabled us to install older Red Hat 6.2 libraries that would run simultaneously with existing system libraries to support Oracle on Red Hat 7.
To date we've yet to encounter a problem with this workaround and are certainly in debt to him, as well as all the Linux developers who've provided us with the free software that runs our application. In a roundabout way, we've discovered that Linux is the most flexible, reliable, scalable and cost-effective solution for our company.
Brenden Bixler is the president of Innogress, Inc. He is an independent e-business consultant and Linux enthusiast of 2 years. Innogress offers custom Internet solutions to diverse international and domestic clientele. Please see http://www.innogress.com for more information.