The Tyranny of the Small
by
Recently, the Itanium Solutions Alliance released an upbeat report about adoption of the Itanium, which lags behind SPARC and Power in the enterprise server market. With the Oracle acquisition of Sun, many wonder what the future holds for SPARC. IBM has recently upped their rewards to $4,000 a CPU for customers trading in SPARC hardware to take advantage of this uncertainty. The irony is that all this hubbub and fighting feels like re-arranging deck chairs as the iceberg of x86 performance slices a gaping hole into the side of the USS Big Iron.
Why would you need SPARC, Power, or Itanium based systems anyway? First there are customers that bought SPARC, Itanium, PA Risc, Alpha, or Power systems in the past and need to stay on the platform. If you’re company that spent millions building, installing and configuring systems, it’s often cheaper to stay put. HP has both PA Risc and Alpha migrations to Itanium systems, for example. Sometimes, you’re completely wedded to an architecture that you find yourself running old software on emulators. The other big reason is the big application, usually a huge database instance, that is part of a business intelligence or data warehouse project. This, in itself, is becoming an endangered beast.
It’s no longer true that you inherently need big iron to run big systems. Google’s obvious example aside, modern software is built with horizontal scalability in mind. For example, Oracle has a clustering option called RAC that allows you to build a database from a cluster of smaller machines. Tools like Rails build their scaling strategy on many small boxes behind load balancers. Java clustering tools support deployment on one App server, which then propagates to other servers, all behind a load balancer. Web servers with PHP can hide behind a hardware load-balancer to act as if it were one insanely capable web server. This is also made possible because of protocols like HTTP, or are built like HTTP, and can take advantage of statelessness, proxies, and caching.
Welcome to the tyranny of the small. You can build an enterprise architecture that scales by adding more off the shelf computing power as your needs grow. The lowly x86, with it’s 30 year old legacy going back to 16 bits, is cheap and it’s fast enough. Combined with storage pricing falling through the floor, (a terabyte can be had on a single cheap disk) and the world for the single big server gets smaller and smaller. It doesn’t help big iron that we’re bumping up against some hard physics that makes single processor (or core) performance improvements harder to achieve. In fact, inside of computers, cores are added to improve performance instead of relying on CPU speed. The performance gap between x86 and “high end” processors narrows or reverses on a core to core basis.
That’s not to say the market for single, large servers is gone. There will always be applications that run better on a single large system, and many existing applications built before the Web was a twinkle in Tim Brenners-Lee’s eye. The mainframe ain’t going nowhere. That market, however, is not where a lot of though energy and money is being diverted. There are some interesting systems, like the Sun’s Cool Threads servers. Overall, however, you can’t beat all the money AMD and Intel are putting into x86 chip design. Nor can you really fight against the basic nature of the web, which likes horizontal scalability thanks to technologies like reverse proxies and statelessness. Even desktop client-server applications are relying on web-based protocols (REST or WS-*) which favor a horizontally scalable backend.
That’s why, with our hosted Radiant service I’m not worried about scaling. I’m worried about other things, but not about scaling. I don’t have illusions that there won’t be challenges, but I have embraced the web and how the web scales best. I don’t have to sink tens of thousands of dollars for a build-out for possible future customers. The commodity parts I need to use can be shipped within 24 hours from most vendors. I only buy what I need to service my customers. I don’t spend money on unused infrastructure. In many ways what the cloud promises is already here. In fact, the problem we have today is not that servers are too small, but rather, how do we split up the servers we do have so that we can ensure we’re getting the most out of the existing infrastructure? That’s a topic for another article, though.
Up Next: What is Cloud? by
Previously: Apple Is Not Not Enterprise Ready by