Salesforce.com has announced database.com (The Register, SecurityWeek) , ‘The Enterprise Cloud Database’. It would seem that they have put an API (REST, SOAP, JDBC) on top of a relational database (with Oracle underneath?), built a funky web based table designer front end and plonked it on the cloud for everyone to use.
Anybody who has ever built an application knows that the rate at which you can transfer data (in terms of latency and throughput) between the application and the database is probably one of the most important architectural considerations. We have spent years agonising over efficient database protocols and where to put our data – on a separate machine, on the local (web) server, in a cache, on a queue etc.
So now, because of the magic of cloud computing, Force.com would have us believe that those considerations are irrelevant because we want scalability, automatic backups and other drivel. Under what situations would anyone build an application with it’s database over there, hundreds of Internet hops away where we talk to it would some bloated protocol such as SOAP with all of it’s angle bracket tax? In mobile apps? Barely, a good mobile app still needs an application server to serve up its data in order to work properly. At a push there may be some niche markets such as serving up commercial datasets as Microsoft is trying to do with Dallas.
It seems that Force.com/Database.com is confusing RESTful APIs (which are APIs to an application and its related data) to full-on RESTful API access to a complete RDBMS. If I were to use a remote database, then I would probably use MongoHQ – at least the model will be closer to my application model and I can access full entities.
Look at this diagram below from database.com and tell me if you can spot any architectural flaws..
I am sure database.com will pick up some suckers/customers but it is architecturally flawed and a waste of a domain name that could be put to better use pushing something useful.