MicroServices architecture:
As per http://microservices.io/, microservices can be defined as an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.
Consider a BookStore webapplication with following operations:
1. Orders
2. Customer Registration
3. Browse books
The application's frontend is in - html, css and javascript along with JSPs, backend is in single Oracle's RDBMS and middleware business logic is in Spring/Hibenate with SOAP/RESTful services. All the layers are part of a single monolith application.
DBMS Schema: Orders, Books, Customers
The problem with above style: Lets say after few months there is an increase in the number of customers that are registering with the website but not all of them are interested in making orders but just to browse the books. In order to scale up to the performance, the whole application has to be scaled horizontally since there is neither an option to individually scale the separate tables(customers and books tables) nor to scale individual middleware services(CustomerRegistration or BrowseBooks) as all the code is in single box.
Solution: Decompose all the services into independently deployable services with database per service.
As per the above design, we can easily scale the services both at AppServers as well as at Database level.
Advantages:
1. Every service can have its own technology stack
2. Teams can independently work with less learning curve
3. Scalability
Disadvantages:
1. Database design and writing queries spanning across multiple databases. The queries become even complex if multiple database systems are of different types - one NoSQL and other is RelationalDB etc
2. Global transactions
3. Increase in remote service calls
REST and MicroServices: Since the services should be simple, we need to design REST services
As per http://microservices.io/, microservices can be defined as an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.
Consider a BookStore webapplication with following operations:
1. Orders
2. Customer Registration
3. Browse books
The application's frontend is in - html, css and javascript along with JSPs, backend is in single Oracle's RDBMS and middleware business logic is in Spring/Hibenate with SOAP/RESTful services. All the layers are part of a single monolith application.
DBMS Schema: Orders, Books, Customers
 |
| Monolith Style |
The problem with above style: Lets say after few months there is an increase in the number of customers that are registering with the website but not all of them are interested in making orders but just to browse the books. In order to scale up to the performance, the whole application has to be scaled horizontally since there is neither an option to individually scale the separate tables(customers and books tables) nor to scale individual middleware services(CustomerRegistration or BrowseBooks) as all the code is in single box.
Solution: Decompose all the services into independently deployable services with database per service.
 |
As per the above design, we can easily scale the services both at AppServers as well as at Database level.
Advantages:
1. Every service can have its own technology stack
2. Teams can independently work with less learning curve
3. Scalability
Disadvantages:
1. Database design and writing queries spanning across multiple databases. The queries become even complex if multiple database systems are of different types - one NoSQL and other is RelationalDB etc
2. Global transactions
3. Increase in remote service calls
REST and MicroServices: Since the services should be simple, we need to design REST services
No comments:
Post a Comment