Microservice Architecture / Dec 14, 2022 / Ms. Sukriti Srivastava
To understand what microservice architecture is, let’s first understand what it is not - monolithic architecture. Suppose, you are building Facebook from scratch. So, you write an application to be used as the backend of Facebook. Everything is written in this backend project: creating new posts, liking posts, commenting on posts, generating newsfeed, showing friend suggestions, etc. We run this application as a single process. This application is called a monolith since this single project contains everything (remember that the prefix ‘mono-’ means single). And the software architecture in which we build monoliths is called a monolithic architecture.
Monolithic architecture works fine when the application is small. But over time, you will be adding more features to satisfy the ever-growing demands of the users. As a result, the application will become larger and a number of problems will start appearing with it. Some of the problems are listed below:
1. Hard to manage: Over time, the team size will increase. Since all the developers will be working on the same project, monolithic architecture will prevent them working independently. Again, since the application will be large, no one developer will be able to keep the whole application in mind. As a result, it will become difficult to manage and to deploy.
2. Components cannot scale independently: The only way to scale the backend horizontally is to create more instances of the same monolith behind a load balancer. That is: the whole application must be scaled at once - we cannot scale a single component. But in reality, some components may get more traffic than others. So, they should be allowed to scale more than other components. But this is impossible in the case of monolithic architecture.
3. Longer compilation and startup time: since the compiler need to compile a huge application, it will take longer. Larger applications also need longer startup time. Even if developers change a small portion of the application, the whole application must be compiled and run. These in turn will affect developer productivity by killing a lot of developers’ time.
4. Only one technology stack for the whole project: Different technologies are best for different use cases. For example, say, you are building an eCommerce marketplace and you follow monolithic architecture in the backend. That means if you use Java, the whole backend project must be written in Java. Now as the popularity of the marketplace increases, you want to suggest products to customers based on their history. For this, you will usually use machine learning. But most machine learning libraries are written in either Python or R. So, it will be difficult to incorporate machine learning techniques in the backend.
Again, in this fast changing world, a single technology may become outdated. Since the whole application is written in Java, it will be difficult to migrate to better/newer technologies.
All these problems appear only because the whole backend is written as a single application. So, what is the solutions? Doing the opposite: splitting the backend as a collection of smaller applications. Each of these small applications is called a microservice. This software architecture is called microservice architecture. Note that the prefix ‘micro’ means small. Since a microservice is a small portion of the whole backend, it is called microservice.
Each microservice runs as a separate process and is deployed separately. As a result, each microservice can vary independently.
One microservice may depend on zero or more other microservices. For example, say, we have a payment platform where there are two microservices: one for authenticating and authorizing users (say, Service A) and the other for managing payments (say Service B). When a user sends a request to Service B for some payment, Service B needs to know whether the user is authorized to do so. Since authorization is managed by Service A, Service B will require to communicate with Service A.
There are two types of communication among services: synchronous and asynchronous.
Synchronous communication is one in which one service will wait for other services to complete some action and return with some output. In the above mentioned example, Service B will have to wait till Service A responds with the answer of whether a user is authorized to do the operation.
Asynchronous communication is one in which one service does not wait for other services to respond. We can use Kafka, RabitMQ, etc for this purpose.
Microservice architecture was introduced for solving the limitations of monolithic architecture. So, the benefits of microservice architecture are the opposite of the limitations of monolithic architecture.
1. Easier to manage: Since every microservice is a separate application, changes in one microservice is guaranteed to be not affecting any other microservice. So, one team can work on a microservice independently, without thinking about other microservices.
2. Components can scale independently: Since each microservice is run and deployed separately, we can scale one service more than other microservices as needed.
3. Shorter compilation and startup time: Since a microservice is supposed to be a small application, it will take less time to compile and run that application.
4. Separate microservice can use different technologies: Since each microservice is a separate application, we can use whatever technology suits the best. For example, recommendation service can use Python since this service requires machine learning algorithms while user management service can use Java.
Contact Us for your project estimation