By Rich Wolski | June 25, 2010
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."
How do I build a cloud?
This question seems to have an obvious answer when posed to someone who has been working on developing Eucalyptus, but self-serving motives aside, there are several factors to consider. The architectural requirements for building a public cloud, for example, are different than those for a private cloud. Because a public cloud must serve a wide variety of "unseen" users at a commodity price point, architecturally the emphasis typically is on modular extensibility at the infrastructure level. Service providers require the ability to add and remove infrastructure resources in well-defined units as demand dictates without changing the uniformity of service that is offered. In the enterprise, users and administrators have well-defined roles and responsibilities that the cloud must be able to support. This delineation of capabilities is expressed as a set of policies that the data center infrastructure must implement. Thus, as an infrastructure platform, an enterprise cloud must be able to implement the varied set of policies, often defined as a hierarchy, necessary to capture the organization structure of the enterprise that deploys it.
Notice that this differentiation does not depend on whether the cloud is a "private cloud" (e.g. one deployed on infrastructure owned by the organization operating the cloud) or a public cloud. It is the drive either towards or away from commoditization that dictates the difference in cloud architecture and not the ownership of the infrastructure resources. Notice also that "pay as you go" (an accounting feature often cited as being a key differentiator of cloud computing from other forms of IT infrastructure) is independent of the public-private cloud architectural differences. That is, an organization can implement "pay as you go" (a feature typical of public clouds) in its private cloud if its accounting practices are well suited to the variability in budgeting that such a scheme implies. Alternatively, a public cloud provider can implement large-scale capacity reservations for its customers instead of the popular "pay as you go" pricing that has garnered so much attention.
Building a cloud, then, starts with a determination of the properties that the cloud, as infrastructure, should attempt to optimize. Those properties and the degree that they are optimized are dictated by usage, expressed by policy, and ensured by operations.
Once this architectural work has been completed, then the organization immediately, without hesitation, and with great enthusiasm should deploy a Eucalyptus cloud. Eucalyptus is amazing technology developed by the most talented and hard-working people with whom I have ever had the pleasure to work. I am also extremely biased.
How do you turn a private cloud into a hybrid cloud?
There are really two approaches to hybridizing a private cloud. The first is to use some form of management "dashboard" (e.g. RightScale) that is specifically designed to work with multiple cloud providers. The advantage of this approach is that it centralizes the management task. As cloud APIs converge on a common set of abstractions, it will be possible to develop a universal VM (one that can run in any of the supported clouds without modification). The disadvantage of this approach is that until the APIs converge, the subset of functionality that intersects between clouds is fairly limited. DeltaCloud, for example, provides a multi-cloud API today but its functionality is a subset of the various cloud functionalities that are available.
Alternatively, building a hybrid cloud using private and public cloud platforms that support the same APIs offers a more complete integration, but for a more limited set of cloud combinations. Again, as cloud APIs converge, the set of combinations that will inter-operate completely will increase, but at present, hybridization based on a common API restricts the set of clouds that can be combined in favor of having a more complete integration.
Like with most architectural designs, it is possible to combine both approaches. Eucalyptus, for example, supports the Amazon AWS APIs. In so doing, it can be hybridized with AWS directly (images that run on AWS will run in Eucalyptus and vice versa). In the same vein, dashboards that support AWS can also support Eucalyptus since they will control both through the common API. If these dashboards or interoperability technologies also support other clouds, then the mapping of abstractions from one to another (at the possible expense of supported features) will be similar for AWS and for Eucalyptus.
As cloud computing evolves, I believe hybrid platforms will become prevalent, and that both inter-cloud coordination and common API approaches will be available. The combination of both approaches will ultimately result in a standard set of abstractions that all cloud applications will be able to assume is present on any platform. Standards will not completely homogenize cloud computing, however. In the same way that there are now several different Linux distributions that share a common set of core functionalities, there will be multiple cloud platforms that share a common set of features.