ElasticVapor :: Life in the Cloud
Contact CloudCamp CCIF Enomaly About Home

Sunday, December 21, 2008

Cloud Interoperability and The Neutrality Paradox

Recently during some behind the scenes conversations, the question of neutrality within the cloud interoperability movement was raised.

The question of cloud interoperability does open an interesting point when looking at the concepts of neutrality, in particular to those in the position to influence its outcome. At the heart of this debate was my question of whether anyone or anything can be be truly neutral? Or is the very act of neutrality in itself the basis for some other secondary agenda? (Think of Switzerland in the Second World War) For this reason I have come to believe that the very idea of neutrality is in itself a paradox.

Let me begin by stating my obvious biases. I have been working toward the basic tenets of cloud computing for more then 5 years, something I originally referred to as elastic computing. As part of this vision, I saw the opportunity to connect a global network of computing capacity providers using common interfaces as well as (potentially) standardized interchange formats.

As many of you know I am the founder of a Toronto based technology company Enomaly Inc, which focuses on the creation of an "elastic computing" platform. The platform is intended to bridge the need for the better utilization of enterprise compute capacity (private cloud) with opportunities of a limitless, global, on demand ecosystem for cloud computing providers. The idea is to enable a global hybrid data center environment. In a lot of ways, my mission for creating a consensus for the standardized exchange of compute capacity is both driven by a fundamental vision for both my company and the greater cloud community. To say interoperable cloud computing is something I'm passionate about would be putting it mildly. Just ask my friends, family or colleagues and they will tell you I am obsessed.

Recently, I created a CCIF Mission & Goals page, a kind of constitution which outlines some of the groups core mission. As part of that constitution I included a paragraph stating what we're not. In the document I stated the following: "The CCIF will not condone any use of a particular technology for the purposes of market dominance and or advancement of any one particular vendor, industry or agenda. Whenever possible the CCIP will emphasis the use of open, patent free and or vendor neutral technical solutions. " This statement directly addresses some of the concepts of vendor bias, but doesn't state bais within the organizational structure of the group dynamic.

Back to the concept of neutrality as a cloud vendor, as interest in cloud interoperability has begun to gain momentum, it has become clear that these activities have more to do with realpolitik and less to do with idealism. A question was posed - should a vendor (big or small) be in a position to lead the conversation on the topic of cloud interoperability? Or would a more impartial neutrality party be in a better position to drive the agenda forward?

The very fact that question is being raised is indicative of the success of both the greater cloud computing industry as well as our efforts to drive some industry consensus around the topic of interoperability. So regardless of my future involvement, my objectives have been set into motion. Which is a good thing.

My next thought was whether there is really such a thing as a truly neutral entity? To be truly neutral would require a level of apathy that may ultimately result in a failed endeavour. Or to put it another way, to be neutral means being indifferent to the logical outcome. Which also means there is nothing at stake to motivate an individual or group to work towards its stated goals. My more pragmatic self can't also help but feel that even a potentially "more neutral" party could also have some ulterior motives - we all have our agendas. And I'm ok with that.

I'm not ok with those who don't admit to them. The first step in creating a fair and balanced interoperable cloud ecosystem is to in fact state our biases and take steps to offset them by including a broad swath of the greater cloud community, big or small, vendor, analyst or journalist.

So my question is this, how should we handle the concept of neutrality and does it matter?

Labels: Cloud Computing, interoperability, standards

posted by enomaly at 1:56 PM

2 Comments :

Blogger James Durbano said...

I believe that as long as the number of people involved is large enough, neutrality will work itself out. For example, if I'm pro-IBM and you're pro-HP, we will each fight for our platforms. The other members of the forum will hear the arguments and collectively we will move forward with a decision. Certainly, some voices may be louder (or carry more weight) than others, but I think in general people recognize when they are being "sold" something. With a number of "sellers" in the market, the "buyers" can compare and contrast and "buy" the best technology.

December 22, 2008 5:22 PM  
Blogger Frank Speiser said...

Contract (social or otherwise) neutrality might not necessarily be a good thing. Cloud computing is rapidly developing and evolving; people are inevitably going to mistake neutrality for commonality. The same problems that rendered the discussion lists at the W3C (bickering about standards at the expense of making the technology work) might come into play. I was on those lists. It got old quickly.

I think cloud platforms should square off in terms of use, availability and interface. Competitors should adapt to what the users request, and add that to their offering. Sooner or later companies will start trying to either open up or build bridges and that'll decide who stays and who goes.

The important thing is to make the cloud (that is, the global/public/wide cloud) useful prior to making it neutral or universal. In my humble opinion, applicability trumps protocol until applicability is hindered by lack of protocol.

So, I say, let 'em fight it out -- and let some people make money by building "neutrality balancers" where it is desired until there's truly a consensus. Otherwise, development will slow and migration out of static machine-to-app architectures will take a lot longer than it needs.

January 4, 2009 10:44 AM  

Post a Comment

Subscribe to Post Comments [Atom]

Links to this post :

  <$BlogBacklinkTitle$>  
<$BlogBacklinkSnippet$>
<$I18NPostedByBacklinkAuthor$> @ <$BlogBacklinkDateTime$>

Create a Link

<< Home

About Me

My Photo
Name: Reuven Cohen
Location: Toronto, Canada

Reuven Cohen is Founder & CTO for Toronto based Enomaly Inc. Founded in 2004 Enomaly is the leading developer of Cloud Computing products and solutions focused on Cloud Service providers. Enomaly's products include Enomaly ECP, a complete revenue generating cloud platform, enabling telcos and hosting providers to deliver revenue-generating Infrastructure-on-demand (IaaS) cloud computing services to their customers, quickly and easily, with a compelling and highly differentiated feature set. Reuven is also the founder of  CloudCamp (50+ Cities around the Globe) and Cloud Interoperability Forum and has consulted with the US, UK, Canadian and Japanese governments on their cloud strategies. 

View my complete profile

Reuven is also founder of several technology organizations;
> Enomaly.com
> Cloud Camp
> the Unified Cloud Interface Project
> Cloud Interoperability Forum
> Cloud Interop Magazine
> Contact Reuven

(twitter @ruv : Linkedin : RSS Feed)

Subscribe by Email

Enter your email address:

Previous Posts

  • Stephen Pollack leaves PlateSpin but shares the lo...
  • Keeping Grid and Cloud Computing Seperate
  • Cloud Mining & Enterprise Social Messaging (Enterp...
  • Google Cloud Economics, The Quota
  • CCIF on Twitter (@cloudforum)
  • Fire Eagle + XMPP realtime notifications
  • On-Demand Enterprise (formerly GRIDtoday) suspendi...
  • The 2009 Cloud Experience (Repost)
  • Enomaly ECP 2.1.1 Released
  • Enomaly Appoints PlateSpin Founder Stephen Pollack...

Search Site



follow me on Twitter

Twitter Updates

    Subscribe to
    Posts [Atom]

    > Disclosure Policy