Stu says stuff

There are at least six views on Cloud Computing out there, and why they're important. Some people are pretty adamant that their definition is the one true definition, others tend to admit the overlap. Optimists would call this state of affairs "synergy", pessimists would call "vagueness", cynics would call it "sophistry".

I'd like to distill, briefly, how I see things.

1. Theme: Scale without skill, Availablility without avarice

Why Cloud? "Don't worry about Scale or Availability, SuperCloudPlatform Will Take Care of It"
Do: Adopt a Cloud Platform, like Google App Engine, Azure, or Force.com
Don't: Worry about Infrastructure as a service, that's so .... 2006.
Laugh Nervously About: The Magic Architecture & Buzzword Bingo required to make this work. Also, all those PaaS APIs seem rather proprietary....

2. Gimme an A! A! S!

Why Cloud? "Consuming IT as an On-Demand Service instead of as a capital intensive product"
Do: Build out your cloud architecture, with its various layers, and invest in software & services at each layer.
Don't: Get locked into anyone's narrow concept of a cloud. PaaS, IaaS, some SaaS, etc., are all contenders.
Laugh Nervously About: That, as with SOA, everything is a cloud; that you can't buy a cloud, yet everyone seems to be trying to sell you one.

3. Efficiency through Outsourcing

Why Cloud? 1. "Owning your computers is as passe as owning your own energy generator" 2. "Do more with less"
Do: Find one or more strategic cloud partners and begin piilot outsourcing
Don't: Buy more hardware or software to use the cloud. It's snake oil.
Laugh Nervously About: The observation that outsourcing has been a panacea for IT's woes for over 15 years, and last we saw, it seemed like a shell game.

4. Efficiency through Consolidation

Why Cloud? "Your DC's Power, Thermal Hardware utilization are awful; you really could improve that. Virtualization was the start, this is the next step"
Do: Buy Cloud Management & Data Center Automation software, use a Cloud Services partner/SI, keep maturing your use of virtualization.
Don't: Really jump into Cloud Definition #3 until your own house is in order.
Laugh Nervously About: The extra software you're expected to buy, and that it seems to require extra hardware too. "Won't Get Fooled Again" by The Who seems like an apt theme song, particularly the final verse.

5. Process Networks

Why Cloud? 1. "The next-generation of the Internet that will tie together process specialization, information integration, social networking, and contextual data" 2. this is sort of where the "Web Services" vision, circa 2002, left off, after which time they made some poor investments in personal hygiene protocols and associated chicanery.
Do: Meditate on the Zen nature of this future evolution of the Internet. Sign on to Twitter. Attend lots of conferences with "2.0" in the title. Maybe buy a BPM tool, or invest in some Strategic Cloud Consulting Services. Clouds #1, #2, #3, and #4 may be useful on the path to nirvana.
Don't: Worry too much about technical details, it's all about your business anyway.
Laugh Nervously About: 1. That no one knows what the fuck these people are talking about, even though there's probably something interesting happening here. 2. That the paint is still wet on BPM vendors renaming themselves Cloud companies.

6. The Rise of Lean IT

Why Cloud? "Reduced lead times to enabling change in your IT environment, thus driving greater business value"
Do: Start redesigning your IT processes. ITIL v3 ain't bad, if you take it with a grain of salt. Pick up some IT automation and management software while you're at it.
Don't: Think that technology alone will solve your problems, this is mostly about organization & culture, baby.
Laugh Nervously About: 1. That the primary industries that have embraced Lean concepts are Automotive and Telecommunications, and the telcos have been talking about it for 10+ years with little sign they're really serious about it. 2. Agile/Lean proponents tend to be backed by a posse of folks that like to write manifestos.

I'm still here, silently plugging away at Elastra's product & working with our design partners. Busy times.

I'll be attending GlueCon in Denver next week, and Interop Las Vegas for a couple of days the week after, if you're around, give me a shout.

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:

Enomaly's UCI
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.

I tend to think of interoperability as a gradient.

The old industry stalwart from the 1990's is what I'd call "runtime interoperability", wherein you could write a Java EE application, deploy it on a Java EE application server, and (with a questionable amount of tweaking), get it to operate. SQL was another attempt at this, with mixed success. The later CORBA standards tried too, with the Portable Object Adapter (POA). And clearly, the ISO/ANSI C runtime libraries have been successful, as have many other programming libraries.

The other angle of interoperability grew in the 2000's is what I'd call "protocol interoperability", an approach that, at first anyway, only a network engineer could love. Most of the *TP's on the internet take this approach, where the "network" is first, and dictates the pattern of interaction -- the "developer" and their desires or productivity is secondary.

