Wagging the dogma

I’ll admit it — I’m one of IT’s most unapologetic Linux fans. If an application will run on Linux, I’ll run it on Linux. It’s not religious dedication for me as much as it just makes more sense in many cases. Its price-performance ratio on Intel hardware can’t be beat, the system administration skills required to run it are analogous to any proprietary Unix flavor, my favorite proprietary (Oracle) and open-source (mySQL) databases run on it, and vendor support for it is growing. The value proposition for Linux is so strong, I pitched it in a recent board meeting, and the guys on the business side “got it” immediately.

But this week I encountered a conundrum that was quite troubling to this Linux proponent. At InfoWorld, we’re running a processor-hungry application that is straining one of our old Sun Microsystems machines, an Ultra Enterprise 450 with dual 300MHz UltraSparc processors. We did some testing and discovered that the application would run much better on an available Intel machine with two 1.4GHz processors. The only catch was that this Intel machine would have to run Windows 2000, not Linux. After calming down our IT manager and systems administrator (both even bigger Linux fans than I), we decided to give it a go on Windows 2000.

For a shop that is virtually 100 percent Linux, this was an unusual decision. But it’s one that many of you might be facing, both specifically and generally. As proprietary Unix hardware and operating systems purchased a few years ago reach the end of their lifecycles, IT managers everywhere face a tough choice: Continue with the old approach (Sun) or leapfrog to running Linux on an Intel box?

Our situation is odd in that it illustrates another fact of life about real-world IT: Many IT managers are unable to make this decision freely. Although many vendors still support Solaris and Windows, they haven’t yet made the leap to Linux. In our case, the vendor had a Linux port that was just about to enter QA, but we chose Windows because it was officially supported (however we anxiously await the Linux port, honestly). I wouldn’t turn our company into the QA department for this vendor just to prove that the application would run well on Linux — that would be a waste of time.

At one of my earlier jobs, I worked in a staunchly Solaris shop, where we were evaluating high-throughput e-mail delivery systems. The vendor for the leading product recommended that we benchmark its solution on Windows NT and Solaris. We did, and NT consistently beat Solaris — for this particular application. After much hand-wringing, we decided to run the application on NT because it met these particular needs. I don’t think I’ve ever seen so much consternation within an IT department. Although we very much wanted Solaris to be faster, it just never came out that way. It was odd to see a group look so defeated after finding a better, faster solution.

When day-to-day IT decision-making is reduced to one’s dogma instead of careful analysis driven by business needs, the tail is wagging the dog. If you’re a JSP shop, sometimes it might make sense to use ASP. If you’re fully committed to C++, sometimes quickly building an application in Perl might do the trick. In our case, we would rather run Linux in the long term because it matches the rest of our environment — and therefore costs less for us to run — but when a key application’s availability is in question and Windows fits the bill, it would be foolish not to give Windows a whirl.