Server Wars, part 1
You can start at the ground floor and look to either an Intel solution or perhaps one that's bit more RISC-qu?
Let's be honest, the "death match" between RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) processors has been going on for over a decade and, despite some media play to one side or the other, it doesn't look like it will conclude any time soon.
CISC processors are inherently more flexible while RISC designs can be more cost effective for specific applications. The real difference in the two can be found in the dedication of your system integrator, not with the hardware developer.
Take Intel's line of CISC processors, for example. If you talk to Intel you'll find out everything you ever wanted know about Intel CPUs, but there's a frustrating disconnect between the product and its productivity.
Intel knows the hardware--but it's IBM, Compaq, HP, Unisys, and others who are taking that hardware to task. It's not an easy job. Despite having some input, these companies still must design around Intel's vision of what the processor's architecture should be.
That can be a costly venture, and it's no accident that the leading companies are those with not only a strong dedication but also the deepest pockets.
In contrast, HP's PA-RISC chips, IBM's Power4, and Sun's UltraSparc processors are integrated into systems sold by those companies themselves. They have not only an intimate knowledge of the CPU's architecture--something which can be acquired of any processor given time and opportunity--but also the ability to have direct input into the processor's design, coaxing its development in directions that are defined by its use, and not vice versa.
A CISC CPU, however, aligns you with mainstream software, while RISC solutions may marginalize your opportunity to employ anything but equally specialized programming.
Then again, the software that powers your server is no less a topic of obfuscation than is the hardware. Wintel platforms naturally have Windows in common and will--at least in theory if not necessarily always in practice--run all Windows software.
There is no discounting the tremendous advantage that this implies for the availability of many off-the-shelf applications, not to mention the greater probability of finding a semi-custom application that fits your needs.
Such TCO friendliness is somewhat offset by a lack of flexibility for situations that don't exactly meet the cookie cutter stamp of the software design. Changes, when possible, are often quite expensive, and changes to Windows itself are not an option.
Lintel (Linux) and Unitel (Unix) platforms are more forgiving. In fact, while IBM maintains a Center for Microsoft Technologies, it leverages that by making available both Unix and Linux options.
Linux is perhaps the most malleable operating environment around but, as a relative Johnny-come-lately, its application base is small in comparison to that of Windows and Unix environments, and practically invites the additional expense of less amortized or custom work.
To be fair, however, if you need a 15-pound sledge hammer, buying a 3-pound model because it's less expensive, requires less square footage, and is easier to maintain may keep your TCO down, but it won't get the job done. In the end, it's not the brand name of your components or software that's significant.
What's more important is the integration of those components and software to meet the requirements of the tasks you need to perform.
But wait, there's more...In Part 2 we'll look at scalability and feature issues, and perhaps even debunk the partial myth of TCO.
Choices should make your life easier, but that's not necessarily the case when it comes to selecting server architectures. In fact, the mists surrounding the available options can lead to a job-jarring crater in your bottom line if you choose incorrectly.
You can start at the ground floor and look to either an Intel solution or perhaps one that's bit more RISC-qué.
Let's be honest, the "death match" between RISC (Reduced Instruction Set Computing) and CISC (Complex Instruction Set Computing) processors has been going on for over a decade and, despite some media play to one side or the other, it doesn't look like it will conclude any time soon.
CISC processors are inherently more flexible while RISC designs can be more cost effective for specific applications. The real difference in the two can be found in the dedication of your system integrator, not with the hardware developer.
Take Intel's line of CISC processors, for example. If you talk to Intel you'll find out everything you ever wanted know about Intel CPUs, but there's a frustrating disconnect between the product and its productivity.
Intel knows the hardware--but it's IBM, Compaq, HP, Unisys, and others who are taking that hardware to task. It's not an easy job. Despite having some input, these companies still must design around Intel's vision of what the processor's architecture should be.
That can be a costly venture, and it's no accident that the leading companies are those with not only a strong dedication but also the deepest pockets.
In contrast, HP's PA-RISC chips, IBM's Power4, and Sun's UltraSparc processors are integrated into systems sold by those companies themselves. They have not only an intimate knowledge of the CPU's architecture--something which can be acquired of any processor given time and opportunity--but also the ability to have direct input into the processor's design, coaxing its development in directions that are defined by its use, and not vice versa.
A CISC CPU, however, aligns you with mainstream software, while RISC solutions may marginalize your opportunity to employ anything but equally specialized programming.
Then again, the software that powers your server is no less a topic of obfuscation than is the hardware. Wintel platforms naturally have Windows in common and will--at least in theory if not necessarily always in practice--run all Windows software.
There is no discounting the tremendous advantage that this implies for the availability of many off-the-shelf applications, not to mention the greater probability of finding a semi-custom application that fits your needs.
Such TCO friendliness is somewhat offset by a lack of flexibility for situations that don't exactly meet the cookie cutter stamp of the software design. Changes, when possible, are often quite expensive, and changes to Windows itself are not an option.
Lintel (Linux) and Unitel (Unix) platforms are more forgiving. In fact, while IBM maintains a Center for Microsoft Technologies, it leverages that by making available both Unix and Linux options.
Linux is perhaps the most malleable operating environment around but, as a relative Johnny-come-lately, its application base is small in comparison to that of Windows and Unix environments, and practically invites the additional expense of less amortized or custom work.
To be fair, however, if you need a 15-pound sledge hammer, buying a 3-pound model because it's less expensive, requires less square footage, and is easier to maintain may keep your TCO down, but it won't get the job done. In the end, it's not the brand name of your components or software that's significant.
What's more important is the integration of those components and software to meet the requirements of the tasks you need to perform.
But wait, there's more...In Part 2 we'll look at scalability and feature issues, and perhaps even debunk the partial myth of TCO.
Bill O'Brien is a freelance writer and frequent contributor to CNET and ZDNet. He writes Tech Update's weekly hardware column.