With cloud computing, we're currently going through the age old discovery of "what form of interoperability makes sense?". Especially given that we're dealing with networked applications (indicating a need for "protocol interoperability") but also with complex configuration & resource dependencies for security, scalability, etc. (an area where "runtime interoperability" usually plays).

Starting Observation: Microsoft Has A Clue.

Windows Azure is trying to balance these approaches to interoperability. For example, .NET Access Control Services allow you to federate identity between your own Active Directory and Azure. This is all just Active Directory Federation Services (ADFS) and using the WS-Federation "standard"; something you could do with OpenSSO too, for example, for over a year. But they'll probably make it easier if you stick within the .NET / Windows world.

A similar case could be made with their .NET Service Bus,  as a way of enabling Windows Communication Foundation and Biztalk applications span Windows Azure and private deployment(s).  This isn't just a pipe dream, either, they're actively doing this with the early Azure releases.

The Scope of Interoperability

What makes this work is that .NET is already a widely used platform in private data centers, and that .NET is a single-source runtime.     Now, an astute observer may exclaim,  "but that's not interoperable!  Where is the multi-vendor ecosystem!?"  At which point we have to ask ourselves, what's the scope of desired interoperability?  

Is it :

- A vendor ecosystem of interoperable runtimes?  Ponder the success and market results of SQL, Java EE, etc.  before wishing for this.    Where they did make a difference?   (They did make a difference, but perhaps not where one would intuitively think.)

and/or

- The ability to enable multiple providers to host a single runtime and enable interoperable "services" (e.g. identity, data, process, etc.) across these runtimes?   

I suspect the latter is more readily attainable, and likely higher value, than the former. And note it doesn't preclude the existence of an ecosystem. It just suggests that enterprises are going to care more about cloud-spanning functionality in their "chosen car trunk" than wait for a common runtime to emerge.

What are the alternatives for a "hybrid cloud" platform to .NET and Azure?   

1. Force.com APEX might work if they invested in private deployments -- not likely.     
2. There's Java, though Sun, IBM and Oracle haven't been doing much there yet.  
3. There's EngineYard starting down the Enterprise Ruby on Rails path.   
4. Google perhaps heading down the Enterprise Python path (also not likely)

5. Infrastructure as a Service, where you could write your infrastructure in Erlang and OCaml for all your cloud provider cares (so long as you don't use multicast ;-)

In this last case, runtime interoperability would require a lot of "roll your own" configuration management, integration, and interoperability.     Or you could rely on...

6. So-called "Cloud Servers" (e.g. CloudSwitch, 3Tera, Elastra, etc.)

Which give you ways to help craft models & designs & orchestrations that help you with configuration management, integration, policy, interoperability, and governance.  Which in essence is just like what the Hybrid PaaS guys are doing above:  constraining the problem space to gain some level of deployment flexibility.   The difference is that cloud servers boil the problem down to a (hard) configuration management problem, instead of building "a standard runtime to rule them all". 

Naturally, because I work at one of those "cloud server" vendors, you'd think this is my preferred model. But honestly, I'd be pretty happy for the industry if they agreed on either model. Time will tell.

My Predictions

a) I have serious doubts about a "new" cloud runtime portability standard.    The battle lines were drawn long ago, and while they'll blur, it likely will continue to look like " .NET vs. Java vs. everything else" for at least 2+ years.

b) One could argue it would be nice to build a standard protocol (using an architecture that fits how early adopters think) for Infrastructure as a Service to provision "Obvious Stuff" like storage, CPU, and network.   The DMTF CIM stuff is great but probably too low-level,  and too WS-* focused to be palatable to early adopters.   The DMTF OVF stuff is likewise great, but isn't focused on "lifecycle", i.e. what the heck happens to this deployment over time?   It's (thus far) focused on creating virtual appliance bundles.

Something RESTful would be nice to enhance our serendipity, but frankly the EC2 API isn't all that great of a starting point (for several reasons; different discussion though).    

Regardless of the architecture, the big win here would be that it would reduce the need for a "Cloud Service Bus" that mediates among different APIs.   I think this kind of standard will happen, but it will take 2+ years, thus being ratified just as early adopters have bought their shiny new Cloud Service Bus.....  ;-)

