By kemer on May 08, 2013
The year is 1971. Apollo 14 lands on the Moon. The Ed Sullivan Show airs its final episode. IBM invents the 8-inch floppy disk. The first e-mail is sent. Dirty Harry utters his most famous line: '...you've got to ask yourself one question: Do I feel lucky? Well, do ya, punk?' (image removed from blog)
Back then, we built from the ground-up because there was no other way. There are those who still think that is the way to build integrated systems.
What would it take to persuade you to build from pre-tested components? You are probably thinking, “But, I already do that!” No, I mean really big and meaningful components, the type that are going to cost money. Real money. It’s at that point when many a red-blooded engineer thinks, “I’ll bet that I can do it cheaper.” Trust me, you can’t.
You would think that the days of building the service infrastructures from the ground, up were long gone. But, there are plenty of excuses: “I need everything to work exactly my way, and nothing out there can do it…,” or “But, I could save a ton of money if I built a home-brew using free open source and distributed it across a bunch of white boxes…” I know: it is so tempting, because it is such an interesting challenge and you don’t have to wrestle with the Suits to get the budget. But, when the numbers get big, too much is at risk.
The Industry has been moving in the direction of creating bigger components. Oracle’s decision to buy Sun was largely because we wanted to add hardware components to our mix. And, indeed we have: consider products like Oracle Exadata Database Machine and Oracle’s SPARC SuperCluster. Big. Powerful. Expensive. Face it: big problems need big solutions.
Our engineers recently tested how well this approach worked by simulating a large communications service provider. Is a simulation of 20-million GSM customers big enough? Step back for a second and consider just how much a glitch anywhere in such a system would ruin your day, if not your career.
Building Consolidation Efficiency into Operations Support Systems is a quick read aimed at you, and not the Suits. I think you will find several things of interest here. First of all, no matter how you plan to build your solution, you will want to test it first. Take a look and see how we approached the problem.
Secondly, we show how we would actually deploy such a solution. I think you might be surprised at how compact the solution can be. Back in 1971 (long before cell phones, of course!) you would build a datacenter that would fill an entire office building. Today, you can fit it into a rack:
Still think you can do it yourself? Well, do ya, punk?