What's this "Cloud Computing" all about, really?
There's a lot of speculation (not to mention misconceptions) flying around about VMware's recent move towards the "Cloud". Critics believe it to be absolute rubbish, a step back to the age of the mainframe, warning us of the dangers of centralized data storage and the security/availability issues that might bring about. "Only your own PC is safe enough for your data." Proponents counter these arguments by quoting the numerous applications that people use that basically require no more than a dumb terminal anyway. For example, our readers wouldn't technically need a monster PC to read our articles and their emails; just a thin client with web access would suffice.
We believe these arguments, though undoubtedly relevant with regards to personal computing, largely miss the point of what the Cloud Computing movement is looking to achieve, and with the announcement of VMware's vSphere, we would like to take some time out to clarify just what Cloud Computing is all about. VMware's press release on this hits the nail on the head quite nicely, in fact, arguing that the main problem in companies' IT infrastructure today is their high infrastructure maintenance costs. Add to this the rapidly widening gap between hardware development and the software that is actually being used in companies, and many data centers end up awfully bloated, even though only a fracture of their capacity is being used.
The irony here is that in many cases, this situation tends to actually be more expensive in the long run when factoring in the costs required to keep a data center running (think about electricity, renting rack space, etc.) However, companies do not like being forced to make a switch, in part explaining the large success found by virtualization in companies that simply want to keep on using the same old software, but in a more efficient manner.
Virtualization, as documented in many articles over the past year, provides a pretty solid answer to this, and is actually the core technology at the base of the Cloud Infrastructure. Its evolution from consolidation tool to fully-fledged dynamic data center management enabler has paved the way for an even bigger jump forward: IT as a Service.
Virtualization has grown to the point where we can reduce a data center to one big resource pool, with the virtual machines more or less floating on top, blissfully unaware of where their actual resources come from. IT as a Service aims to make it possible to extend this internal company resource pool (conveniently nicknamed the "internal cloud" from now on) reliably with resources obtained in much the same way as electricity, or a phone line. The idea is pay as you go, pay for what you use, always available and reliable, and with a large choice of service providers (from here on referred to as the "external cloud"). This is what VMware vSphere 4 will be able to provide.
Facebook
Twitter
RSS
11 Comments
View All Comments
Bandoleer - Wednesday, May 27, 2009 - link
VMware has always stated that logical CPU's (HT) are not considered cores as licensing is concerned.pcfxer - Sunday, April 26, 2009 - link
e-mail, internet browsing sure, maybe even something like google docs, but running centralized applications is NOT nearly what management/marketing would have you believe it is.Any support technician that works with local and centralized application infrastructure (in the likes of Citrix/TSP) would agree with me immediately when I state - TSP is a bugger to debug and diagnose, the issues are complicated by odd application errors that don't relate to what is really happening. What really happens is that the NTUSER.DAT file becomes corrupt, why? (bad resource/data forking??) Not sure, myself, it's closed source on the TSP and on the centralized app (MS Word, etc.) ends.
Centralized applications also require FAST and HIGH THROUGHPUT to work efficiently. Consider it like this: your computer stores the application so you optimize the HD latency, memory latency, cache latency etc. TSP however, relies on the network. for thin clients it's easy; just optimize the NIC and TCP/IP stack. Beyond that, it is BRUTAL! You start asking vendors how many simultaneous connections and the sustained latency/throughput with X number that they give you and you'll see the VERY puzzled looks on their faces.
Do it anand, trust me, Cisco sent me to engineering to get the answers that I wanted. Some more expensive switches end up being SLOWER than others because of the latency incurred when using TSP with a larger number of clients.
Main applications shouldn't be centralized, niche ones, maybe, but the most reliable deployment is a bunch of workstations running local applications. IT ALWAYS WILL! When was a data stream dropped between your hard drive? Does it happen? Yes, rarely. When do packets get dropped that are just as important? OFTEN.
has407 - Monday, April 27, 2009 - link
Just because applications as architected and implemented today don't work well with a centralized/cloud model doesn't mean there's something wrong with the model, or a fundamental reason why applications--as in code that produces the same result--can't or won't behave reasonably with that model.We've been through a couple cycles of this, going back and forth between centralized and distributed. We had "cloud computing" (aka "service bureau's") decades ago, and they worked fine, because systems and applications were architected and implemented to work in that model. Ok, so they were green screens and not GUI's. So what? Then came the PC/client-server model, and now we appear to be moving back to the centralized/cloud model.
The problems cloud/centralized models face today are a mirror image of the past (i.e., what happened in the 90's during the change from centralized to distributed and client-server). The problems are transitional, and are largely the result of attempting to make applications built for one model behave properly in this (*cough*) "new" (*cough*) model. Been there, done that, and we'll do it again. *yawn*
The only thing that seemingly hasn't changed in decades is people who insist "X" won't work because, by darn, "X" is what they know and because they're narrowly focused on one part of the picture.
Milleman - Sunday, April 26, 2009 - link
Why aren't they supporting the Ubuntu 8.04 LTS version? Very strange, since datacenters or providers really wants to stay supported on OS version as long as possible.has407 - Sunday, April 26, 2009 - link
They support 8.04, 7.04 and quite a few others; see:http://www.vmware.com/pdf/GuestOS_guide.pdf">http://www.vmware.com/pdf/GuestOS_guide.pdf
has407 - Wednesday, April 22, 2009 - link
> Another question left unanswered is whether VMware would allow for quad-socket machines in the Essentials packages...They're pretty clear about that, per the VMWare vSphere 4 Pricing, Packaging and Licensing Overview: "[Essentials and Essentials Plus] include licenses for three physical servers (up to two processors each)...". However, it's unclear whether they'll allow a max of 6 processors in any combination up to 3 boxes; e.g., 4+2 or 4+1+1, but few people are likely to looking for those in combination with Essentials (that 4x box is an expensive outlier).
> For the Essentials Plus, Advanced, and Enterprise Plus packages, the maximum number of physical cores per CPU is upped to 12...
You don't get that with Essentials Plus; the 6-core/proc limit still holds.
LizVD - Thursday, April 23, 2009 - link
After some digging around on VMware's website, I ran into this:"Each physical server may contain up to two physical processors with up to 6 cores per processor."
on the following page: http://www.vmware.com/products/vsphere/buy/overvie...">http://www.vmware.com/products/vsphere/...re%20pri...
So I guess that's cleared up now. :)
LizVD - Thursday, April 23, 2009 - link
Thanks for the heads up on this, we based our questions on the documents we received from VMware prior to the press release. As it turns out, those were not very clear on certain numbers and outright wrong on others (as noted in the picture on page 4)Now that the information has been released publicly, I'll get right to correcting these things.
has407 - Wednesday, April 22, 2009 - link
> ...otherwise roughly translate to a slightly less than full-featured Standard version (only works on ESXi)...Not sure what you mean by "only works on ESXi"? The choice of ESX or ESXi is the same for all editions and is a "deployment-time choice". Or are you referring to specific features that will only work with ESXi? If so, can you be more specific? Thanks.
blyndy - Wednesday, April 22, 2009 - link
"...a fracture of their capacity..." ...?