c) A wild card is where the "massively parallel processing uber alles" crowd will flock.   From what I can tell, four visible options:  
(i) Hadoop (i.e., Java; though I bet there's a .NET port coming), 
(ii) Open Grid Forum / Globus,
(iii) Parallel SQL Database (e.g. Vertica, ParAccel, Greenplum, etc.),
(iv) Proprietary Platform (e.g. Google)

And those cases are very clearly NOT going to be a likely candidate for hybrid-cloud interoperability below the service-API level, given the latency requirements and tight coupling inside those services.

d) Even in a world of a handful of interoperable Cloud Platforms, I suspect there's a going to still be a big configuration management and governance problem.

Where does Elastra's work fit into this?

Well, first, let's be clear: I have modest expectations for our work on EDML, ECML, etc. I don't expect them to become standards. I do hope to contribute the work we've put into this stuff into a standards effort, and that the industry really does adopt a RESTful linked data approach to describing IT. On the other hand, we've been at this for over a year, and I doubt there will be industry consensus on even 20% of the topics we're modeling. EDML, with its emphasis on resource reservation, allocation, packages and settings, sure, I could see value. ECML, however, is an architecture and policy description language; I suspect there's a lot more acrimony awaiting in there.

Secondly, I have no illusions about the ability for a startup or even a "community" of individual contributors to influence or fund a standard with this much industry attention. Large companies will get their way, invariably. Good ideas may survive through a combination of luck, serendipity, and maybe small doses of charisma and chutzpah among the evangelizers.

So, I will continue to show up at the occasional interoperability or standards meeting, post on mailing lists, etc., but otherwise I'm focused on our product suite. We built these languages to get our jobs done, and are happy to open them up when we have the time to complete the documentation for a wider audience. For now, I'll be presenting highlights at the OMG cloud interoperability meeting in March.

Previously on the hit game show, "What's a Cloud?"

• John Willis: Is Everyone an aaS?
  
• Greg Pfister: Is Cloud Computing Just Everything aaS?
  
• (my interpretation of) IBM's definition: a style of IT delivery combining virtualization + soa + service management, for apps, data, and IT resources
  

Over on RedMonk, I heard a very intriguing quote from James Governor that was buried in video:

"If you think of the post-SOA term, from Nick Gall... Web Oriented Architecture, clearly this is somewhat different from SOA, although there are some patterns common to both of them..... Is the cloud Web-Oriented Operations, or WOO? (We have WOA and WOO)... and what IBM is saying is definitely not WOO, it's business as usual, it's just about flexible delivery of application -- all the stuff that is goodness, all the stuff that Tivoli has been talking about since 1995. That stuff all has value, but it's not Cloud. Cloud involves difference. Business as usual, that's just provisioning service, and automation and virtualization, which is all good, but... if I hear a another person tell me that CLOUD = SOA + VIRTUALIZATION + AUTOMATION, I'm going to ignore them and rubbish the idea as much as I can."

Preaching to the choir here; I left BEA almost a year ago to build out a WOA platform for clouds.

But I'm curious -- as far as I can tell, most clouds really ARE some combination of:

