An Introduction to Microservices Architecture – Simple and Easy To Understand

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 the 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 to 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 developers 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 detail.

What are Microservices

Microservices is an architectural style in the software development life cycle based on SOA (Service Oriented Architecture) to manage and fine grain a grant application. Here application would be a group of loosely coupled lightweight services which are expert in their service implementation and collectively achieving an entire application goal. Netflix, eBay, Amazon, and many others which have the first approach as monolithic but now using Microservices architecture. It is a very compatible and adapted architecture for agile methodology as each day requirements 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 the enterprise industry. Monolithic architecture is the group of complex modules that are tightly coupled and have a single execution point (in laymen language single war or ear file), typically deployable on the web or application server.

The 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 extra overhead and reduce 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 to a growing business. So here we will discuss the problems when a monolithic grows too complex and cumbersome application to manage.

1. 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 a single war file. A lot of developers will be involved and testing efforts will be high to test the whole application. The frequent release plan will be overhead as we have to reinvent the wheel all the time.

2. 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.

3. 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 the expert team is required to manage such cumbersome code based on monolithic architecture.

4. 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 terms of cost and efforts.

5. IDE and container overhead:

Each developer will have to load the 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.

6. Scalability of application is expensive and difficult:

So if monolithic grows then it will be 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 a 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.

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 to the above monolithic architecture in terms 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 terms of communication and less complex.

Conclusion

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 the next series, we will discuss the pros/cons of microservices architecture and a project example to understand it in a more practical way.

Read –

Microservices in Action with Spring Boot

Simple Guide to Spark Framework for Microservices

Please feel free to ask a question or two and we will be glad to answer them.