Monolith First ! When and why to choose it?
A lot of companies are adopting a microservices architecture. In this blog, we will see what is a problem with monolith architecture that leads to microservices adoption. Let’s start with a story of e-commerce startup
Start up will start with a monolith architecture something like below and may have modules for each feature.
Modular Monolith is the best choice if you are starting out, it reduces lots of complexity for you and everything is straight forward for you.
Things are easy in monolith
Simple to develop, test and deploy.
Need various data points for APIs? Join the tables to return the necessary result.
Constraints between tables are there for data validations.
You can use transaction to make changes as an atomic operation and rollback if something fails.
Then why people move out of the monolith and choose more complex architecture like microservices?
Once your startup starts seeing some traction you will need to scale
- Scale the infrastructure to meet the new demand
- Scale the tech teams/company to meets the new business requirements and features etc
This is when you will start seeing probelms……..
Problems with monolith
The database is a single point of contention. Scaling the database can be a challenge after some point fo time. The database need for each module can grow differently after some time. Some might be read-heavy som might be right-heavy there for each needed to optimized accordingly for their scaling needs.
Conflicts in production deployments reducing feature velocity.(No continuous deployment)
Now you might have 3-4 teams working parallel and adding features to the same repository, Therefor to move code into production will need coordination between teams(No continuous deployment) that will increase the time you will need to move your code in production(lead time). Entire application is deployed every time feature is released
In addition to that one feature change might impact the working functionality of the other feature as they are using the same codebase and database. For instance, if someone added a column in common table being used by two features, that might impact things in production.
Multiple features will go live together as we are working in single repository. As a result, if an issue comes up it will be tough to figure out the root cause and brings back the system in the working state immediately.
Each module might have different technological needs. For example, the feedback module might want to use a NoSQL database and the Payment module might want to use an RDBMS. One module might need to be coded in a different language because of specific needs etc.
We might somehow manage infrastructure and scale it out in monolith, but as the company grows the number of teams will also increase. Resulting in more coordination between the team to roll out the features.
Scaling the tech team along with the business will become tough, and it will take more time to add features as we grow,
In conclusion, If you are a small team and starting, Monolith is the best way to go. Things are easy to develop and manage in the Monolith. Twitter,eBay, LinkedIn all started with a monolith architecture and eventually moved to microservices when they scaled.
If you are scaling your company eventually you will have to move to microservices architecture. Click here if you want to know about microservice architecture.
Follow us on