In sum, a busy, talkative workshop, with reasonable attendance (I counted upwards of 50 at peak). A good mix of government and some industry (the only real missing speaker was HP, though they attended). I'm also continually thankful that Elastra gets invited to these sorts of events; it sort of validates that our approach is interesting to the larger players.
Many shapes & sizes of Cloud
A clear indicator of the maturing of the cloud community was that private clouds and hybrid clouds were on everyone's lips, and seem to have been essential to generating "enterprise interest" in the concept of cloud computing.
I recommend reading NIST's presentation on this topic, it's well thought out (I'll link to it when the proceedings are published).
It's not that private clouds are what people are exclusively interested in, it's that a) in the short run, they're the only game that's acceptable for Federal agencies or for conservative enterprises, due to very real security and compliance fears, b) even in the long run, the reality will be a hybrid cloud world, not a Big Switch, and c) the benefit behind clouds cannot be just about outsourcing, or else we're screwed, it's just an over-hyped sales pitch. At this point, I think those that say "Private Clouds are a distraction" are full of shit.
The benefit of clouds
In my talk (slides should be available soon), I discussed how Elastra views the benefit of clouds to business. In order of "difficulty to achieve": Primarily it's about resetting cost structure -- moving ongoing IT demand consumption to a variable cost structure, and freeing IT from viewing everything as massive fixed cost. Secondly, it's about drastically reducing the lead times to change one's IT infrastructure in response to demand. Thirdly, it's about increasing visibility of the IT infrastructure and how it ties to business results. Fourth, it enables a more precise, commoditized approach to outsourcing. These benefits have their roots in the overall move towards services-oriented computing, just that they're being applied inwardly.
Some might say that clouds "TODAY" provide a commoditized , precise approach to outsourcing. And I would say "sort of" -- the caveat is that everything is still proprietary, and that SLAs are mostly crap, the price structures don't work well except for 'very elastic uses' of scale, and there aren't many large-scale clouds that are viable alternatives to Amazon EC2 (though Windows Azure is getting there, and IBM is likely coming).
I don't really know if the attendees bought into my view, but I still think we don't talk about this stuff enough -- we're too busy futzing with technology.
What about PaaS?
These sorts of interoperability discussions have a hard time reconciling with Platform as a Service. The Salesforce.com talk was good, explaining their view of interoperability -- they allow you to share your data with other clouds & services, and that's their nirvana. But your implementation and custom logic is 100% proprietary. You might be able to get portable logic if you use a Model Driven Architecture approach that generates APEX code for you, but that's about the extent of today's possibilities.
Reuven was notably unhappy with this state of affairs. I chimed in and claimed that PaaS works well for departmental applications or vertical apps where "you just want it done and don't really care about customization lock-in". There are many, many examples of business applications in that category: witness every Microsoft Excel macro or Access database in the small, or any large-scale ERP, HR or CRM system. This is why Salesforce is a billion dollar company.
I know this will come as a blow to the "open uber alles" crowd, but sorry - enterprises care about reducing lock-in on their infrastructure. Not really in their applications. If enterprises start looking at IT more in application terms, and PaaS becomes "the way forward", we had better start dusting off our SOA, ETL, and EAI hats, because that's where the problem will always lie.
In fact, the biggest problem with Salesforce's stuff is not that it's locked-in to their software, it's that you can't choose to run it inside a private cloud. They're one of the stubborn ones against "private clouds", understandably. For this reason, I think Microsoft's approach to PaaS is probably going to be very successful. .NET is your platform. It's very popular, and will continue to be so because of Azure.
Standards ... If not today, when?
On the interoperability front, there was discussion about whether it was premature for cloud standards. And generally, the feeling was, yes it is -- BUT -- history has shown it's important to start the discussion early, and get people networking early, lest they go off and do their own interpretations of what people need & we wind up with a mess despite our best intensions. One of the analogies that Bob Marcus kept alluding to was the emergence of the Enterprise Service Bus in the SOA world, which emerged because even though we had the WS-* stack, things still weren't all that interoperable, and capabilities varied wildly, so a mediator became necesary. And the service buses themselves were all very different in their operation, so required specialized knowledge to install, use, and develop against.
A lot of the sessions are "here's what we're doing to help to get people to talk about standards", which is fine, but indicative of how "early days" all of this interoperability work really is. The general feeling can be summed up as:
a) Cloud Computing is still fuzzy, but has the potential to be great ;
b) Clouds are mostly closed today, and that's OK, but not great ;
c) A modicum of provider-level openness will be essential for the Federal community.
IOW, it's a huge mistake to assume that the EC2 API is a de facto open standard. I don't think anyone in the room had this illusion. Here's why, IMO: for one, it's a stretch to call it "open" -- it's under the control of a single company, and licensed by them. If they decide they dislike the software that implements that API, they can change the license for future versions, and shutdown old versions, making older versions basically useless. Secondly, there are a number of core cases it doesn't cover. The biggest is that it doesn't give you the ability to express "desired state" of a cloud as a document. It's just an API. Whereas enterprises seem to want to be able to reuse their configurations, store them, verify, certify, sign, and version control them, etc. Hence the interest in document standards like OVF or hypermedia formats like EDML and ECML.
The problem is that if these standards take so long to build, then we're going to have to invest in "cloud service buses" to enable portability and interoperability. In a prior post, I mentioned that this is what I believe will probably happen. There are too many cooks in the kitchen.
The substantive discussion on potential standards included:
Winston Bumpus (DMTF President)'s talk on OVF
Mark Carlson's talk on SNIA's XAM initiative
And from the vendor side, there was:
Sun's Cloud API
Elastra's Markup Languages
All which deserve a separate post.
My short takeaway was this: OVF is likely going to be very popular. We're going to regret its scope decisions eventually (i.e. a focus on install & deploy, and little else), and I think there's going to need to be proprietary extensions to enable its use in a "cloud" context, but as Winston called it, "it's the MP3 of the data centre".
Get enough people repeating that to themselves, and I think they'll have a marketing winner. If Woody Allen is right, and "80% of success is showing up", I'd say yes, DMTF currently is the leading candidate for becoming one of the premier cloud standards bodies.