Results tagged “cloud”

I've uploaded my position paper for the OOPSLA 2009 Cloud Design Workshop next week. This provides a detailed technical overview of what Elastra has been working on for the past year.

Cloud Computing has been a catalyst that has been accelerating a long-needed convergence between IT Operations and Application Architecture. We need to build systems to be operated, managed, and governed -- not as an afterthought. And we need better collaboration between IT specialists. Through a mix of web architecture, and a dose of autonomic computing, and we may have the beginnings of a new inter-cloud architecture. It feels like the end of a marathon, but we've only reached the first checkpoint.

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.

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)

and of course, everyone's favorite...

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.

Over on Cloud Cafe...

Another day, another conference...

The slides from today's session are available on SlideShare. This session was almost ridiculously jam-packed, with standing room overflowing into the hallway. I think it went well -- thank you all for attending.

2 sessions down, 1 to go!

Thanks to all who showed to the tutorial; a packed room, and we didn't get through all the material, but fear not, it is here!

Content is available on SlideShare; a PDF download is available here:

QCon2008Tutorial.pdf

My critique of both a recent CACM article and one of the author's blog entries, regarding Cloud vs. Grid interfaces, was quite long, and I've been told, meandering.

Here is a pithy summary of my position:

1. The greatest leverage in system architecting is at the interfaces. The greatest dangers are also at the interfaces. [1]

2. When the components of a system are highly independent, operationally and managerially, the architecture of the system __is__ the interfaces. [1]

3. For networked applications, there are many different styles of interface, including APIs, to message exchange contracts, to hypermedia. These drive very different emergent properties in the resulting system.

4. Loosely coupled systems are assisted by the projection of both object state AND available state transitions. Hypermedia is a suitably general model to enable this.

[1] This is just a paraphrase of Maier & Rechtin regarding key heuristics for systems architecture. For a summary, see this paper.

Updated: Instead of reading my specific nits here, you can see a brief summary of my suggested guideline to designing a cloud interface.

Ian Foster, Savas Parastatidis, Paul Watson, and Mark Mckeown have an article in the latest Communications of the ACM comparing WS-ResourceFramework (WS-RF), WS-Transfer (W-T), RESTful HTTP, and "no convention" as approaches to modeling state.

Look Inside >> September 2008

This article was particularly timely, as it is very similar in approach to my "Managing Data in an SOA" talk at Jazoon 2008. (A better formatted PDF copy of that presentation is available here.) Jazoon is primarily a Java conference, so I got the impression that about less than half of the room had even heard of the Web Services specifications I was talking about, let alone the tension among them, due to how much they overlap. Roy was in the crowd, offering the one audience comment at the end: "Given all of this, which approach would you recommend, or are you using, for your own work?". Much of Elastra's work in managing and provisioning clouds is based around a hypermedia architecture, with RESTful HTTP being our chosen framework. I'll be talking more about this at QCon San Francisco in November.

With regards to this article, I first want to commend the authors at trying (noticeably) hard to keep the discussion technical and respectful, and I hope my comments here will be also taken in that vein, even if I'm being negative. I've long respected their various blogs . The article is certainly a step up from entries such as this one, on "Web Fundamentalism".

My first comment is that the article might be misnamed. In a paper on "modeling state", I didn't see the word "transition" mentioned once. This seems to be a major limitation of this discussion. The authors clarify:

First, a few observations about what we mean by modeling state. The systems with which we want to interact may have simple or complex internal state. Various aspects of this state may be exposed so that external clients can engage in "management" operations....We are not suggesting these mechanisms provide direct access to the underlying state in its entirety. Rather, we are assuming the principles of encapsulation and data integrity/ownership are maintained.... It is unwieldy to keep talking about "modeling a projection of underlying system state," so we use the short- hand "modeling state." It is important to bear in mind, however, the reality of what could be going on behind the boundaries of a system with which an interaction takes place.

That helps to some degree, but it still seems to miss the major point of why it's useful to project state independently from the underlying system: to loosen the coupling of interactions in a distributed system. Interactions lead to state transitions. Besides the state data itself, the available state transitions also can be projected. REST's approach to this is "hypermedia". Object-oriented designs use the state pattern to project such interactions without requiring client coupling. As far as I can tell, the other approaches don't have a clear answer to this. The "No Convention" approach is the worst culprit: potential transitions are tightly intertwined in whatever domain-specific data identifiers, operations or model is being accessed. On the other hand, both WS-RF and WS-Transfer could enable a form of hypermedia with embedded WS-Addressing Endpoint References (EPRs), but this has a variety of problems that are discussed below (some have called this approach "REST on Crack").

I note that if all you want (or all you see) when contrasting these approaches are a system with consistent CRUD operations with an independent, interoperable data format, a lot of the debate between these approaches seems rather obtuse. But complex systems are better modeled as "state machines" than as a state space that can be "managed" with CRUD. This seems to be the major missing piece of the debate - a misunderstanding, underappreciation, or disinterest on modeling state transitions or lifecycles when accessing or manipulating state. Ian Foster's most recent blog entry claims that (in the context of grid vs. cloud):

