The advent of cloud computing has demonstrated how to use automation, virtualization and standardized machine images to drastically cut the time and effort required to provision new computing instances. Forward-thinking enterprise IT leaders are taking their cue from such examples and have begun implementing their own internal islands of 'cloud computing.'
A really impressive example was reported last week at the US Department of Defense. The newly launched Rapid Access Computing Environment (RACE) is a portal into a shared, virtualized computing infrastructure that allows military staff to provision new server instances in a matter of hours, rather than having to wait days or weeks before they can get started on a project. "We need to have the ability to develop and deploy applications within the timeline of the military decision cycle," says the project's leader, which I suppose is a sanitized version of the more robust language you'd hear on that topic from the troops on the ground.
As well as saving time (and lives, perhaps) the project will also save 'hundreds of millions', he believes. It's a clear demonstration of the enormous benefits available merely by applying technologies and principles such as virtualization and automated deployment to the provision of computing resources.
But is it really cloud computing, I wonder? Certainly, it uses many useful attributes of cloud computing, and it adopts the as-a-service model of delivering resources on demand in a flexible, elastic model. But it's clearly also a private implementation, cut off from the public cloud as a matter (I presume) of national security.
So while I'd happily define it as computing-as-a-service, borrowing many features from cloud computing, it will suffer from being cut off from the shared, collaborative environment of the public cloud. The infrastructure won't benefit from collective scrutiny by many different types of enterprise; it won't be able to freely tap into third-party resources available on the public Internet; it's unlikely to stay as up-to-date with the latest technologies as more public cloud infrastructures.
Maybe those are trade-offs that are worth making in return for ensuring the US military's computing projects are kept isolated from intrusion and other threats on the public Internet. But there are functional, cost and innovation implications that have to be recognised. So long as those implications are fully weighed and acknowledged, that's fine. I suspect, though, that most organisations embarking on their own privately hosted cloud projects are so overjoyed at the immediate benefits compared to what went on before that they never stop to consider what they may be giving up in the longer term by taking the privately hosted route.
Yes, but they also avoid being on a public, multi-tenant cloud that may also be hosting spambots such that the whole site is blocked. As well as avoiding DDOS attacks against a public site that sees nothing wrong internally and so takes many hours to respond.
Overall, this argument seems silly to me in the extreme ... they can (and in fact do) make full use open source (which does "benefit from collective scrutiny by many different types of enterprise" and is "able to freely tap into third-party resources"), etc.
Additionally they can have additional policies in place around H/A, BC/DR, multi-tier architectures where a back-end data base may need more resources than an XL config, and actually use *better* technology than many public clouds (ie. many only use 100Mb ethernet instead of 1GBe or even 10Gbe, more redundancy on servers such as dual PSUs, extra network or HBA connections, etc).
Just because it is public and done at huge scale does not mean that it uses the latest and greatest technologies ... in fact, the public providers are specifically incentivized to use the cheapest stuff for the longest time since it raises their margins.
I guess I just don't follow your thinking on this topic at all.
Thanks