This comment was originally posted on Twitter

Within each of these mechanisms, clearly, the implementation detail varies and industry standards take over wrt data schemas.

My point is as simple as this. I see a place, in the cloud for REST but I also see it for every other such protocol it’s just a question of agreeing them; but hasn’t the industry being trying to unify major boundaries like this since the beginning of time….the cloud is just the next, in vogue battleground that highlights the fact that we have failed thus far…..

This comment was originally posted on Twitter

REST is the “REST of The Cloud”.

Give us URIs and we can make use of REST/HTTP. As @Mark reminds us, the key point here is HATEOAS — “Hypermedia as the engine of application state”. In the case where “hypermedia” refers to content deliverable using HTTP, this means that *web application execution* works in the same way as *web content navigation*. It has been shown that this is quite a good way to provide web apps and web integration, over the internet.

It’s entirely reasonable to provide this model for cloud applications provided that every resource in the cloud can have a sensible URI that can be resolved through DNS. I’m not sure how easy that is yet — it is not by accident surely that @Stu mentions pervasive NAT. Unlike SaaS, applications provisioned in the cloud, whether instance- or fabric-based, may change location (eg for scale-out, failover). So, some address management is needed and it needs to work with DNS. This can be facilitated by the cloud provider, and/or by using other application protocols than HTTP for some work.

I appreciate that ‘REST’ may not have been meant literally by James et al. It’s about simplicity, right? @Mark talks about a simple reference point: a “canonical cloud architecture” from Hoff. Ironically this architecture is based on queues, which are hard to provide RESTful interfaces for without creating an abstraction leak. @Stu makes the point that any platform/architectural choice (Hoff’s or other PaaS) leads to commitments.. which may *simplify* the end user developer’s cognitive experience, while screwing them over in other ways (eg price/performance) that they cannot ‘get out of’.

So why do customers say things like Amazon is ‘too simple’? It’s not because they care about programming style, even if they share @Mark’s and @Stu’s concerns. It is because they can’t see how to migrate their existing (“complex”) infrastructure, maybe including 100s or 1,000s of applications, over to someone’s (“simple”) cloud. To do so would require change, and change is *always* complex, no matter how “simple” the destination.

Hmm. I see what you mean, but… Consider: what if I just change the wording a wee bit, and out of your text, obtain “Cloud = Architecture for Parallel Resource Resolution”. Because, where you (seem to) see a “job being executed”, I see an abstraction beneath it, where the “job” is just a resource resolution (or chunks of same). Now, you can then promptly accuse me of reading too much into that model, and I will immediately concede the point (I’ve had tuplespaces on the brain ever since reading Carriero + Gelernter, years ago). But, for the sake of argument, if you accept my interpretation for a moment, then…? Do you see what I mean?

Quote: “Whereas there’s a real need for a “system of systems” architecture that solves a collaboration problem, i.e., what is in the space between services?”

Yeah. Is there a real need for that, though? Can you quantify it for me? Let me put it another way: if we say that the model that Hoff’s “canonical cloud” represents is a pattern for the *implementation of services*, then the point you are raising here is “what lies between them”, correct?

So, why can’t I just respond with “whaddya mean, what lies between them? The same thing that lies between any two other URIs.” How would that response (minus the mild snark) be different from “Web Architecture should be the way that various pieces of cloud metadata (standard or proprietary) are shared and linked”?

I sense we are nearing the dangerous ground of debating the merits of a priori service contracts…

Please don’t interpret that I’m advocating that we create some kind of uber/holistic standard that covers every possible element of clouds at all layers. I think there might be room for innovation in _products_ to do that kind of thing (CMDBs, etc.), but there’s little consensus to create a _standard_ of that nature.

What I am advocating that Web Architecture should be the way that various pieces of cloud metadata (standard or proprietary) are shared and linked, if we’re going to make Cloud “different” from SOA+AUTO PROVISIONING+VIRTUALIZATION.