Redefining the 3-Tier Architecture

It’s time to sit by the fire, grab some hot cider, and listen to a story. No, this isn’t Are You Afraid of the Dark? fan fiction. On second thought… for some us, this is a horror story. 👻 Don’t worry. It ends on a good note, with some thoughts on how the API landscape has changed the way we design applications.

Once upon a time, established software principles dictated a very simple model of delivering line of business applications. We called it the 3-tier architecture, a self-describing little thing named before software vendors learned to influence human psychology with buzz words.

It made sense, a logical separation of concerns — as we say in design pattern books — and it reflected a big change that was already underway.

As time progressed, databases maintained the desire for single-machine consistency and availability. User interfaces were migrating from terminal emulators to more modern desktop (and eventually) Web experiences. This represented a conflict. How do we get mainframe data outside the terminal emulator? Part of this migration path involved moving logic out of the mainframe and into application servers, often with VT100 compatible terminal emulators connecting directly with programming language APIs via libraries.

Okay, wait… isn’t all of this very boring? Maybe. But that’s a trait associated with line of business applications. Boring is a long-term survival strategy for software architecture. 🙃

Increasingly, logic had to move closer to the client and farther from the data. This brings us to the fundamental desire for the aforementioned 3-tier architecture.

• Presentation tier - Consumes logic produced by a Web or application server, carefully crafted to create the ugliest Web sites we’ve ever seen.
• Logic tier - That darn application server. It’s really this tier that spawned a new breed of Business Process Management software and integration tooling.
• Data tier - Pick a favorite monolithic database: Oracle, MySQL, Microsoft SQL Server. Apologies if some of these names induce anxiety.

Let’s hold on to our britches, because we’re getting to the good part. Everything has changed.

Scrubbing the timeline a bit, skipping past some difficult years — SOAP vs. XML-RPC, MongoDB vs. CouchDB — let’s look at some motivating aspects to the latest cool kid architectures. 😎

From the perspective of a multi-tiered application architecture, our human-facing interfaces are being driven by APIs. Based on Postman’s 2021 State of the API Report, 49% of respondents said that more than half of the organization’s development effort is spent on APIs. This is astronomical and represents an evolution that’s been steadily growing around us.

We have arrived at a place of dumb connectors and smart components with respect to business logic. We are just now ingesting the concept of API-First. There are benefits to putting more smarts in the messages, but that’s a different campfire story. 🏕🔥

Application developers are now often specialized in front-end vs. back-end, with a few of us shifting contexts as full-stack developers. In retrospect, this was all inevitable. The success of the medium was indisputable. As a result, the Web got smarter. And we all grew with it.

So what do we do with all these line-of-business applications as we move forward into solving new century problems? Well, as it turns out, API Gateways are the new VT100 terminal emulators. Let’s look at how this all fits together, how we’ve redefined the 3-tier architecture.

• Experience tier - Thick clients are all the rage. While our slick, new Web apps don’t contain all the business logic, they often contain quite a bit. Decisions are now made in the browser.
• Integration tier - We are utilizing API Gateways and iPaaS platforms to facilitate interaction between our new experience tier and the API data sources we’ve already built over the years. Experience APIs can be pieced together using façade and scatter-gather patterns in the gateway, backed by security, analytics, and message transformation.
• Data source tier - CRUD APIs, database connections, message queues… If it can be accessed over the network, it can be accessed by an API Gateway. The database has become an implementation detail. Microservices have fortified this as the new reality.

We only see more exploration here, as folks look to federation, microservices, and even micro-frontends to achieve a sweet-spot of modularity and centralized data source access when crafting application experiences.

Does this resonate? It does for a lot of folks. Again, we are in a time of migration. How long will it last? Well, the VT100 emulators and mainframes are still around, all these years later.

Transient technology, as it turns out, may never die. 🧟