The traditional 3-tier architecture is dead, or at least its dying quickly. In a traditional 3-tier web architecture the tiers were defined as:
- Database: A relational database including stored procedures inside the database
Each tier had a specific job to do:
– Client: render the UI
– Server: business logic (controller) plus generate updates to the UI (view) based on queries run against the database (model)
– Database: data access and storage
So what’s changing? Literally, everything. Every layer of the stack is undergoing a massive change that necessitates a change to the architecture.
Client to UI/UX
Node.js has emerged as the go-to solution for UI/UX server-side API development, although other scripting languages such as Python and Ruby remain popular choices. Essentially, a Node.js API (or equivalent) is a thin API layer that represents the Model portion of the older, monolithic server-side frameworks.
Further, mobile development for iOS and Android require a UI/UX API. Consolidating this new API requirement within the UI/UX team allows all customer facing application development to move at a faster pace.
Server to Services
TL;DR: The older server-side MVC monoliths have been broken apart into specialized functions. The Model layer has been pushed down into Data Services, The View layer has been pushed up into the UI/UX team, and the Controller is now an entire Services API layer that provides common functionality that is used by multiple apps.
The traditional server-tier has been broken apart into specialized functions. Traditional server-side frameworks consisted of an MVC architecture (Model, View, Controller). These older applications were monolithic code bases that did everything from querying the data layer, running business logic to rendering UI components.
As discussed above, the View portion of server-side MVC has been taken over by the new UI/UX API server.
The traditional MVC server-side frameworks have given way to a more specialized business logic layer, which consists of APIs capable of handling various service-oriented functions. The new Services APIs consist of common Platform Services plus reusable app Services APIs.
The Model layer, or server-side data access layer, has been pushed into a new layer known as data services. Data Services is the newly evolved data team. We’ll discuss the data layer more below.
While it may appear that the server tier has been reduced in scope, the reality is that the Services API layer is the core infrastructure team. Neither the UI/UX layer nor the Data Services layer would be able to develop functionality as quickly as they do without the platform and shared services delivered via the Services API tier.
Database to Data Services
TL;DR: Data storage and query is undergoing a revolution.
Much as the client layer has undergone an explosion of capability, the data layer now consists of a myriad of technologies.
Live was easy for the data team when relational databases were the only option. RDBMS’ provide a fully integrated data environment, complete with the SQL query language, an integrated query engine, stored procedures, logical abstractions and physical storage.
However, the modern data layer consists of a multitude of specialized data components that often separate the query language, the query engine, logical abstractions and physical storage.
Let’s use Cassandra as a quick example. In Cassandra, data engineers write queries using CQL. However, to actually run CQL the data engineer must embed the CQL in Java, Python or another supported language. So, now the data engineer requires an execution environment for their query code and they must give access to the query layer to the Services team and the UI/UX team. The obvious solution is for the Data Services team is to run their own Data Services API layer, which is exactly what has happened. Contrast this with an RDBMS where all a stored procedure is embedded inside the database and the API is the stored proc’s function signature.
The traditional 3-tier architecture of client, server and database are being replaced by new tiers that more closely align with modern applications:
– Data Services.
The Services layer is now more specialized as the view layer has been pushed to UI/UX and the model layer has been pushed to Data Services. This enables the Services layer to focus on what it does best, which is write advanced business logic and provide platform services that are common across multiple apps.
Data Services, which was previously confined to relational databases, now runs multiple data storage technologies, just one of which is a relational database. Data Services now runs its own API layer as well.
These changes align well with modern application development and help accelerate development cycles. UI/UX can deliver client functionality faster by leveraging the core infrastructure provided by the Services team and owns it’s own server-side API to quickly integrate the data provided by the Data Services team.