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."
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.
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."
"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.