Have a couple of opportunities which I’d like to discuss with you if interested. The=se are hi level roles and in your expertise. If interested, Feel free to send me a copy of your latest resume and a time to call.

Regards,

Ryan.Lum@greythorn.com

Point #1: The name metacloud is actually appropriate in this case; I’m talking about a cloud of clouds. But you’re right in saying prefixes like ‘meta’ get thrown around a lot- often in completely inappropriate contexts- just to get attention. Whatever we call it, what I’m describing will likely come to fruition if history is any indication. Like other technologies built on top of multiple platforms, it will add a lot of value to the cloud as a whole.
The comparison to Linux is definitely far fetched. I needed an example of a technology built on multiple architectures that hides the anomalies among the architectures. So I picked the old standard: Linux. Maybe I could have done better; it’s easy to read more in to this analogy than I did.

Point #2: Actually, I have slapped an abstraction on file storage across clouds- http://simplecloud.org- and it has worked well in every application that I know of. Block devices are a very different beast that aren’t accessed through a web service, so I agree that there won’t be an easy abstraction there. In my vision, user exposure to underlying block devices would become less of an issue as storage services speed up enough to replace them in most storage use cases. And that’s a *long* way off. You’re right that most cloud technologies and services aren’t there yet. But enough of them are to start playing around with cloud portability.

You lose me on the electrical stuff. Damn it, Jim, I’m a software guy, not a hardware guy.

Final point: I’m out on a limb with the convergence point. Truth is, I just wanted to use the Lord of the Rings analogy.
To be clear, I’m not talking about standards. I’m talking about ‘market forces’, as you put it well. And we do see examples of technology convergence: Eucalyptus implementing Amazon’s API in the cloud, on the OS side, Linux (here I go again ) for the most part winning out over other OSs- save Windows Server if you put it in the same class, and HTML as you point out.

We are in the dawn of the cloud, so it’s true that the metacloud is a long way off. But the base technologies are already there for someone to start tinkering with it. I hope to find the time soon.

I’d love to hear what you think about my latest post: Programming the Metacloud.

Thanks for the insight.
,Wil

First off, penning new hyperbolic tags like ‘metacloud’, while a time-honored tradition in the tech industry, doesn’t really help make things any clearer, especially when it’s something that is relatively nebulous. And comparing it to Linux? Like some kind of ‘cloud OS’ just makes things even murkier. There is about zero chance this will happen any time soon. An OS is an abstraction for a piece of hardware. The abstractions that will evolve on top of cloud computing systems are a whole new ball game because of their distributed nature. They will behave quite a bit differently from hardware abstractions. Which brings me to point #2.

Second, the notion that common abstraction layers across different clouds makes developers lives easier is a treacherous notion. Whether you feel the clouds are pimping processors or not, the reality is that every single cloud today has fundamentally different architectures. For example, if you compare GoGrid, AWS, Rackspace Cloud, Azure, Savvis, and Hosting.com approaches to storage you will see a huge number of very different offerings, with different price points, different interfaces, and performance characteristics. You can’t just slap an abstraction on top of on-demand block devices, like AWS EBS, and call it a day. Not all block devices are made equal. Every layer of abstraction theoretically hides the underlying behavior for simplicity, but the flip side of that is that it hides differences in architecture that will cause a developer indigestion if they don’t understand them.

A much better abstraction than the simple libraries you mention, which simply provide a common programming interface and don’t handle architectural differences, are Platform-as-a-Service (PaaS) systems like Heroku and EngineYard. PaaS must deal with architectural differences in order to provide a truly repeatable development environment. This also means, unfortunately, that you wind up with an opinionated environment. That’s the only way to make these work successfully across clouds.

Put another way, the libraries you point to are more like simple circuits that can carry differing electrical currents. The clouds themselves while all providing electricity do so in different ways. Cloud A provides 50Hz 110VAC, cloud B provides 60Hz 208, etc. etc. The libraries you mention simple are wires for connecting these currents together, but you as the user must deal with the differences. PaaS are systems that have current converters in them. Meaning you’ll get 65Hz 120VAC from all of the clouds they support and it will be consistent, but if you need a different type of electricity you are SOL.

Finally, I think the notion of convergence on APIs is an old saw that hasn’t proven true. APIs, libraries, frameworks, and languages continue to proliferate at an astonishing pace. I agree that in many cases, standards evolve or win by fiat (e.g. HTML), but that appears to be the exception, not the rule. Most of the time when this occurs it’s because of market forces. Right now, we’re in the very early stages of the game. Will there be market pressure to converge over time? Certainly, but we’re probably talking 5-10 years out. TCP/IP, one of the hottest technology adoption curves ever, took 10-15 years to establish it’s dominance. We’re in like year 3 with no clear leader except perhaps Amazon, who have shown no or little reticence to allow copying of their architecture or APIs.

I applaud your intentions and passion, but while I think the vision is spot on, I think the tactical situation is much, much different from Linux. Linux could build on a single basic platform (x86) and branch from there. We don’t currently have a single open cloud that can be a reference design.

Some of the best experiences I had at Zend involved the Magento team.

But no tears will be shed; Given the success of Magento, I’m sure we’ll work together again.

,Wil