The new 2-tier client-DaaS architecture

Mobile clients could set a trend towards adoption of a new 2-tier application architecture that talks directly to a cloud-hosted database-as-a-service such as Database.com, cutting out the need for an application server in between.
Written by Phil Wainewright, Contributor

In a guest post here in January, Matt McAdams critiqued Salesforce.com's database-as-a-service offering, Database.com, which I had previously lauded. McAdams, who is CEO of PaaS vendor TrackVia, successfully argued that you wouldn't want to use Database.com as the database layer in a 3-tier client-server architecture:

"... web application developers will find the idea of hosting their data outside their application platform severely unappealing. The reason is latency ... If the database and the application code are in different locations, then more than a dozen public Internet traversals are required to complete the request."

That's fair enough, but I felt at the time that perhaps it was missing the point. New platforms are bound to disappoint if you merely use them to replicate what you've always done in the past. While there may be incremental gains from implementing 3-tier client-server apps in a web-delivered model, the real advances will come from doing things differently.

An excellent exposition of how else things might be done was set out earlier this month in a blog post by F5's Lori MacVittie, who explicitly refuted McAdams' argument, writing that "he ignored the architectural model in favor of narrowing in on a specific deployment model."

MacVittie went on to discuss the emergence of a new architecture that puts all the code on mobile devices and talks directly to a cloud database, dispensing with the application server layer:

"Web applications have been getting fatter and fatter with more and more application logic being pushed onto the client. HTML5 appears to support and even encourage that trend. Consider, for a moment, this web application written nearly entirely in JavaScript. Yes, that's right. Nearly all of the functionality in this application is contained within the client, in 80 lines of JavaScript code. That's a client-database model."

This line of argument gets especially interesting when she goes on to point out (echoing my view that In 2011, mainstream means mobile) that the increasing importance of mobile platforms is likely to lead developers to adopt the same architecture for all their implementations:

"An architectural model in which the data access portions are shared — hosted as a service — for both mobile and traditional desktop clients makes a lot more sense in terms of cost to develop and maintain than does attempting to support two completely separate architectural models. Given the movement toward more client-centric applications — whether because of platform restrictions (mobile devices) or increasing demand for functionality that only comes from client-deployed application logic (Web 2.0) — it is likely we'll see a shift in deployment models toward client-database models more and more often in the future. That means data as a service is going to be an integral part of developers' lives."

The emergence of this type of architecture is something I first started speculating about more than five years ago (even then the possibility was floating around in the PaaS environment) and more recently my Enterprise Irregulars sparring partner Bob Warfield has been pushing the notion of Fat SaaS. In fact I'm wondering what happened to that blog post Bob promised us in the wake of his recent call on the folks at DreamFactory, who espoused this model from very early on.

This is still an emerging story — to be continued, so watch this space — but the key takeaway is that, while database-as-a-service offers little of note to traditional 3-tier applications, it may have more of a cornerstone role in the architectures of the future.

Editorial standards