Microservices vs Monolithic architecture
Microservices architecture is getting a lot of attention these days and being used by Uber, Netflix, Linkedin and many other other companies. I am sure you would have worked on various applications which use monolithic architecture. There are considerable problems with monolithic architecture which we won’t face if use microservices architecture. We face a lot of problems in terms of deployment, scaling, understanding huge code base, moving to a new framework, continuous delivery of new features, in term of coupling between components etc.
Microservices architecture allows a big application to divide into small, loosely coupled services. It comes up with a lot of benefits which we are going to discuss here.
- It allows segregation by business components and builds business services by embedding business rules, logic in a single application e.g. order promising. Since the integration contract is via APIs it is possible to mix and match various best of breed technology components in the overall stack rather than restricting to a single set of technologies, which will be the case in the monolithic architecture. E.g. Server applications can be written in Java while Data Science stack can be in Python and they can interact easily via REST APIs.
- Let’s say you have one e-commerce application which was developed using monolithic architecture, and over the time it has grown with a lot of new features. Now codebase became huge and few sets of people going to join your team. It becomes too difficult to understand this application as there is no clear separation between various components of the application. After spending a lot of time, they added few bug fixes to the existing codebase. There are high chances of breaking existing features as it is very complex and you need to be very careful in term of making changes in existing codebase. It might take a lot of time, and you wouldn’t be confident even after spending a lot of time. Microservices allows you to see your application in terms of small, loosely coupled components, anyone can get started with existing application in short span of time and, it wouldn’t be too difficult to add a new fix to the codebase. You should have well-written documentation for each microservice which covers all the APIs.
- Imagine today you are running a promotion. So you would be getting a huge amount of traffic. And somehow your message component broke. It will affect the whole application, and it will cause whole application to go down. If same happens in microservices architecture, you won’t face such failures as it runs multiple services independently so even if one goes down, it won’t affect other services. And it would not have a huge impact on business unless it is not category/tier 1 microservice.
- You are a group of people who spent a lot of time in terms of understanding your application codebase. you guys excited about adding new features ex. product trending features, search etc. As a developer, you need to re-deploy this application each time. And you would be working on many such features, just think about the time it is going to take every time in deployment. So if your application is huge, it takes a lot of time in building, deployment etc. which definitely cause loss of your productivity. Nobody likes to wait for 10 minutes or more and then see the result of code changes. In microservices architecture, we try to make codebase as small as possible in each service so it doesn’t take much time in terms of building, deployments etc.
- Today you getting the huge amount of traffic, and nothing got broken, servers are up. Let’s say we need to scale any one component here e.g.. payment, you can’t scale individual component in the monolithic architecture. In microservices architecture, you can scale any component separately with adding more number of nodes dynamically.
- You started with some old framework initially, and now if you want to move to new framework or technology stack. It becomes very difficult in monolithic architecture as it has become very big, complex over the time. It is not that difficult to achieve in microservices architecture.
That’s how microservices architecture makes your life easy. There are various strategies available which help you in a diving application into small services e.g. decompose by domain driven design, decompose by business capability etc. I would strongly recommend anyone who is just starting with microservices architecture to go through below given case studies :
Microservices at Netflix: Lessons for Architectural Design
The Opportunities Microservices Provide at Uber Engineering
What Led Amazon to its Own Microservices Architecture – The New Stack
Everything comes up with pros, cons, and microservices architecture has cons too. I would keep writing about microservices, various design patterns available in microservices architecture, event-driven architecture in future.
Also published on Medium.
1 thought on “Microservices vs Monolithic architecture”