Last Redshift redux (hopefully): Couldn't salesforce.com forget the hardware and use Amazon's EC2?

Last week, when I interviewed Sun's Peder Ulander (there's text, video, and audio -- take your pick) about the idea of redshift computing (a Sun theory that all the world's servers will eventually give way to just five or so massively scalable systems), he talked about how Sun's formula for being the muscle behind one or more of those systems wouldn't just be to have the best hardware in terms of scalability, performance, reliability, power consumption, etc., but that it would also involve the provision of world class software services.

After giving that some thought, I wondered aloud (via blog) whether, by the time that five computer "utility" arrives (if it arrives), if infrastructure software (a.k.a. "plumbing") of the sort that Sun specializes in might be less interesting to the primary customers of that utility. In other words, why bundle plumbing software with the hardware when so many of the providers' ground-breaking "utilities" would rather make of the hardware what they want? Google is one example. Salesforce.com is another. If you ask me, the plumbing appears to be taking a back seat to the business value. And, while it's just a theory of mine, it's a mission for others. Salesforce.com platform evangelist Peter Coffee wrote me to say that if Sun is the muscle behind one of those systems, salesforce.com will be the muscle behind two others (leaving only two left for, well, fill in the blank).

Technically speaking, those two salesforce "systems" could also be Sun systems. Salesforce would only need to choose Sun for its bare metal. But, despite Sun's epiphany about the direction the server population is heading (it probably won't be five, but Sun is probably right that it will be a fraction of what it is today), the company's gear is already half-way out the door at salesforce.com: the one company that's the poster child for the Software-as-a-Service (SaaS) movement. According to salesforce.com CEO Marc Benioff, he prefers Linux on Dell.

But then it occurred to me, why not take that one step further. If the salesforce.com platform is already moving to commodity plumbing (software and hardware) and SaaS providers have a preference for bare metal, why not enhance that poster-child status by taking the next natural step towards that five system, redshifted world? Why not ditch the hardware altogether and run all of salesforce.com on something like Amazon's Elastic Computing Cloud (EC2)? The same goes for Google.

EC2, for those of you not familiar with it, basically provides Intel bare-metal in on-demand fashion. Via Amazon's Web services APIs, you can launch, provision and shut down the Intel equivalent of a 1.7 Ghz x86 processor-based system with 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth.

According to the EC2 Getting Started Guide, "Currently Fedora Core 3 and 4 systems based on the Linux 2.6 kernel are explicitly supported, although any Linux distribution which runs on this kernel version should work." So, while Ec2 isn't exactly a bare metal option (in other words, other server operating systems like Windows and Solaris aren't supported), you still get to load your own image onto the equivalent of an Intel box.

Unlike with traditional server hosting that typically requires a one year contract with a hosting company, with EC2, you only pay 10 cents per hour per "CPU" for as long as you need it (even if you do need it for a year straight, the cost compared to typical server hosting yields a dramatic savings) .

The same utility computing model is available from Sun in the form of its Sun Grid Compute Utility (I'll call it SGCU). But, while recognizing that these two birds of a feather are still a bit like apples and oranges, there are big differences.

For starters, much the same way Ulander sees Sun's bundled software services as one of the differentiating features that will secure Sun one or more spots in the so-called top 5 systems of a redshifted world, SGCU is not available as bare metal the way EC2 is. Based on AMD's Opeteron chip, SGCU is in-fact an Intel-like utility. However, for customers interested in using the SGCU, there's imaging to do. The SGCU already runs on Solaris 10 and all customers have to do is throw a workload at it.

But, as a SaaS poster child, salesforce.com's vote for Linux over it's on-the-way-out Solaris is writing on the wall that Sun should probably take note of. At the very least, Sun should probably consider how to make the SGCU available with other Intel/AMD-compatible operating systems (or offer a bare metal option the way Amazon runs EC2).

Another big difference between EC2 and the SGCU is positioning. Sun markets the SGCU as a utility that you'd use for a short-term high-intensity compute job; one that you might not have the local capacity to run in a reasonable amount of time; and one for which it makes no sense to buy that capacity since it would sit idle most of the time (in other words, an underutilized waste of money). EC2 is available for the same type of jobs and offers the same, on-demand scalability. But, it's far less turnkey. For example, the SGCU is stocked with a catalog of high-performance computing applications (for simulation, 3D rendering, etc.) at which you can throw relevant data sets and users don't have to worry about how to make those applications scale. Provided those applications conform to Sun's requirements (runs on the x64-based version of Solaris 10, scripted to run on Sun's N1 Grid engine, etc.), the applications should scale without requiring user intervention.

Whereas customers don't have to worry about how to scale the SGCU infrastructure in order to turn a workload around in the fastest amount of time, running scaled apps on EC2 is far less turnkey. Yes, to scale some application with the muscle it needs, you can fire up and provision as many Intel boxes as you need through EC2's Web services APIs. But you're basically on your own when it comes to loading applications across that "cluster" or "grid" and getting them to scale properly. Back to the bare metal analogy, it's a lot more like running your own Intel servers on your own premises. What you make of them is up to you.

Finally, perhaps the biggest and most tangible difference is their per hour cost. For starters, both utilities have a base cost but the chances of some additional fees being involved are pretty good. With EC2 for example, you'll probably end up with some fees associated with Amazon's S3 service (where your system images get stored). There are also additional fees if there's any data transfer to and from your "servers" with destinations outside of the EC2 service (eg: if one of your Intel boxes is a public facing Web server). Likewise, with the SGCU, there could be additional fees. To the extent that many users of it will be submitting a dataset to one of the applications in the SGCU catalog, the providers of those applications are free to charge for their use.

At its base, Amazon's EC2 costs 10 cents per CPU per hour. At $1 per CPU hour, the SGCU cost 10 times as much. Sun's Web site provides sample calculations of how this works. for example, it says:

For each job the user submits and runs, the user's Sun Grid CPU usage is aggregated and then rounded up to the nearest whole hour. For example, if your job used 1000 CPUs for one minute, it would be aggregated as 1000 CPU minutes or 16.67 CPU hours. The software rounds this up to 17 hours and the job would be billed as US $17.

For those randomly-run high performance compute jobs that are easily tackled by a ready-to-scale application in the SGCU catalog, the SGCU is probably the most convenient solution (sidebar: if you have your own existing Linux app, you can also recompile it for x64 Solaris 10 and load it into the SGCU). That convenience however has its price. Meanwhile, for SaaS outfits like salesforce.com, Google and others (the more likely candidates to be involved with those final five systems in a redshifted world) that prefer to start with bare metal and deal with the scalability problem on their own, the bundled software vision that Sun thinks will make the difference seems misaligned with the direction that those outfits are taking.

Whether that means a company like salesforce.com would divorce its software infrastructure from its own hardware infrastructure and run it on something like Amazon's EC2 is a completely different story. There's only so much destiny the bigtime SaaS-providers like salesforce, Google, and others are probably willing to outsource. Even with the right SLAs in place, the mission critical nature of many SaaS-provided applications probably means that such outsourcing is something their General Counsels' offices aren't quite ready for. Yet.