When cloud computing emerged, it spawned a healthy debate regarding its definition. Like the word "irony" famously immortalized in the film "Reality Bites," the term "cloud" was immediately familiar and undefinable for most technologists. "You'll know it when you see it."
As enterprises are adopting private clouds, the question of how workflow and responsibilities need to change is one we find ourselves discussing with increasing frequency. In particular, the dynamic way in which clouds respond to provisioning requests from their users, and the "self-service" features that all clouds support, both change how users and administrators interact with the data center.
I was at the Enterprise Cloud Summit in New York where Lew Tucker was moderating a panel on private clouds in the enterprise, and I noticed a rather dramatic change in the discussions that took place regarding private clouds. To begin with, Alistair Croll from bitcurrent gave a wonderful set of opening remarks that framed private clouds in a way that is really accessible. Randy Bias talked about the experiences with his new company, Cloudscaling.com in architecting a cloud for Korea Telecom. Again, much of what he had to say resonated with our experiences at Eucalyptus (perhaps too well at times) -- a great talk. The morning session ended with our panel covering topics offered by Lew at first, but mostly from the engaged and surprisingly awake audience members.
"Scale" is central to the arguments for and against cloud computing but, somewhat curiously, the arguers never seem to provide or agree upon its definition. Given its importance, in this posting I will try to explore the meaning of the term "scale," specifically in the context of cloud computing.
In the last two episodes of this series, I provided commentary on four of the top five questions on "Cloud Computing" that we have heard in the Spring of 2010. In this epilogue, I reveal my presentiments related to application alterations that are requisites in cloud computing.
In my last posting, I provided a best-effort opinion on the answers to two of the top five questions we see in the Spring of 2010. Given the brief hiatus I have enjoyed, I am now ready to share the outcome of my ruminations on cloud construction. The two questions that I tackle are:
- How do I build a cloud?
- How do you turn a private cloud into a hybrid cloud?
After a brief interlude, I will return with the final episode in this series of the Top 5 Questions on "Cloud Computing."
The phrases "cloud computing" and "private cloud" have permeated the technical zeitgeist with a rapidity that we have rarely seen. As a result, we spend a good deal of our time discussing these concepts with our customers, partners, and technical colleagues in an effort to understand what they mean in concrete terms. In an effort to bring some clarity to these ruminations (primarily to myself), I've tried to distill them into a "Top 5" list of questions we are asked and to formulate my opinion of how they can, and in some cases should, be answered.
First, the questions in dramatically paraphrased form are:
- What is a "private cloud" and how is it different from a "public cloud" and a "virtualized data center?"
- Is a private cloud secure?
- How do I build a cloud?
- How do turn a private cloud into a hybrid cloud?
- What will I need to do to my applications to get them to run in a cloud, private or public?
One of the questions surrounding commercial cloud computing that seems to continue to elude a clear answer is "Should Cloud Computing services be developed as commodities?" Less succinctly, the question is whether services should become completely interchangeable with respect to the functionality they support so that price is their only differentiating factor.
Initially, most consumers, or potential consumers, of cloud services seem to respond very enthusiastically to the prospect of interchangeable commodity services. The belief appears to be that interchangeability will lead to competition between service providers as no provider will be able to "lock in" its customers based on a specific functionality. Competition will have the twin benefits of driving the price down and creating redundancy in the market so that customers can be insulated from the effects of a possible failure of a single vendor.