1. Service Interface (e.g. Amazon Web Services aren't really WOA up close)
   
2. Provisioning and Automation of some sort (e.g. images, web applications, multi-tier designs)
   
3. Virtualization is admittedly optional, though increasingly common
   

So, if cloud is different, is the difference really a trend towards WOA, or is this really going to happen? I see two patterns:

One pattern is emerging from the IBM and HPs of the world that have collected a number of shiny baubles in their ERP4IT stacks (Tivoli and OpenView) and invested heavily in SOA and WS-* to painstakingly integrate them (and the pile of IT that has been built on this technology over the past 5+ years)> This pattern indicates that the IT world is cleaving in two, with web architecture on one side, to build the new class of end-user services, and boring old SOA+VIRTUALIZATION+PROVISIONING for the back end.

The other pattern is that the cloud is about Web Architecture end-to-end, using WOA to enable linked data and mashups for the development lifecycle, architecture & operations lifecycle , and end-user-services.

I wouldn't bet on the latter being a fait accompli, as most haven't wrapped their heads around how to make this work. And of course, there's a lot of inertia. There are bright spots: notice one of those links comes from IBM Rational's Jazz / OSLC initiative - they seem to "get the Web" for enabling interoperable software delivery lifecycle tools. But the problem is end-to-end. At some point the industry has to recognize that IT is becoming complicated enough that planning for product-line-style reuse is of isolated value, and designing for serendipity and applying knowledge representation principles at global scale are legitimate ways out of this mess.

A lot will depend how this changes the cost and user experience of the ball-of-IT-mud (and whether that can be effectively communicated to those who don't follow the latest architecture acronyms).

I attended a Cloud Interoperability Forum in Mountain View yesterday, hosted by Stephen O'Grady from Redmonk and David Berlind from InformationWeek. I roughly counted around 50-60+ in attendance, with a moderate drop off after lunch.

Twitter stream is available under #cloudinterop.

Here are my takeaways, the day after....

Cloud Taxonomy: aka "What we have here is, failure to communicate"

TL;DR version of this post: We think we know what we're talking about when we discuss "cloud computing". We really don't know what we're talking about - there's a lot of confusion, and it's rapidly becoming a marketing term. Thus, a taxonomy would be useful, if we're ever going to foster interoperability or portability.

Out of everything, I think the desire and will to build a taxonomy was the main outcome of the meeting.

Diversity of Clouds

Clouds come in many shapes and sizes. Infrastructure, developer platforms, storage services, etc.

There's a groundswell of "me too" infrastructure-as-a-service cloud plays, and they're the ones that want/need interoperability the most. I worry that this tends to drown out the conversation, and I'm not sure that this is what customers really are after (more on this later). The two Google App Engine guys (Architect & PM) in the room left after lunch, from what I could tell.

Interoperability at a platform level like Google App Engine or Salesforce becomes just like good old data integration - ETL, EAI, SOA, REST, etc. Some in the audience seemed to want to solve this latter problem (which seems, politely, a high hill to climb).

I spoke up and noted that we should try to understand the areas where there is broad agreement, and the areas where there is no broad agreement, and focus on the former. Because otherwise we're just going to wind up with a messy niche. This was echoed by several participants.

Even with areas with broad agreement we're going to have a lot of work to do, weighing existing standards against their old assumptions which may (or may not) apply. For example, "Cloud Storage" was brought up as an area in need of standardization. But, at what level? Management, provisioning, monitoring, etc? Should it be a high-level API? Or something more like the specs that the SNIA has put out? All of this requires a lot of thought as to the intended audience and the scope of use cases.

Openness, Ideology, and Standards

Bob Sutor, of IBM, stood up to speak to his experience of previous standards efforts. Two points struck me as debatable:

1. "The days of making boatloads of money on locked in technology are gone -- you're not going to get a patent and sit on it."

I agree with this, to some degree, but I think it may be misleading. It's easy to say that "nuclear weapons are no longer effective" when you sit on the largest stockpile of them. IBM has (and continues to collect) the world's largest patent library. And most of their software portfolio is proprietary, and will likely remain so.

No question, open standards and open source implementations are essential, but the issue is figuring out how to balance collaboration, adoption, and the desire to make money by (in part) excluding competitors. "Commercial open source" companies do this by offering proprietary add-ons. Even RedHat does this, by excluding 3rd party distributors from using its trademark. You'll also notice most ISVs certify their software on RHEL, not CentOS... as intended.

2. Bob urged caution in the tale of REST vs. WS-* to avoid ideology in developing cloud standards. Despite misgivings, "A lot of people made a lot of money on WS-*".

Firstly, I respectfully think this is a misunderstanding as to the role of ideology in standards making. That sword cuts both ways - is all I'll say.

Secondly, I think that it short changes the importance of architecture when defining interoperability standards. Do you build a Cloud API? Or a hypermedia format? Or a document exchange protocol? Or a data schema?

These things lead to drastically different market and business results, and depend on decisions made in the first day - so-called "ideological" decisions such as "what's your architecture?". If all you want is cloud providers to use the same API, I'm not even sure that's the main problem. Sure, it helps small providers in a small, burgeoning ecosystem, but I don't think that's what enterprise IT cares about yet, primarily.

IMO, standards bodies are dangerous affairs for small companies. It's rare that they have a tall seat at the table.

Open Implementations vs. Open Standards

A minor bun fight ensued related to the frustrations of market dynamics vs. building software that one can rely on beyond the lifespan of a company, or if the company has a policy you don't like.

Tim Bray noted that there is a visceral fear of lock-in among many of the companies he talks to. "Substitutability is everything". A senior tech executive from IBM noted that "substitutability focuses on a very narrow set of problems though - enterprise IT and CIOs have an integration problem to deal with".

Followed by various comments from the audience:
"The cost of an Oracle maintenance is too much to deal with".
"Yet few are switching away from Oracle for new deployments."
"..."

I suspect Sun's acquisition of MySQL likely has something to do with the above discussion.

I don't really think there will ever be a resolution to substitutability vs. lock-in: it's a fundamental market dynamic that will be played out repeatedly in different ways.

Anyway, it seems we're back to the old nugget of standardizing for Interoperability vs. Portability, something I recall that was the argument for WS-* over EJB back in the late 1990's. EJB supposedly gave you portability, and RMI/IIOP was what gave you interoperability, and it wasn't good enough because it (realistically) preferred Java on both ends. SOAP/XML was language agnostic and, better yet, supposedly "ideologically agnostic", so that VB developers would play as equally as C++ developers and Java developers.

At best these have both been "modest" successes. I would lean towards believing that interoperability as something actually having lasting business impact -- reducing transaction costs. Portability can do that too, but it's much more case-by-case. We really should be careful as to which we prioritize, and in what area.

A second thread of discussion was on how hard it is to build an open standard, and how difficult it is for one to actually gain traction and become successful. One suggested that open source implementations are more effective means of interoperability - because since it is mechanism, it works, it doesn't have to be (badly) interpreted by several organizations.

But this too has problems, which I and several others pointed out:

a) you CAN get locked into open-source software - switching costs are still pretty high, based on how dependent you are. What happens if the project is taken in a direction you don't like? What happens if it doesn't address your needs? Well, you fork.... which leads us to:

b) If there realistically can't be ONE open source project for an area of cloud computing, there likely will be several. That don't interoperate, or aren't portable.

