Slashdot Mirror


Linux From A CIO's Perspective

An anonymous reader writes "CIO.com has a story on Linux and OSS in the enterprise from the perspective of the CIO of Cendant Travel Distribution Services, Mickey Lutz. 'In the summer of 2003, Mickey Lutz did something that most CIOs, even today, would consider unthinkable: He moved a critical part of his IT infrastructure from the mainframe and Unix to Linux. For Lutz, the objections to Linux, regarding its technical robustness and lack of vendor support, had melted enough to justify the gamble.' His organization saved 90% in costs in so doing. Read on if you want to see how the top brass views OSS."

5 of 163 comments (clear)

  1. I'm reading through this and it's interesting. by Anonymous Coward · · Score: 5, Interesting
    There are two things I find really interesting here:
    1. Vendor support. OK, so if vendor support has gotten better, then which vendors does this CIO recommend? I don't see which ones he used in the article, maybe I just missed something.
    2. This quote
      "Open source is propelling us to adopt Java and a new way of programming," he says.
      Should be a bit of a cluebat for both Sun and the Open Source extremists. Java and Open Source can be extremely good for each other, it's just that both Sun and the Open Source community need to learn to cooperate on practical matters with those whose ideological goals differ... unfortunately it seems that neither Sun nor the Open Source community is extremely interested in realizing how much they could benefit from the other.
    1. Re:I'm reading through this and it's interesting. by thammoud · · Score: 4, Interesting

      Most companies (including us) that use the popular Linux/Java combination do so without caring about any Open Source ideolgies. The combination is simply outstanding.

  2. Cost breakdown by alvinrod · · Score: 5, Interesting
    Mainframe: $100 million

    Unix: $25 million

    Linux: $2.5 million

    These numbers were taken from a table in the article. Interestingly enough, the cost if something does break favors Linux as well. From the same table we get that the mainframe solution consists of 4 IBM mainframes, whereas Linux and Unix solutions require around 144 servers for Linux and 100 - 120 servers for Unix. If the hardware goes to hell it's so much easier to replace the single bad part than a mainframe.

    Hopefully, more people will begin a transition to open source solutions when they realize it can be successful.

  3. Re:Difficult, but big payoff by stefanlasiewski · · Score: 5, Interesting

    The issue is that you're working without a safety net. If things go really wrong, there's no backup army of specially trained techs to run in and fix things.

    Well, there is a backup Army, and it's you.

    Google can have a 4000-node Linux cluster because they have enough staff to maintain and optimize the system (Keep an eye on their job pages to get an idea).

    Google also has some highly specalized needs-- some machines only crunch data for the DB, other machines only serve webpages, etc. It's in their interest to optimize the Kernel, OS, Database & Web applications as much as possible. Take a tweak which gains a 1% performance gain, multiply that against 4000 machines, and it's quite an advantage.

    There isn't a vendor in the world that can totally support their infrastructure, so Google does it themselves.

    --
    "Can of worms? The can is open... the worms are everywhere."
  4. The main mistake is changing everything together by iabervon · · Score: 4, Interesting

    "In hindsight," says Lutz, "we shouldn't have tried to cut over to a new infrastructure at the same time we were deploying a new software application. It was too much at once."

    They found that their Linux servers couldn't support the new application they had deployed at the same time. That doesn't mean it's less capable than the mainframes they replaced: they didn't even try running the higher-load application against the mainframes.

    They should have first ported their servers to Linux on the mainframes, then switched them to Linux on clusters, then sent out new software that they could force back to the old behavior, then supported the new software in general.

    That way, they'd have been able to isolate the problems more easily (which really turned out to be that the new application generated extreme peak loads, and nothing to do with Linux per se, aside from that they managed to improve the Linux performance to deal with it) and keep things stable while they fixed the issues.