I think VMWare PR did this to differentiate the new product, unaware of the implications.

And of course spooling up an EC2 instance to handle one-a-month reporting would be a great example. Also one where latency is not much of an issue. <s> And you bring up a lot of great things to watch out for. Thanks.

Hank

>>Here it is: http://www.rackspace.com/blog/?p=595 Funny part is, if you go a month earlier and read the Rackspace Cloud manager's blog, he's touting how great the cloud is.
>
>Thanks. I actually find it reassuring that he's a believer in the right tool for the right job philosophy, rather than being (merely) a rabid cloud promoter.
>
>Superficially it looks like GitHub is an organization with very specific needs, which are not (currently) achievable with generic cloud servers. Being very technically astute, and with a developer mindset, I can see why they'd want to do things their own way.
>
>That particular post doesn't touch on another major impediment to cloud adoption, namely security and trust issues. Some companies can't conceive of putting their sensitive data on servers at another company, where a rogue employee could access them. There is also a political angle - to give one example, some Canadian companies won't consider using any hosting by any American company, or any company that has any US bricks-and-mortar or server presence, because of the US Patriot Act.
>
>>A related story to this is the VMWare admission, in their promo materials for VSphere, that VMWare Server on its own is not appropriate for 'data intensive' applications, which is to say every application I've written with the except of a demos. The same issue threatens cloud virtualization, viz. http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/
>
>Well, I think if VMWare actually made a statement that broad, without qualifying exactly what they mean, they're doing themselves a disservice.
>
>Server consolidation via virtualization is a big win when the servers to be consolidated are lightly used, i.e. they are not persistently bottlenecked. "Data intensive" applications/servers tend to be bottlenecked - often I/O (usually disk), sometimes CPU.
>
>If you virtualize more apps or servers onto an already bottlenecked server, things can get much worse than the raw numbers might suggest. For example, suppose you have a (currently dedicated) SQL Server handling large database(s). It has lots of CPU and RAM, and has a fast connection to a high-performance SAN that has plenty of free space.
>
>Someone suggests you consolidate a Windows domain controller onto that machine. After all, its current CPU utilization is only about 10%, it will need only about 4GB of its 64GB RAM, and the SAN won't even notice the 50GB you'll generously provision for the DC. They fail to notice that all of the 64GB RAM are currently fully used, and that (despite the SAN) the server is I/O (disk)-bound.
>
>A Windows DC may not use much CPU or RAM, but it's fairly "chatty" with its disk subsystem, making lots of requests. If these requests effectively force the SAN I/O driver (or the SAN itself) to context switch or flush its cache(s), this can be hugely expensive to overall I/O throughput. It can make the usage pattern - and performance - look like random, rather than sequential, access. Observed performance of SQL Server could drop a lot.
>
>But, it might be a lot worse than that. The bare-metal SAN driver may include optimizations that work especially well with the interface card and SAN controller(s), and possibly even with SQL Server in particular. If there isn't a good equivalent paravirtualized driver for VMWare, VMWare might present the SAN to the guest VMs as a simple block device, and all those optimizations could be lost.
>
>The same sort of argument can be made for CPU-bound machines. Suppose you have a render cluster or farm and you're running CUDA apps on a bunch of nVidia GPUs. If the virtualization layer won't let your apps or OS talk directly to the GPUs (or even let you use CUDA at all), most, if not all, of the benefit will be lost.
>
>These examples use consolidation/virtualization onto a single physical server, but the same issues are present - probably even more so - in the cloud. As I see it, the issue isn't really "don't virtualize/cloud 'data intensive' apps" - rather, it's more like, "Don't add any more load onto an existing bottleneck".
>
>With that in mind, I can think of scenarios where a cloud could even help a currently bottlenecked application, if it can offer higher throughput than dedicated hardware. Suppose the above company with the example SQL Server machine really only needs that strong server because reports they run once a month would otherwise take too long. Most of the time, their server (and SAN) sits there underutilized. If instead, they contracted with a cloud provider to obtain tons of disk I/O once per month (maybe even more than they get with their current SAN), plus appropriate CPU and RAM, they could get their reports as fast, or faster, than before. The rest of the month, they could contract for much lower service levels.
>
>So, in the final analysis, will a given company see improvements in performance, availability or cost? As with everything else in computing, "it depends" :)
>
>>>Cloud services are still in their relative infancy. If the only problem is latency, that'll be fixed over time - Google already has it licked. Once South Korea-level service ( http://gigaom.com/2009/02/01/by-2012-koreans-will-get-a-gigabit-per-second-broadband-connection/ ) becomes relatively ubiquitous, a lot of other offerings will suddenly become "good enough".
>>>
>>>Have you got a link about GitHub's experiences/decision? I'd be interested in reading that.
>>>
>>>>Hi Al,
>>>>
>>>>when GitHub (a big open source repository using, of course, Git) was offered free access to the Rackspace Cloud, they turned it down, and asked for (and got) a managed server. Why? Because the latency for data access against a server in the cloud would hurt their user experience. There are a lot of similar commentaries on the Net if you go looking for them (which I did after reading about the GitHub experience).
>>>>
>>>>Hank