Three-tiered architecture is a myth. You only think you have it. In reality, you have a two-tiered architecture and a dream.
The “traditional” definition of three-tiered architecture says it consists of:
True three-tiered architecture allows you to scale or migrate any individual layer with no impact whatsoever on the other two layers — you can make a change in any layer without having to change a single line of code in any of the other layers.
It’s a great idea — it sets up a situation where you can plug and play any component cleanly and smoothly.
That is completely true of the web application layer. The development of the HTTP protocol DID create the complete web application layer. It’s completely decoupled from the application and database layers. The HTTP separation of web and app server tiers was more successful because it specifies the protocol.
However, if you think realistically, you’ll see that your application and database layers are not even close to being separate entities. They are so tightly coupled you cannot make any changes to one infrastructure without affecting the other.
Applications and databases have been firmly entwined since the beginning. Unlike “clean” HTTP, database vendors introduced proprietary extensions and implementations of the SQL language. Thus, the SQL language created the unification, requiring a persistence-related application change needed to be reflected in the database and vice versa.
Everything that happened on one tier needed to be reflected in another. When both systems were run on the same server, this accelerated processing, as the information didn’t have to travel very far.
The advent of the cloud changed the dynamics completely — the promise of on-demand scalability could be achieved — except it really isn’t happening.
It’s still nearly impossible to decouple the application server from the database. A single change to one can have adverse effects on the way the two tiers communicate. For example, a change in the database may “break” connectivity to something in the application. SQL may be set up to serve a specific piece of data when the application calls for a “purchase order number,” but an update to the accounting database changes the purchase order number to a work order number, making it no longer accessible to the application. Analyzing code-to-database connections requires extensive static analysis to find all the couplings before anything can be changed.
Instead of directly addressing the coupling issues, companies try workarounds during the transition to the cloud. They duplicate efforts, running on-premises and cloud databases in parallel as they gradually transition functionality. They migrate old data to the cloud database and write to both databases. If no issues occur and both databases are in sync, they later switch over read queries.
That’s great, except:
The secret is load balancing, which plays an important role in the decoupling process. It serves as an “automatic” translator, a middle layer that keeps the communications channels open between the database and the application but completely bypasses the tight coupling, allowing each to scale or migrate as necessary. This simplifies the ability to manage the database-application couplings without causing damage to either. With true three-tiered architecture, your database can easily and quickly “speak” to multiple applications, and your applications can speak with multiple databases.
With database load balancing, each challenge can be addressed to truly benefit from cloud scale. Database load balancing enhances the distribution of workloads across multiple servers. Migration can be eased using intermediary control planes, which translate SQL commands to cloud-active operations without changing a single line of code. Database load balancing decouples applications from their storage, drives operational simplicity, and unlocks massive TCO reductions. The end result is safe migrations with zero downtime by being able to switch reads to the cloud server and switch writes at any time.
Once the migration has occurred, keeping the database load balancer in place provides long-term scalability and stability, ensuring zero downtime during maintenance and reducing the risk of unplanned outages.
A database load balancing infrastructure:
In the long-run, database load balancing makes it easier to manage operations, enabling:
As seen in The New Stack
Rahul Subramaniam is CEO of EngineYard, DevFactory, and FogBugz. He is also Head of Innovation at ESW Capital. He has a long history working in the computer software industry, with a background in algorithms, python, agile software development, and software project management.