The new 2-tier client-DaaS architecture

The new 2-tier client-DaaS architecture

Summary: 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, cutting out the need for an application server in between.


In a guest post here in January, Matt McAdams critiqued's database-as-a-service offering,, which I had previously lauded. McAdams, who is CEO of PaaS vendor TrackVia, successfully argued that you wouldn't want to use 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.

Topics: Servers, Cloud, Hardware, Mobility

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • RE: The new 2-tier client-DaaS architecture

    I respect Lori's opinion - she provided me helpful information for an article that I am writing about Adobe Flex client/server security - but I would not put application logic in a JavaScript or HTML5 application. The application logic should not be be available for casual exploration.<br><br>A client/server application, with sensitive business logic on the server, is inherently more secure. I agree that smart/fat/rich clients are good things, but Flex/Flash, Silverlight and JavaFX can all be decompiled so they are only slightly more secure than JavaScript and HTML applications.<br><br>Also, business logic should not be stored in the database because business logic and data do not necessarily evolve in step. Separation will still be required in the future, or yesterday's business logic will hinder tomorrows new application requirements.<br><br>End-to-end client/server security is an involved subject. I'll tweet when my article is published.<br><br>Mike Slinn<br>Twitter: mslinn <br><a href="" target="_blank" rel="nofollow"></a>
    • The database is the right place for logic

      "Also, business logic should not be stored in the database because business logic and data do not necessarily evolve in step."

      There are significant advantages in representing business logic in the database in terms of productivity, reliability and performance.

      I agree with the general idea that in a modern cloud environment the application server is essentially redundant.
  • DreamFactory

    Phil, the DreamFactory guys have some very cool things going on. I don't know if I'll do a directed post specifically about DreamFactory or not--I tend not to do "review" sorts of posts.

    But their FatSaaS architecture is fascinating and they have considerable commercial success. There is even reason to believe they may be the most successful AppExchange players.


  • RE: The new 2-tier client-DaaS architecture

    Phil - back in 2006-07 I did some proof-of-concept work with my current employer (Thomson Financial) whereby I used the Thomson databases and APIs as the DaaS layer with the application layer 'running' within as a custom application.

    I think the point you made is spot on - doing things the old way on new technology is only going to disappoint you. At the time, what I was doing was I believe the future model for application development - keep apps and data-layer separate. With this approach, you can build your app layer where it best meets user needs (desktop, browser or mobile) and still access the data centrally. Further, each app controls the information it accesses and how it accesses it. Each application is optimized and the data remains in one spot keeping a tight lid on access, security and maintaining a single copy for the enterprise.

    Like you, I'm a buyer for It needs some work to be fully ready but its a huge step in the right direction.