Understanding the Architectural differences between Monolithic and Microservice
when we are developing a project then architecture will be going to take an important part in the whole development journey. So, I think no developer wants to ruin their night in the office for the late release pressure. And sometimes the company faces big business loss and in some scenarios, developers lose their jobs. So, let's start the main topic of this blog to understand the differences in architecture.
Understanding Monolithic Architecture
Food to Go, Inc. (FTGO) initially used a monolithic pattern when launched as a food delivery service. They are using monolithic architecture at the starting of the project.
Their application contains all the modules like order management, restaurant management, delivery management, payment in a single java application. In starting that architecture is good for their business software development because they have a small team to work on applications but as the application gets popular in the market then they require more new functionality for their simple application. After launching and getting popular in the market they start hiring more developers and then they find most of the time they miss the deadline which affects the business in the long run.
Because more teams for different modules development on the same codebase causes monthly production deployment in the place of daily or weekly deployment. And that causes testing was a headache for them. So, development need not be dependent on these thing’s which creates the monolithic hell for large projects. When the team size increases then most of the time gets wasted on the discussion part because everyone needs to be agreed on the implementation approach. But we don't want to waste valuable time in this competitive market.
Understanding MicroService Architecture
Before starting the topic, First, we need to understand the MicroService by some examples to understand the architecture.
MicroService can be represented by a hexagonal architecture that contains the business logic with a separate database and way to communicate like APIs, message brokers, gRPC.
Now, we need to understand what is microservice on the level of scaling cube.
The X-axis of the s-cube denotes the scaling of the application which can be done for monolithic as well. We can also say load balancing. So, Do not mix the load balancing with microservice. We can do load balancing for both monolithic and microservice.
Creating multiple instances of a single application is termed as load balancing which uses a load balancing algorithm for routing on instances like (RoundRobin algorithm).
The Y-axis of the scale cube denotes the scaling of the application by splitting function decomposition or code splitting. And that thing comes under the microservice because we are splitting the single application into multiple applications based on modules (like a food delivery application contain an order module, a payment module, a cart module, customer module).
And the Z-axis of the scale cube denotes the partitioning data by similar things or splitting of data on database data views.
So, we need to focus on the Y-axis of the Scale cube which shows scalability on the code level and that is termed as microservice when separated into multiple services with their own business logic. So, what we understand till now is microservice is splitting modules into multiple applications. And when those services communicate with each other then that whole architecture is termed as MicroService Architecture.
In the next post, we will understand the communication pattern in the Microservice.
Reference Book Source - Microservice Patterns by Chris Richardson