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."
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.
Now, let's get prepared to rebut any Microsoft officials whenever they talk about the common "Total Cost of Ownership" as far as Linux is concerned.
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.
Well, there is a backup Army, and it's you.
No, you are the front lines army. The backup army was the reason you were paying the annual fees. Without those annual fees, there is no backup army. i.e. If you can't get it right, there's no one else to come in and fix it for you.
Take a tweak which gains a 1% performance gain, multiply that against 4000 machines, and it's quite an advantage.
That's something of a straw man argument. If 3 Sun machines and 10 LinTel boxes have the same Flop capacity, then a 1% increase in either one will add up to the same increase in computing power. The key difference is that there are only three Sun machines to update.
There isn't a vendor in the world that can totally support their infrastructure, so Google does it themselves.
That doesn't mean that there couldn't be. Google made their choice to go with a large number of decentralized systems. It works for them and it works well. But they have to do everything internally *because* of that decision. Had they gone the EBay route, they would be able to get that backup army, but then they would pay for the priveledge.
Javascript + Nintendo DSi = DSiCade
I'm not sure how to respond to the "no-brainer" label. My development team just migrated our company's production software development platform from a network of aging HP-UX machines (which served us quite well in their day, don't get me wrong) to a Linux network. The new development tools run 20 times faster (that's the actual figure, not hyperbole), our experience over the past two years is that the Linux network is much more reliable, and the server hardware is simply an increment onto their existing Windows server lease and support contracts, not a whole separate costly item like the HP's were. I don't know the exact dollar figure it'll save them every year, but I know it's major. For us, the developers, it was definitely a no-brainer.
But management fought us kicking and screaming every step of the way. They weren't really sure what they wanted, they just knew they didn't really want Linux. After repeated patient, detailed explanations of the cost savings and productivity benefits were met with skepticism and outright disbelief, we finally had to create an extensive Six Sigma analysis of the business and technical case for our choice. I can't fault them for wanting that, but once they got it, they seemed rather sorry they'd asked, because it supported every word we'd already said. For them, it was far from a no-brainer.
Now, how they were using their brains, I cannot say. To us, it looked like a child screaming about getting a vital vaccination. But despite their grumbling and repeated shots of the stink-eye our way, they now have their new system in place and it works great. The other developers love what they see.
Of course, our whole team is being laid off and all development is moving to India, but that's beside the point. (That was in the works long before we were even condsidering the migration. Honest!)