Why Companies use Microservice Architecture to Scale
Companies like Amazon, Spotify and Netflix transition from a Monolithic architecture to a Microservice architecture when scaling. But why?
What is Microservice Architecture?
In technical terms, this architectural style breaks down an application to loosely coupled services that can be developed and maintained independently.
Take a hypothetical e-commerce site “MeowKit.com” that sells cat toys for example. The web application that runs MeowKit can be broken down into the following services:
Each of the services can be remotely accessed through API calls, allowing them to function independently from each other and serve a unique purpose. More importantly, it allows each service to be built by a different development team, allowing development efforts to be properly allocated if necessary.
Significance of Microservice vs Monolithic Architecture at Scale
To understand the significance, let’s imagine that you are Bob, a Front-End Software Engineer that just joined MeowKit, a famous ecommerce brand handling thousands of orders through its web application every hour.
Here’s 2 possible scenarios that you may encounter.
Scenario 1: MeowKit still uses Monolithic Architecture
What you(and everyone else in the team) see:
You are introduced to a large monolithic code base that represents the web application. All different features and functionalities are deployed and built on top of each other in a single instance.
After spending weeks to understand how you should modify a feature, you realise you have to wait for 40 other developers to finish working on their features before the entire system can be redeployed again.
Some difficulties that the team encounters:
- Difficulties in scaling to handle increasing transaction volume. Currently, the application can only scale by running more copies of the application on different cloud servers.
- Poor work efficiency. Although different development teams handle different aspects of the web application, they have to coordinate their efforts for redeployment since they are working on the same code base.
- Difficulties in debugging. With the entire system being deployed as a single instance, fixing a bug may result in regressions in other components.
Scenario 2: MeowKit uses Microservice Architecture
What you see when tasked to develop the Web UI service:
You only have to understand how different components in the Web UI service function in order to modify a feature within. To access other services, you simply use the relevant API calls that they provide in their documentation.
Benefits that the team enjoy:
- Simple to scale. Services can scale independently from each other. For instance, when MeowKit decides to run a mass promotion, the Notifications service can scale independently to send promotion notifications to their customers without having to also scale Payments service (yet).
- Good work productivity. Each development team can develop, deploy and maintain a service independent from other services, allowing better efficiency. For example, the UI team benefits from being able to iteratively and constantly deploy their code for minor UI edits.
- Ease of debugging. A bug in the entire system can be quickly traced to a specific service, which is smaller and easier to debug.
Why aren’t ALL companies using Microservice Architecture then?
It depends on the stage that the company is at.
While a company can benefit from the scalability and ease of maintenance in a Microservice Architecture, the transition between architectures can be costly and challenging for a startup. Deploying and managing services introduces additional overhead that might not be reasonable when the priority of the team isn’t scalability.
It is never a bad idea to start off with a well-structured monolithic web application until the development team starts to experience issues with scalability and/or maintainability. Thereafter, careful decomposition of components into services can be planned at stages.
