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.
Consider the following question: "Does the freeway system scale?" If you have spent any time stuck in traffic you have undoubtedly wondered about the scalability of the freeway or roadway system. Most immediately, the question at hand is "How does the user experience on the freeway degrade as more users share the system?" The term "user experience" here is most often thought to refer to delay, but even for something as familiar as freeway congestion, delay is too simplistic. For example, some drivers prefer a route that is free of congestion over one that minimizes travel time with congestion. That is, a 30 minute trip in stop and go traffic may be less desirable than 40 minute trip to the same destination with no traffic.
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:
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:
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.
As many of the press reports have indicated (Wall Street Journal, New York Times), Marten Mickos has joined Eucalyptus as our new CEO, which is truly an exciting turn of events. It is amazing to be able to work with Marten, who truly understands the value of open source software and how to build an open source business, particularly at this stage in the technology’s and the company’s development. Before Eucalyptus, many of us had been big open-source users, and those of us who come from academia have benefitted tremendously from the availability of open-source software. Indeed, one of the motivations for Eucalyptus continues to be a sense that it is our turn to contribute to the community. The business success of MySQL AB, where Marten was CEO for seven years before it was acquired by Sun, is seen as a triumph; at its foundation is the still tremendously- successful MySQL open-source technology.
Recently, Thorsten Von Eicken, founder of RightScale and Adrian Cole, founder of jclouds, both offered interesting insights regarding cloud APIs -- in effect, defining some of the "dos and don'ts" of API design. Since we (at Eucalyptus) struggle with the implementation of different APIs somewhat regularly, I felt like I could shed some light on the perspective with which we work during these struggles.
From our perspective, understanding the distinction and separation between the design of the API from the abstractions to which it is an interface is important. That is, when we look at API we see two aspects of it:
-- the operations on abstractions referred to by the API calls
-- the syntax and operational behaviors of the API calls themselves