Difference Between Monolith and Microservices in Software Architect Infrastructure
In this era of Information Technology, applications are used by more users for supply requirements daily. No doubt, the application is more issues on the side server because is limited resource infrastructure if any big traffic users and application is used every day and every time for 24 hours. So, when when we ignore the issue, it’s big problem in the future.
So, I want to tell about software architecture on infrastructure side. In software development, These are 2 Software Architects on development, that are are Monolithic and Microservices?
Monolithic Architecture
Monolithic Architecture is a traditional model for software development in 1 instance/server for all resources. So in another app, the application deploys on 1 instance/server.
It’s an example for describing monolithic architecture in e-commerce.
You can see there is 1 instance for the Backend and Frontend in one system. For mobile apps got from Backend Service via API. So in this case you can see this architecture is full-stack for the development App.
The component technology requirements are:
- Database
- Cache (Redis)
- Cloud Storage
- Full-stack (Backend and Frontend)
- Mobile Apps
For features on this app:
- List Products
- List Categories
- Cart
- Checkout
- Payment
- Promotions
- List Users
- List Sellers
- Orders
- Chat
- Banners
- etc
As you can see, the architecture of the application has more complex features in one system, it can be a heavy performance on the Backend System side. If the apps can be complex features, you have difficulty maintaining and scaling on this system. When the application got large traffic from users (eg. 1 Million Request/Second) so the systems can be down in seconds and you must scale the systems for handling traffics.
However, in this case, you can build an app so fast with this architecture. And you can build with this architect fast.
Then, I want to tell you about the pros and cons of this architecture.
Pros
- Easy development — One executable file or directory makes deployment easier.
- Development — When an application is built with one code base, it’s easier to develop.
- Performance — In a centralized code base and repository, one API can often perform the same function that numerous APIs perform with microservices.
- Simplified Testing — Since a monolithic application is a single, centralized unit, end-to-end testing can be performed faster than with a distributed application.
- Easy Debugging — With all code located in one place, it’s easier to follow a request and find an issue.
Cons
- Slower development speed — A large, monolithic application makes development more complex and slower.
- Scalability — You can’t scale individual components.
- Reliability — If there’s an error in any module, it could affect the entire application’s availability.
- A barrier to technology adoption — Any changes in the framework or language affects the entire application, making changes often expensive and time-consuming.
- Deployment — A small change to a monolithic application requires the redeployment of the entire monolith.
So, we can see the pros and cons of monolithic architecture. With that problem, we can suggest for split the feature on the backend side into mini apps which can be called Microservices Architecture.
Microservices Architecture
Microservices architecture is an architectural method that relies on a series of independently deployable services. These services have their own business logic and database with a specific goal. So different from monolithic architecture is the monolith is developed with 1 architecture it can be 1 repo/project, and microservices can be split for some services, depending on the requirement system.
This is an example of microservices architecture in the case previous Architect.
You can see, this architect has more services that are:
- User Service
- Product Service
- Chat Service
- Cart Service
- Order Service
All services have more tools too such as DB, Message Broker, 3rd Party Payment Gateway, and Cache (Redis). So, with this architect, you can scale each service according to the requirement if one of the services can be high traffic. All services build in 1 layer of API Gateway for layering each service for security and not all APIs can be shown to the public.
So, with this architecture, the problem service can be handled and maintained so easly and scale up/down as requirements.
There are pros and cons of Microservices Architecture.
Pros
- Agility — Promote agile ways of working with small teams that deploy frequently.
- Flexible scaling — If a microservice reaches its load capacity, new instances of that service can rapidly be deployed to the accompanying cluster to help relieve pressure. We are now multi-tenant and stateless with customers spread across multiple instances. Now we can support much larger instance sizes.
- Continuous deployment — We now have frequent and faster release cycles. Before we would push out updates once a week and now we can do so about two to three times a day.
- Highly maintainable and testable — Teams can experiment with new features and roll back if something doesn’t work. This makes it easier to update code and accelerates time-to-market for new features. Plus, it is easy to isolate and fix faults and bugs in individual services.
- Independently deployable — Since microservices are individual units they allow for the fast and easy independent deployment of individual features.
- Technology flexibility — Microservice architectures allow teams the freedom to select the tools they desire.
- High reliability — You can deploy changes for a specific service, without the threat of bringing down the entire application.
- Happier teams — The Atlassian teams who work with microservices are a lot happier since they are more autonomous and can build and deploy themselves without waiting weeks for a pull request to be approved.
Cons
- Development sprawl — Microservices add more complexity compared to a monolith architecture since there are more services in more places created by multiple teams. If development sprawl isn’t properly managed, it results in slower development speed and poor operational performance.
- Exponential infrastructure costs — Each new microservice can have its own cost for a test suite, deployment playbooks, hosting infrastructure, monitoring tools, and more.
- Added organizational overhead — Teams need to add another level of communication and collaboration to coordinate updates and interfaces.
- Debugging challenges — Each microservice has its own set of logs, which makes debugging more complicated. Plus, a single business process can run across multiple machines, further complicating debugging.
- Lack of standardization — Without a common platform, there can be a proliferation of languages, logging standards, and monitoring.
- Lack of clear ownership — As more services are introduced, so are the number of teams running those services. Over time it becomes difficult to know the available services a team can leverage and who to contact for support.
So, we can now that building Microservices architecture must have more teams to handle some services. It’s not easy for some companies to recruit Engineers. It can be the company must more effort into budgeting Engineers to develop this. But it’s no problem for the big system because the system must always be online 24 hours non-stop. If some service is down, overall another service can be online, not overall down. Different from Monolithic Architect, if the system is down, all systems and applications are down too.
Conclusion
With 2 architectures we have some suggestions for development.
- For the first development system for Apps, you can suggest with Monolithic Architecture approach.
- If you want the first development with Microservices Architecture, you must over budgeting for Engineers and Tools too, and you can find much trouble in some days and make timeline development its long target expected.
- With Monolithic Architecture, you can build systems/Apps fast on track with a small timeline.
- But after building Monolithic Architecture, you can get into some trouble with performance or bug issues someday after live production and get high traffic. Because with that Architecture, you must troubleshoot from your source code, infrastructure, and many more.
- If you get into some trouble, you must migrate the system to many little systems with Microservices Architecture.
- But, if you want to implement Microservices, you just got more Engineers to implement it.
- The issue for migration, the existing systems/apps do not disturb.
- Do a smooth migration approach.
- Migration must be step by step, not migration all at once.
- So much time for migration.
For example in this case, you can see story migration at blibli.com from this https://medium.com/bliblidotcom-techblog/evolusi-arsitektur-backend-di-blibli-com-dc74e1650211 created by Eko Kurniawan Khannedy (Software Architect at blibli.com).
References:
