Last week Eucalyptus participated in the Red Hat Summit in Boston. This week we are at the Ubuntu Developer Summit (UDS) in Budapest. At UDS Canonical formalized the decision to make OpenStack what they call foundation technology in Ubuntu Cloud. What are the likely impacts of this decision?

As John Pugh of Canonical states it in his tweet (@zoopster): "no real change there it's about choice."

We have been aware of this for some time, and we understand Canonical's decision. Sure, it would have been great to continue as the one and only cloud platform in Ubuntu Enterprise Cloud (UEC). But we have embraced openness and open source exactly because it creates choice and reduces lock-in. OpenStack is a welcome colleague in the Ubuntu world.

Eucalyptus will continue to fully support Ubuntu Linux. The UEC is a set of extensions to Eucalyptus that Canonical maintains as add-ons to the baseline set of Eucalyptus Ubuntu packages. We plan to continue to package Eucalyptus for Ubuntu; it is the set of add-ons that will no longer be supported by Canonical.

The world is becoming a massive computational machine. Soon we will have 10 billion connected devices on this planet - phones, pads, laptops, servers, GPSs and vehicles, medical devices, meters and recorders, and so on. And then there will be more. These connected devices, which are advancing the speed and quality of our communication and access to information at an extraordinary rate, are also democratizing the use of technology - between humans and among the devices themselves! The only way to effectively handle the varied, unpredictable and massive workload resulting from this expanding connected world is with compute clouds. We must rapidly build public clouds, private (on-premise) clouds, and hybrid clouds. If we don't, we'll quickly run into a number of walls: lack of compute resources, lack of space for the computers, and lack of energy to power them.

After reading about the AWS outage, it occurred to me that while much attention has been given to the effects, little discussion of the fundamental cloud principles at work has been offered. It seems to me that there are two important factors to consider when analyzing an event like the AWS outage:

• the tension between elasticity and fault isolation
• the rarity of rare events

I'll try to muse (as briefly as I can) on both topics.

The Elasticity Versus Fault Isolation Tradeoff

In some sense, a cloud must allow the users to have it both ways. On the one hand, users expect elasticity: the fluid and seamless acquisition of resources from anywhere in the cloud without explicit regard for location or provenance. On the other, the cloud is expected to fence off faults and failures so that they do not propagate globally across the cloud when they occur.

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. Discussing the nature of these various roles (see Cloud IT Roles for more details) has become as much a part of the Eucalyptus deployment process as is the software itself. In this posting I'll try to discuss the nature of these conversations in broad terms.

Today Canonical and Dell made an important announcement: Dell is shipping servers with Ubuntu Enterprise Cloud (UEC) pre-installed. This is great news for any business interested in private cloud computing. UEC consists of the Ubuntu Linux distro combined with the Eucalyptus open source cloud platform. UEC is a robust and production-ready software product that has been shipping for over a year now, with a huge number of deployments all over the world. Now, all of that is available in the USA as a simple and single purchase from Dell.

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.

Does the system scale?

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:

• 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?