@Steve – you make a fair point on the danger of exposing database willy-nilly. But this one is supposed to be for apps, not end users. I.e., the apps are already accessing local databases through SQL; and we’re replacing the database with a distributed one, but with the same interface. In theory, the apps wouldn’t have to change any code other than to switch the data source name.

A friend of mine forwarded me this post. I think we all need to recognize that we are on the cusp of the next generation of computing. As such, assuming that we get all the same stuff as we do today in existing, physically co-located environments is unrealistic. It will evolve and evolve rapidly. And with server sales falling (IDC), an elastic DaaS model would seem like an attractive offer.

My same friend looked at this as the death of traditional middleware. I don’t think so. I see it as the birth of true extra-prise interoperability. MQ will be around until Christ returns as a carpenter. No one should kid themselves on that (are you listening IBM?!)

Seems like a cool idea in theory, but from a software architecture standpoint, this seems completely wrong. I would never give direct access to my database to third party apps. Heck, not even to my own external apps. A lot of stuff typically happens as data makes its way to a database for longer term storage. That stuff (business logic) is subject to change. Guess what? The database schema is likely to change with it.

This is why we have a layer of abstraction called an API. The API can be versioned to maintain stability while the underlying systems are modified with more agility.

Aside from all of that, imagine how easily your entire system could be corrupted if one application is making unchecked modifications to the underlying data. This seems to be putting way too much faith in fellow developers.