Linux to ponder on...

[Sweeper]

BIG IRON VS. LINUX

Posted July 5, 2002 01:01 PM Pacific Time

RECENTLY, I accompanied one of my colleagues on a trip
to visit two companies competing to provide back-end
services for InfoWorld. One of the companies has been
doing business with InfoWorld for several years, and
the other wants to win that business. I was brought
along to do some quick, technical due-diligence on
each. For the purposes of this discussion, I'll call
our current vendor Company A and the vendor wanting
our business Company B.

Doing a thorough "deep dive" analysis of the technology
at a partner company in a few hours is difficult, so
it was important to look for small details that
provide insight into the larger picture. At Company A,
I was struck by one detail in particular: While they
had made systems choices that provided stability for
their environment, they had taken an expensive "big
iron" approach -- a few big boxes running a
proprietary operating system on a proprietary
architecture. Company B was moving decidedly in the
other direction -- migrating to clusters of
inexpensive, Intel-based Linux servers to perform the
same tasks as Company A. From a technical and business
standpoint, I was already leaning toward Company B.

So why does this even matter? If Company A currently
provides the same service reliably, why would I want
to switch? On the surface, my leanings toward the
Linux-based solution might seem like a religious,
technology-driven choice more than a practical
business one. But in fact the business side of the
equation is more important in my thinking.

Admittedly, I consider myself a Linux fan from a
technology perspective, but my gut reaction to the two
companies' technology choices emanated from one key
issue: cost. It was no coincidence to me that Company
A (the big iron vendor) had a more expensive offering
and seemed less flexible on pricing while Company B
appeared to have some room to move. Without the
maintenance and expense of maintaining the big iron, I
thought, they could afford that flexibility.

With budgets tight at my own company, I am much less
willing to underwrite my partners' expensive
technology choices in my budget. Company B's move
towards Linux signals to me that their long-term
vision centers around offering a high-level quality of
service while keeping costs in the datacenter as low
as possible. This approach should increase their
profit margins and helps my bottom line.

A lot has been said about how the writing is on the
wall for the big iron vendors. Back in January,
Oracle's Larry Ellison said, "It will be several years
before the big machine dies, but inevitably the big
machine will die." Not as much has been written about
the viability of the companies themselves who are
still firmly committed to big iron solutions. If I
were the CTO of one of those companies, I would be
worried that my costs of delivering service to my
customers would eventually make it cost-prohibitive
for them to continue with my service. I would also be
concerned that each time I sent my six-figure annual
maintenance check to the big iron company, my
competitor would be using his cash to add more cheap
capacity to his growing Linux cluster.

**** At this point, I am simply astounded by companies that
have not seriously embraced Linux, especially small
and presumably nimble ones, such as Company A, with
applications that could be easily ported. With
financial services companies embracing Linux, not
considering Linux amounts to having your head in the
IT sand. More importantly, you just might be putting
your business at risk by alienating your customer base
with prohibitive costs.

Change your business now or be gone later.

Chad Dickerson is InfoWorld's CTO.

[justy]

Sweeper, real interesting thread. I'm so long out of the guts of this game its good to get an insight into the future.

What I will note is, that we'd be brought to similiar functions/demonstrations as these as hardware engineers. One of the key topics for me was, what happens when this goes wrong?
Then four steps later, what happens when this goes wrong, then four steps later................... and so on.

A cluster based system can survive a component breakdown ( a single full system ) with moderate disturbance. A main frame system only needs one ten cent capacitor in its power supply to fail, to cause major disruption. Total death in the interm.

To me, as long lost in the woods as I am, Cluster is the only solution. It was the only answer then, and will remain the only answer.

Glad to see that you guys are in tune.

All the best, Justy.

[caddmannq]

I read Chad Dickerson's column every week. It always makes sense to me.

The first company I ever worked for was centered on IBM "big iron". So was the second, and the third, and the fourth, and the fifth. The first, second, and third are all dried up and (except for one) gone. The fourth has finally started converting, and is severely struggling to hold it's dwindling market share. The fifth has converted completely, though somewhat late in the game, and is holding fast; but with much effort.

The place I work for now has never run a mainframe; though most of us started out with one somewhere else. We aren't tied to any expensive legacies, and that's a GOOD THING.

If one station crashes, we're up on a backup in seconds, or minutes at most. In eight years, we've never been completely "down", and no individual station has been down more than a day. Nobody has ever lost more than an hour's work, and rarely more than ten minutes under any circumstances.

In the big iron days, that would have been a true miracle. We never even came close.

[justy]

Hmmm.. I don't know if thats a backup to my speech or not, but the truth is:

If its all running sweet, then sweet.
If it decides to lie down, who or what is still awake?

That is the answer.

All the best, Justy.

P.S. cadd my perception is less in-tune with my appitude. I know your saying pretty much a similiar thing, but Its not translated that way.