I spent a great half-day at CloudCamp @ CommunityOne, this week. This was an Unconference, "a facilitated, participant-driven conference centered around a theme or purpose," meaning that the agenda and content were provided by the participants. The format can be very effective, especially in cutting-edge, rapidly evolving areas like this.
Indicative of the state of cloud computing, our first order of business was to hammer out a definition: what is "Cloud Computing"? We quickly agreed that abstraction from hardware management was a key thought, but I don't think anyone really believes that's the whole story. Certainly not this group! As we talked, it became clear that most participants thought Cloud Computing also requires refactoring your application for horizontal scale, statelessness and location transparency, and a few other fairly new programming disciplines. These might be part of the definition, or perhaps just "best practices," but they were high on everyone's interest list. (There is, by the way, some good work on-going at NIST in defining the terms of cloudy discourse.)
What strikes me in all this is that, if you're deploying into a cloud, you're going to need several of 'em. Just as you can't let developers and testers and untried code onto a production system, so also a production cloud needs to stay clean. You may be able to share lower levels, but you'll need security separation, debugging tools, experimental versions, and so on. NIST talks about three "cloud delivery models":
- Cloud Software (Applications) as a Service
- Cloud Platform as a Service
- Cloud Infrastructure as a Service
If you're building the applications, you might be able to share the platform with a production application instance, but not the application itself. Similarly, if you're building the platform, then shared infrastructure can work, but you'll need a sandbox platform.
This all fits very nicely into CollabNet's Lab Manager component: the Lab Manager can allocate infrastructure instances from several providers, and track the profiles that distinguish production from test, test from development, application from platform, and so on. If you're developing at the Infrastructure level, you can use the Lab Manager to allocate physical boxes in your own office, so you can poke and prod. If you're working at Platform level, you can allocation physical boxes anywhere, and exercise your location transparency in and out of lab, test, and even production. And if you're clouding up your application, you can float blissfully above all that, while still complying automatically with your local policies.