No evidence is provided for this assertion that complex interfaces are the reason for the difficulties people have with grids. I argue that the issues are more complex. "We can argue whether we prefer REST or Web Services, or say Nimbus (a grid virtualization interface) or EC2 (a cloud virtualization interface), but the differences among these alternatives are not great."

This blog entry seems to demonstrate Mr. Foster really doesn't understand the differences between these interface types, and seems to be referencing this CACM article as a way of brushing this observation under the rug.

Speaking as someone who's designing and building cloud servers, I've made a snide comment or two on this topic this before (e.g. in one of Greg Pfister's presentations, see slide 2). I think there's a lot of thought value in Globus Grid specs, but the totality has a feeling of scientific computing that most IT people generally can't wrap their heads around. The WS-RF interfaces encourage early-adoption developers to give up because they can't easily call the APIs. Amazon EC2's success is largely due to its "retail experience", but also due to the ecosystem of tools and providers that has developed around it. This ecosystem would not have happened had its interfaces not been very, very simple. I'll admit that EC2's REST API doesn't quite use hypermedia the way that I am discussing here -- a future post (around the time of QConSF) will explain a more hypermedia-oriented approach to representing cloud resources.

The rest of this post gets into the gritty details of my issues with the article.

A couple of areas of agreement that I have with the article:

1. The "no conventions" approach to state management has major drawbacks.
   

   
   While the article doesn't say this outright, it certainly hints at this position. In my opinion, if you MUST use WS-*, and you need a consistent CRUD model, then you probably want to look at WS-Management.

2. The value of lifetime features, such as WS-ResourceLifetime, or subscription features.
   

   
   While I don't think lifetime management necessarily warrants new methods, I do think there's value in having a consistent way of specifying a resource's lifetime. This can be mapped on existing methods & response codes, if a media type were created for it. An expired HTTP resource could return 410 Gone, for example. HTTP-based subscriptions happen all the time, though I admit a more precise hypermedia model would be useful.
   

Unfortunately, there are many points of confusion or contention with the article:

1. Misunderstanding what a uniform interface means.

   "According to REST, a small set of verbs/ operations with uniform semantics should be used to build hypermedia applications, with the Web being an example of such an application."

   "REST = verbs" is a red herring. We cleared this up recently in another episode of minor blog drama. Uniformity has to do with URIs, Resources vs. Representations, self-description, the general applicability of all methods to potentially all resources, and the big one, hypermedia. Or, in implementation terms, one has to look at more than HTTP to analyze REST -- there's URI, MIME, and media types like HTML and Atom.

2. Conflating POST with "Create".

   POST means whatever the hypermedia specification that calls for its use says it should mean. In AtomPub, it means "create". In HTML, it means "process this form". It might be emulating GET. It might be appending something. You don't know unless you know the hypermedia context it was linked in.

   HTTP is not CRUD. REST is not just file storage.

3. The utility of accessing and manipulating partial resource state.

   This is less of a point of confusion, and more of an additional critique against something like WS-ResourceProperties.

   Accessing partial state, like one can do with WS-ResourceProperties or (while it's not mentioned in the article) WS-ResourceTransfer with XPath fragments, makes the data model a lot less uniform, and a lot harder to work with. William explains this quite well.

   As an aside, I note that HTTP has the Range header for accessing partial state of a large representation; this wasn't discussed in the article.

4. Suggesting that RESTful HTTP requires "convention over specification". (Aka. Ignoring the hypermedia constraint)

   "Note that whereas HTTP defines all the verbs used, the structure of the URIs and the format and semantics of the documents exchanged in order to implement the job service's operations are application specific. Thus, while the URIs appear to convey some semantic information based on their structure (for example, a /status at the end of a particular job URI may be interpreted by a human as the identifier of the status resource), this is an application-specific convention. "

   And again in the summary:

   Thus, when defining state management operations, the WS-RF and WS- Transfer approaches both use EPRs to refer to state components and to adopt conventions defined in the WS- RF and related specifications and in the WS-Transfer and related specifications, respectively. In contrast, the no-conventions and REST approaches adopt domain-specific encodings of operations, on top of SOAP and HTTP, respectively.

   This is a bad practice, and not indicative of robust REST approaches. Normallly one would use specifications like:
   

   
   
   • HTML form submission
     
   • XForms submission options
     
   • Atompub service documents
     
   • URI templates
     
   
   to describe how a URI (or, very commonly, an entire representation!) is constructed. Arguably none of these are "application specific", or even "domain specific". They're "binding environment specific" (e.g. they each have a different underlying object model), because RESTful doesn't assume an XML Infoset binding model the way WS-RF or WS-RT do.

   One should think of form hypermedia as "just in time interface description". Instead of coding against an operation like in RPC, you're coding against a message destination (the POST target), whose intent is hopefully described by the surrounding metadata. In practice, this is normally no different than most reflection-assisted RPC (e.g. CORBA DII , Java RMI with reflection, dynamically invoked WSDL, etc.), though eventually if RDF takes off one might see even richer forms of reflection than just "symbol lookup".

5. Confusing URIs with EPRs (and Skipping over WS-Management, which offers a resolution)

   One of the co-authors of this CACM article, Mark McKeown, describes in a 2007 blog entry the problem with EPRs:

   ...given an EPR that has ReferenceParameters you should NEVER share it with anyone else. You cannot know what those ReferenceParameters are for. They could be there for some identification purpose, in which case it would be OK to share them, but you cannot know that for sure. They could actually be for identifying a particular session, or client. Sharing EPRs with ReferenceParameters would be like sharing your HTTP cookies; you simply wouldn't do it. Now, imagine a Web were you were not able to share URIs.

   I wasn't involved with the standards work for WS-Addressing, WS-Resource, or WS-Management. But, as a potential consumer of these specfiications, here's what I understand of the mental journey:

   
   
   1. URIs are identifiers.
      
   2. EPRs are not identifiers. Quoth section 2.6 of the spec:
      

      
      The Architecture of the World Wide Web, Volume One [AoWWW] recommends [AoWWW, Section 2] the use of URIs to identify resources. Using abstract properties of an EPR other than [destination] to identify resources is contrary to this recommendation. In certain circumstances, such a use of additional properties may be convenient or beneficial; however, when building systems, the benefits or convenience of identifying a resource using reference parameters should be carefully weighed against the benefits of identifying a resource solely by URI as explained in [AoWWW, Section 2.1] of the Web Architecture.
      

      
      
   3. WS-Resource claims EPRs are identifiers, ignoring the advice of the WS-Addressing specification,
      
   4. WS-Management, the major spec that adopts WS-Transfer, introduced the wsman:ResourceURI reference parameter to remain consistent with the WS-Addressing recommendation, at the expense of admitting that they now have TWO URI's in the header, one for the "endpoint", and one for the "resource".
      

   The moral of the story: Most technical decisions are a reflection of the economic and political context they were made in.

6. Confusing the relative sizes of deployment base

   Proponents of the HTTP/REST approach empha- size that it provides for more concise requests and permits the use of sim- pler client tooling than approaches based on Web services. Critics point out that the use of HTTP/REST means that users cannot leverage the signifi- cant investment in Web services tech- nologies and platforms for message- based interactions.

   While I agree there has been significant investment in Web services technologies,
   

   
   
   1. the vast majority of it does not use WS-Addressing,
      
   2. an even smaller fraction uses WS-RF or WS-Man (which leverages WS-Transfer)
      
   3. even without this, it is probably several orders of magnitude less than the amount of deployed HTTP-based hypermedia technologies.
      
   
   Now, granted, there is not much in the way of HTTP/REST tooling that's specifically targeted at advanced enterprise use of that technology (such as interaction or business process management), but given the context of this article is on "state management", this counter-argument doesn't really apply.

   WS-RF is a world onto itself, with no bridges to the World Wide Web. WS-Management at least tries to remain consistent with the web architecture by exposing a visible EPR Reference Parameter with wsman:ResourceURI that could be dereferenced via HTTP.

   In this debate, the real question is how "general" distributed hypermedia is. Can it be used as a general-purpose systems architecture? Is it, in many cases, a superior set of constraints to just "contracted message exchange"? That's the core of the debate, in my mind.
   

In summary, while I appreciate its tone of this article, I think the content was very selective in its omissions, and as such should not be seen as a definitive analysis of "modeling state" with these specifications. I really hope it wasn't written to drive a political debate underground, but its primary author seems to be using it in that way based on what I read of his recent blog entry. The result would lead me to interpret this article as well written sophistry. It should, rather, serve as a useful starting point for continued discussion and improvement of our technologies.

I've been quite busy this past month organizing a move of my girlfriend and I to San Francisco, but just a brief note for those that skipped my rather mysterious post on February 29th....

After 3.5 years at BEA, I've decided to jump to a new startup in the cloud computing space, called Elastra, as a lead architect of their product line.

Today, Elastra provides the software to provision clustered, highly available MySQL, PostgreSQL, and EnterpriseDB on Amazon EC2. The vision is to take this to multiple layers of an application stack (App servers, Mongrels, BPM engines, Integration engines, etc.) , adding in simulation and modeling, for different underlying utility infrastructures, whether public clouds like Amazon EC2, or private clouds like your in-house VMWare or Xen installation. I also think some surprises will emerge, as we explore with our customers what it means to be in "the cloud".

p.s. I have an "ode to BEA" entry coming soon, stay tuned...