Which leads us back to the need for open standards with (at best) reference implementations.

Interestingly both the Chairman and President of the DMTF were in attendance and were actively trying to foster dialogue, particularly around the need for a cloud taxonomy.

"Identity" and "Trust" are rat holes of epic proportions.

A significant chunk of the meeting was discussing the ability to carry federated identity across cloud providers. I chimed in that I think more important is carrying identity from location to location in one's application.

I know this topic is near and dear to James Urquhart, and I agree that it's crucial for long-run adoption of a multi-provider marketplace. I unfortunately think that reality is quite a long ways off.

But, this is a problem that goes beyond clouds, and I'm not sure this audience was the right one to wrangle with it.

We have plenty of answers, but we aren't asking the right questions, yet.

The audience was largely falling into the trap of being technologists rushing to solutions without thinking through problems and the audience they're targeting.

There was a focus by many to "scratch personal itches". Which is all well and good, but that's what open source projects are for, arguably, not standards bodies.

There were a few comments of a dislike or disinterest in "academic standards" that will try to do too much. I caution that what is academic in one person's eyes is essential in another's. And sometimes people mistake "academic" for "breadth" or "ambition". Are SNMP MIB's academic? They certainly look pointy-headed, until you realize how pervasive they are. How about all the CIM schemas at the DMTF? Aren't they useful? What about OVF? Certainly it doesn't do much today, but I bet they have broader plans for it.

Finally, there wasn't much discussion about what Enterprises or CIOs want, despite the attempts of some audience members. Which to me, is the biggest concern - above the needs of the "cloud ecosystem" of small vendors, or the frustrations developers get when using today's cloud platforms. We need to focus on what businesses actually want out of this technology.

If the fitness, diet & nutrition industries were to diagnose Steve Jobs' weight problems, they'd likely say he wasn't eating enough, or was exercising too much.

I have no idea what Steve's hormone imbalance is, but I'd surmise it has something to do with insulin.

We've been accustomed to believe that weight management isn't a hormone problem, it's due to gluttony and sloth. The evidence is starting to mount that it's more complicated than that.

From the Telegraph article...

'The job of determining how fuels will be used - whether we will store them as fat or burn them for energy - is carried out by the hormone insulin with LPL,' says Taubes. 'Because insulin determines fat accumulation, it's quite possible that we get fat not because we eat too much or exercise too little, but because we secrete too much insulin.

Regardless of the underlying reason, here's hoping Steve recovers.

With great sadness, I see that Ted Rogers has passed away.

I worked for Rogers Communications from 2002 through 2004 in a somewhat senior position (2 levels away from Ted). That company was inspirational in some ways, chaotic in other ways, but it all seemed to hold together, mostly out of Ted's ability to express a vision and dive into the grittiest of details to make it happen.

RIP, Ted.

My final presentation for the week is up on SlideShare.

At first I was worried this might be a bit too "out there" , but feedback has indicated the presentation was well received and provocative in the right ways, particularly in getting people working on REST to talk more about areas that have been usually punted, particularly the design of "interaction-oriented" interfaces in hypermedia, using POST.

Great seeing Jim, Steve again, and meeting Leonard and Ian for the first time. Though they left the conference before my session, I also briefly got to meet Tim, and Mark Nottingham, two leaders in this space whom I've long respected.

Over on Cloud Cafe...