Long long ago, So long ago, some people may know how long ago, monolithic applications were built which hosts both application and data. Because the data resides in one place, even with multiple instance of application, sharing data is a problem.
When relational databases are developed and with advent of client – server model, data is stored in a separate DB and two tier architecture was followed. Application is the client and the DB is at server.
When multiple instances of application was present, they shared the data from the common DB
With two tier architecture, scalability is still the issue, even when there are multiple applications, they maintained connections to DB. Since only one application can commit to DB, Server cannot respond to multiple requests at same time. This can cause Data integrity issue.
Hence 3 tier architecture came into being, with Service Oriented Architecture (SOA) paradigm.
In the original 3 tier architecture, service and DB are at server and application is client side. Business functionalities are abstracted in the service. Service offered caching capabilities and hence DB does not need to be hit every time.
With the advent of web applications, Applications are hosted on server and rendered on browser.
In a 3 tier architecture, application, service and DB reside on the server side. Application gets rendered on client side.
In this 3 tier architecture, application and services can be scaled independently. A load balancer is included in front to balance the load to multiple instances of application.
The load balancer in front of the web app is called External Load balancer as it balances external user traffic from internet
The load balancer which is present in the middle between Web application and services to balance traffic to service is called Internal Load Balancer
This model helped in balancing the web traffic and the service traffic. But the DB was still a single point of failure.
Relational DBs were vertically scaled by adding more memory and CPU. Yes it is termed vertical and memory and CPU were still added on top of same DB.
Approaches to horizontally scale DB were investigated and approaches like Sharding developed where the DB schema and even Data was split into multiple DB. The services will still have to aggregate data from multiple DBs and was not effective in all situations.
Web application, with its backend service and with a single DB was still termed a Monolithic Architecture even when it followed 3 tiers.
Then came the concept of Domain driven design. The application logic was decomposed into multiple domains, each catered by its own Application service. Hence came the Microservices Architecture and each Microservice was responsible for one single function and had its own DB. This helped to overcome the problem of DB scalability in a Monolithic 3 tier architecture.
Microservices were exposed through a Common API gateway, which offered Security, API composition to the microservices and Web applications started calling the Microservices through the Gateway
Each microservice could be independently scaled.
With the advent of Node JS and server side Javascript, Single Page applications started to be developed where the Web application is loaded for single time into browser and the application then continues to run on the browser by invoking the services from server side. This was still successful as the server side services can be called through API gateway offering complete security to the requests coming from browser.
With the advent of Docker containers, the microservices revolutionized the applications. The component in each tier can be containerized and can be scaled independently.
Until now, we have seen Applications were dependent on services which were dependent on DBs. User was able to successfully use the application as long as each of these components are available as the user transactions were synchronous. These were not reliable all the times, as the network can get disconnected sometimes. Hence need for asynchronous transactions arise.
When the web application calls a service, if the service was waiting on a DB transaction to be fulfilled, what will happen if the service encounters a failure. Web application will fail in its user transaction. The user will have to repeat the transaction. This will cause inconvenience to the user. Here is where Messaging frameworks helped in enabling Asynchronous transactions.
Message bus provided a way to persist transactions and in case of a failure, the service does not loose the state, and can resume the processing once they are up . Finally the user does not have to repeat the transaction. Thus came the Message Oriented Architecture. This is a multi tier architecture and not just a 3 tier.
Often services need to talk to each other. This can be accomplished through the Message Bus as well. A Service can publish an event and an other service can subscribe to it. Hence a need for Enterprise Service Bus was established.
Message Bus is more suited for Asynchronous transactions and not for Synchronous transactions. When the user works on an Application, when he persists the Domain data, the CRUD operation needs to be a Synchronous transaction. But the post processing logic of what happens after the domain data is committed like invoking other relevant processing logic, notification, etc are termed Asynchronous transactions. Those asynchronous transactions are well suited for the Message Bus.
This art of one system publishing an event and other system consuming an event and doing further processing is termed Event Driven Architecture
In an Event driven architecture, the handler services do asynchronous processing and updates its own data store. But that data store may not have received the transactional data in the same time when the original services which committed transactions to DB. This is termed as Eventual consistency and is an acceptable factor in Event Driven Architecture.
With the Domain driven concept, even Web applications can be broken down into Microfrontend per each domain and multiple microfrontends belonging to multiple domains can be composed in a shell application and can be rendered.
The advantage of Microfrontend is that individual teams can independently develop a a Microfrontend and can promote all the way to Production without having any dependency on the shell application to be redeployed. This helps in Continuous Integration and Continuous delivery and facilitates the Agile development.
In summary we have seen how a single tier architecture, two tier architecture , three tier architecture, Service oriented Architecture, Microservices architecture, Message oriented architecture, Event Driven architecture and Microfrontend Architecture.
breathesoftware.wordpress.com 