Monolithic v/s Microservices - Knoldus Blogs

Monolithic v/s Microservices

Reading Time: 3 minutes

Monolithic architecture :-  A monolithic architecture is the traditional unified model for the design of a software program. The term monolithic is not new and is borrowed from the Unix world. In Unix, most of the commands exist as a standalone program whose functionality is not dependent on any other program. In simple words, monolithic meaning is formed of a single large block of stone which is inflexible or rigid. The below image describes monolithic architecture in pictorial form:

monolithic in this context, means composed all in one piece. Monolithic software is designed to be self-contained. Components of the program are interconnected and interdependent means they are tightly coupled rather than loosely coupled  as is the case with modular software programs. In a tightly-coupled architecture, the order of components is very important. Each component and its associated components must be present in order for code to be executed or compiled.

Even a simple code change in one of the modules or component may break a major functionality in other modules. So this would results in a scenario where we would need to test the whole application again not only single module. With the business depending critically on its enterprise application frameworks, this amount of time could prove to be very critical. Moreover, so simple change will also takes lot of time because we have go through the whole application again.

Deployment of monolithic application will become another challenge. During the deployment, we will have to be ready and  make sure that each and every component is deployed properly otherwise, we may end up facing a lot of issues in our environments that may be test or stage or production.

Microservice architecture :- Microservices is a variant of the service oriented architecture(SOA) architectural style that structures an application as a collection of loosely coupled services. The key benefit of decomposing an application into different smaller services is that it improves modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Each small service running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.  The below image describes microservice architecture in pictorial form:

As you can seen in above image every microservice has its own Database. Each microservice has its unique functionality and business logic. Microservices are interconnected with each other but they are loosely coupled . Suppose, if we want to change in only one microservice then we just need to go on that microservice and just change it we don’t need to go through whole application.

Micro Services are designed to manage or survive with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.

Key benefits of microservices architecture :- 

• Delivering business focused and lightweight services/APIs that are truly design, built, deployed and executed independently of each other (meaning that in terms of infrastructure dependencies, they share very little)
• Strongly focus on people alliance and communication as the main mechanism in the adoption of best practices and standards rather than common set of strict guidelines and standards that constraint the way services are define, built, deployed and maintained
• DevOps (config management, deployment automation, Continuous Delivery) as a fundamental building block rather than a value add.
• Scalability should be easy as services are very lightweight and stateless.
• Doesn’t encourages the use of monoliths to deploy services. Services should run almost as demons.

References :-   https://oracle.com