You must have been on a train many times in your life, but have you noticed the architectural pattern of the train. Is it Microservices Architecture? let us see.
The trains are the best example of loosely coupled and highly cohesive design architecture. To understand this in laymen language, in a train if engine fails then what needs to be done? correct, the only engine is replaced and your train is on track again. A similar approach is applicable for train coaches as well. It also integrates coaches of the different types, i.e. Air-Conditioned, first class and second class to achieve a single system.
We have seen above a great example and if we map it into our software lifecycle then we come to know that we are moderately talking about microservices.
Microservices architecture is a new trend and well popular among developer now a day to create enterprise applications, in technical terminology, it is also called “Microservices”. So, in this series of articles, we will discuss Microservices in details.
What are Microservices
Microservices is an architectural style in software development life cycle based on SOA (Service Oriented Architecture) to manage and fine grain a giant application. Here application would be a group of loosely coupled lightweight services which are expert in their service implementation and collectively achieving entire application goal. Netflix, eBay, Amazon and many other which have the first approach as monolithic but now using Microservices architecture. It is very compatible and adapted architecture for agile methodology as each day requirement and technologies are changing rapidly.
SOA is not Microservices
Of course, you would have been thinking that, is SOA same as Microservices? conclude it to not exactly. Don’t confuse that SOA and microservices are the same terms. Traditional SOA is a way big term which uses imperative programming language while microservices is a responsive actor. A monolithic application can also be SOA based but microservice architecture totally overrules monolithic. So, we can understand microservices as a more refined term of SOA architecture.
Why we need Microservices Architecture
Microservices architecture is not a silver line that can be fit anywhere, it has its own kind of complexities that need to be addressed efficiently to get productive results. Basically, you have to draw a chain of communication of different patterns, services, and third-party systems. So, we must understand why and where it needed.
For that, we should understand monolithic architecture in enterprise industry. Monolithic architecture is the group of complex modules which are tightly coupled and have a single execution point (in laymen language single war or ear file), typically deployable on web or application server.
Below figure depicts a monolithic architecture, in which we can see all components are tightly coupled, heavy weighted and interdependent.
Initially Amazon, Netflix were having a monolithic architecture but later on, when their business grew, they faced challenges and finally adopted microservices architecture. For simple applications, it is always good to go with monolithic as here microservices can add an extra overhead and reduce the productivity.
Benefits of monolithic are simple DDS.
- Simple to develop
- Simple to deploy
- Simple to scale
Microservice will always perform efficiently when the application is complex and need to scale to cater growing business. So here we will discuss the problems when a monolithic grows too complex and cumbersome application to manage.
What if business required frequent and easy releases:
For example, a change occurred in one component only but due to this change whole application will do down and need to deploy again as monolithic have single war file. A lot of developers will be involved and testing efforts will be high to test whole application. Frequent release plan will be overhead as we have to reinvent the wheel all the time.
Complex and tightly coupled code overhead:
The application will have a tightly wired code which is very hard to maintain by developers doesn’t matter how modular approach have you taken. Training for the new member will be complex and documentation will be so confusing.
Difficult to manage the team:
As each change required the whole system to suffer and a complex code will require a large team that will further be interdependent. A team working on a change can block other teams. Along with expertise team is required to manage such cumbersome code based on monolithic architecture.
Legacy technology stack:
As an application is very tightly coupled and interdependent, we will not have the facility to change the technology stack of a specific module. An application will not be future ready as the replacement would be very expensive in term of cost and efforts.
IDE and container overhead:
Each developer will have to load whole application code in the local workstation that will slow the performance of IDE and reduce the efficiency and productivity of an individual. Further to this, it will increase the deployable overhead for the containers.
Scalability of application is expensive and difficult:
So if monolithic grows then it will be in unidirectional as it is very tightly coupled and have some interdependent complex wirings so it would be very tedious to scale it. In any case, if we can scale it by means of having cloud then it would be very expensive. And what about the database? It would be troublesome to handle such volume data as each instance of the application will hold all data and it will create a problem for caching and eventually we get delayed response and less efficient monolithic application.
The solution for above problems:
So, we have discussed above, the pain of having a monolithic architecture which is growing dynamically and increasing the complexity rapidly.
Below is the solution of above monolithic architecture in term of microservices. Here we will be using very less dependent modules and mode communication will be web services in general case i.e. Rest APIs.
Each view will have a separate way of interacting with backend which further has a separate and dedicated database. We can have three independent war file which will release the container overhead.
Above solution is based on microservices architecture and we can see that it is very loosely coupled and clearer in term of communication and less complex.
We hope this article is worth reading. At the end of this article, we are assuming that readers are now aware of microservices architecture and where it needs to be applied. Later, to the continuation of this article in next series, we will discuss pros/cons of microservices architecture and a project example to understand it in a more practical way.
Read – Microservices in Action with Spring Boot
Please feel free to ask a question or two and we will be glad to answer them.