This content originally appeared on Bits and Pieces - Medium and was authored by Siddhesh Shinde
What is the key point we need to consider while moving from monolith to microservices?
I’ve recently started reading the book Building Micro-frontend and I’ve decided to share some of the key points I learned when we decide to move from monolith to micro-service.
Monolith
In monolith architecture, we write a lot of code that should harmoniously work together. We tend to preoptimize or even over-engineer our application logic. We also try to Abstract reusable parts of our code which can create a more complex codebase, and sometimes the effort of maintaining complex logic doesn’t pay off in the long run.
If we want to scale monolith architecture, we cannot scale a single part of the system but we need to scale the entire system, causing many headaches if our system is not modularized or written with higher standards.
Working on a monolith codebase with distributed teams and colocated ones could be challenging, particularly after reaching medium or large team sizes.
Organizations with large monoliths typically slow down all the operations necessary for advancing any new feature.
In monolith architecture, we have to deploy the entire codebase every single time, which comes with a higher chance of breaking the APIs in production, introducing new bugs and making more mistakes, especially when the codebase is not rocked solid or extensively tested.
Microservice
Microservice can split a unique codebase into smaller parts, each of them being a subset of functionality compared to a monolithic architecture, where every part is independent of each other allowing the team full ownership and independent evolution of the codebase.
The microservice architecture allows us to scale part of the application.
Pitfalls of microservice
- The investment in automation, observability and monitoring has to be completed to have a distributed system under control.
- Microservice should not be too small that are required to rely on other microservice to complete the action, this creates a strong coupling between microservice and forces them to be deployed together every time.
- The complexity of microservice architecture could become more painful than beneficial.
💡 Microservices can be complex — but making the right decisions on identifying and isolating each microservice is half the battle. Treating the microservices architecture like composable building blocks is key, and it’s made easier with an open-source toolchain such as Bit which allows your teams to independently isolate, publish, version, document, test, and share individual components such as functions, UI elements, or data models, that can be reused across multiple microservices. This can greatly reduce the duplication of code and increase the modularity and scalability of your system.
Learn more about component-driven microservices here:
Component-Driven Microservices with NodeJS and Bit
We should use microservice only when we needed we should not pick microservice recklessly just because it is the latest and greatest approach.
The Journey
When we start a new business offering service online we need to consider some steps.
- The fast iteration should be used for understanding if our business could succeed or not.
- What should be the list of the tech stack used to build and run a single application?
- Create MVP products representing your businesses. We should concentrate on the bare minimum, we’re able to quickly gather information about our business idea directly from our users, this is called MVP.
Creating an MVP product monolith architecture is the best way to do that.
Integration and observability of monolith architecture are quite easy. The deployment process is very easy considering we need to handle one automation strategy for the entire API layer and one deployment and release strategy, and when the traffic starts to increase, we can scale our machine horizontally, having as many application servers as needed to fulfil the user’s request. That is why monolith architecture is often a choice for a new project since we can focus more on the business logic of an application instead of investing too much effort in other aspects, such as automation.
For making a monolith architecture project we need to decide
- Which database better suits our project?
- Where should we host our database?
- Finally, we need to choose which technology will represent our data.
If your company decided to scale up the tech team, hiring more engineers, QAs, scrum masters, and so on. The best way is to implement a microservice.
While scaling in monolith we realize that all our APIs are scaling organically, some of them are highly cachable, so the CDNs are serving the vast majority of the clients. Our origin server is under pressure only when our APIs are not cachable.
Splitting our monolith starts to make sense at this point. Embracing monolith also means reviewing our database strategy and therefore having multiple databases that are not shared across microservices.
In microservices, each team is responsible for its set of microservice
- Make a decision on the best database to choose.
- The best way to structure the schema.
- How to cache some information to make response faster.
- Which programing language to pick for the job?
In microservice, each team is entitled to make a division and be responsible for the services they are running in production.
Using these microservices we are able to scale out the APIs layer and our persistent layer with well-defined patterns and best practices.
Know more about the Different types of Frontend application
From monolithic to microservices with Bit
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Journey From Monolith to Microservice was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Siddhesh Shinde
Siddhesh Shinde | Sciencx (2023-03-20T14:57:12+00:00) Journey From Monolith to Microservice. Retrieved from https://www.scien.cx/2023/03/20/journey-from-monolith-to-microservice/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.