“Perhaps ironically, the less Amazon do themselves, the more popular AWS will be. Instance-based clouds are portable… unlike the fabric offerings of Amazon competitors. What other firms see as a weakness (“not enough IP in AWS”) is actually a strength…”

That is what I said in an email to Alexis Richardson and the ESME team the other day, talking about Amazon Web Services and some comments CTO Werner Vogels made at SXSW about the AMQP messaging protocol.

It was my business partner Stephen O’Grady who made the simple Instance vs Fabric distinction, and I find it pretty useful in contextualising the cloud. Of course any instance cloud has some fabric qualities, and any fabric also has some instance to it.

When you look at the market though its pretty clear the fabric players are suffering from feature-itis.  No surprises there given cloud definitions are so flaky, but in the meantime Amazon is just getting on with it.

Compare and contrast with other players.

Take the Google cloud fabric, otherwise known as App Engine. Google seems to be puttering around, in some cases carrying out science experiments like porting Jaiku to AppEngine, before working out it doesn’t know what it actually wants to do with it (“Google will no longer actively develop the codebase”).

Or lets consider Microsoft Azure – the fabric fell down for 22 hours last weekend, but seemingly noone noticed. Azure is in limited beta, and so on… but my question for Microsoft is: why not just offer some Windows machine instances for developers to deploy to, a kind of simple Azure onramp? Note to self: ask Amazon how Windows in EC2 is going. Its especially surprising that Microsoft is delivering something that requires developers to learn a bunch of new methods because normally the firm is all about backwards compatibility. The beauty of instance simplicity is… no new skills.

The problem with fabric complexity is the promises being made: “your apps will scale linearly”.

What about the enterprisey types? Salesforce.com is clearly the most successful fabric play at this point, by some margin. Third parties like Coda have built entire financial applications, namely Coda2go, from the ground up to run on Force.com.

I have had some interesting chats with some senior technical leaders at companies like IBM and SAP in the last few months who have been dismissive of the Amazon Web Services cloud offerings. My favourite comment – “there isn’t much IP in there”.

Not much IP perhaps. But check out the success. I have seen all this before. A few times. There was a time IBM thought the Oracle database couldn’t threaten its own Mainframe DB2. IBM later ceded x86 virtualisation to VMWare partly because it thought there “isn’t much IP in there”. IBM invented virtualisation- no upstart was going to be able to do what IBM could. Maybe not- but perhaps virtualisation has some different roles to play.

Amazon is the new VMWare. The adoption patterns are going to similar. Enterprise will see AWS as a test and development environment first, but over time production workloads will migrate there.

IBM now supports AWS (check it out, it really On Demand!), joining Adobe and Oracle. None of these programs required code rewrites. That’s the genius of AWS. The Amazon blog talked to the Oracle offering like so:

What does this mean? Instead of budgeting for and acquiring hardware, setting it up, installing an operating system and several layers of complex packages, you can simply launch one of these AMIs on EC2 and be up and running in minutes. This is definitely no-fuss, no-muss application development and deployment.

Amazon isn’t the de facto standard cloud services provider because it is complex – it is the leader because the company understands simplicity at a deep level, and minimum progress to declare victory. Competitors should take note – by the time you have established a once and future Fabric infrastructure Amazon is going to have created a billion dollar market. And what then? It will start offering more and more compelling fabric calls… People will start relying on things like SimpleDB and Simple Queue Service. Will that mean less portability? Sure it will…

Brandon Watson from Microsoft alludes to the dynamics I am describing here.

I think the key takeaways would be that Amazon has built some very cool technology and they continue to innovate.  However, that must be tempered with some cost considerations (tied to growth) and the fact that the platform itself doesn’t solve any hard problems for you.  Google, on the other hand, has little in the way of cost concerns (they have a stated goal of supporting up to 5 million page views for free), but what you can do with the framework is pretty limiting in the context of the richness of applications now possible.  Lastly, Azure is a contender, but we have some things yet to prove, and of course, we are late to the game.

Italics mine. Doesn’t solve any hard problems… but instant server provisioning… is a hard problem that Amazon is solving. Lets worry about magic applications later.

disclosure: Adobe, IBM and Microsoft are clients.