No, that isn’t a homophonic mistake.

Dan directed my attention to an interesting article recently, “Are 3-tier web architecture models too rigid?” in which the author postulates pig that “maybe it is time to finally break out of  the old 3-tier web architecture box and retire the concept…”

In addition to a great mention of F5 and an “application delivery tier” in web architecture models (the concept of which deserves its very own blog post), the author inadvertently, I think, brings to the fore one of the reasons SOA might have failed to dominate the world: service inequality.

Most web service managers and architects I talk to describe their architecture as a "3-tier" model, meaning they have a web server tier, and appserver tier, and a database tier.  However most such architectures in fact turn out to be much more complicated with ESB components and other connectors, access control services, mulitple layers of data sources, firewalls, intrusion detection systems, audit servers, disaster recovery support and more.   Sure there are pieces which fall neatly into one of the classic three tiers.  However there are a lot of gray areas, side-bars, and odd pieces in the typical architecture as well.

Tiers. Tears. Ever wonder that perhaps there’s more of a relationship between these two than just the phonetic similarities? Tiers implies hierarchy, which implies priority and importance. Web server > Application server –> Database. A traditional 3-tier web architecture, defined hierarchically based on the order in which their respective services are invoked. The order also implies dependency: the web is dependent on the application is dependent on the data. All good there.

But it also treats “lower tiered” services in a SOA as, well, of lower importance. Even though SOA ostensibly raises everything to the same level of simply “service”, still application and database services are treated as ancillary when in reality the order ought to have been reversed: data is the lifeblood of the organization, and thus applications and the web are really useless without it. But SOA didn’t do that, or at least those who adopted SOA as the core of their enterprise architecture didn’t do that, and thus the 2nd and 3rd tiers of the “architecture” were replicated in perspective, if not reality. And if that’s not enough to evoke tears from an architect truly dedicated to a service-oriented anything, I don’t know what is.

As George Orwell might have said, some services are more equal than others. Some got more attention, more care and feeding, and others were viewed with all the respect of plastic tableware: disposable, replaceable, peculiar to one meal (application) and then discarded. They weren’t nearly as reused as “higher order” services, and thus the consistency that might have arisen from the use of the same data services across an organization was never achieved and the benefits resulting from such consistency never realized.


WHY CLOUD MIGHT SUCCEED WHERE SOA FAILED

I have argued, and will continue to argue, that the “customers” of cloud need to understand what’s behind the curtain in a cloud infrastructurebuffet infrastructure. That’s still true. The end goal of cloud and particularly Infrastructure as a Service (IaaS) is to allow customers to build an architecture that is best suited to scaling, securing, and delivering the applications they will be deploying and that requires a bit of understanding about how that’s going to be accomplished. It may never be as drag-n-drop as I’d like, but that’s a goal, not a requirement, and simply encompasses the desired end-result: choice in infrastructure services including network, application network, and application.  All services, equally available and equally presented in that grand technology buffet that will be, hopefully, “the cloud.”

Cloud has the potential, even more exciting, to elevate those services – such as those in the network and application network infrastructure – to equal status with other services. Such services may be provided by a router, or a switch, or an application delivery controller, or a load balancer, or what have you. It doesn’t matter that such services take not the physical form developers are used to seeing – namely hosted on a software platform. It is still a service, offered by the cloud provider or a third-party provider, and it can be included at will without concern for which tier in the architecture it should reside.

Cloud may succeed here because deployment of all services is viewed as flat, without the typical solutions physically residing between each tier to provide scaling services. The data service and the presentation-layer service may be residing on the same physical hardware and scaled by the same physical device. They become equals by virtue of the fact that we aren’t replicating our enterprise architecture Visio diagrams in physical form. This may sound like a trivial thing but it’s not. The mere perception of where something resides in an architecture tends to reinforce a hierarchical approach.

This is important because the network and application network infrastructure “tiers” have long been viewed as “beneath” the application, just as data services and common but not critical business services have been viewed as “lesser” services when compared to those that made up the core business model. But those infrastructure services – particularly in the cloud – are just as important to the successful implementation and subsequent delivery of applications to customers as the application itself. By removing the tiers physically from the cloud and flattening the deployment model, cloud can effectively provide an even playing field for infrastructure services to be viewed on the same level as application services. In the cloud Visio diagram they’re equal, and there’s no hierarchical constructs to impose priority of either service over another.

There is a difference between data flow paths and tiers, and the elimination of a physical architecture that tries to closely replicate a design model can break the bonds that have too long tied them together. Data must flow in a certain way and dependencies considered, but every service that is involved in that data flow is equally important. If any one of them failing results in the application failing, then they they are all of equal value to the application.

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share