An overview of microservices
Have you ever logged in to facebook and ever wondered how everything works, from getting the list of friend posts and your profile information.
You might think that facebook magically does everything all in one go by the time you logged in. Thing is…that’s not how it works. What happens is your application will start calling different services to fetch all the information you need to proceed.
For example, when you logged in to facebook, it will probably try to access some of the following services individually:
- profile service
- a service to retrieve comments and posts
- advertisement service
- a service to retrieve a list of friends
These services are like organs for humans. They are essential and each of them places a role to help the application properly.
Well…how does any of this have anything to do with microservices?
Microservices are services created in an organized and structural ways. Instead of having one know it all service that does everything, the functionality of the application are broken down into chunks. These services are owned by small, self-contained teams.
To understand microservices better, let’s understand how the opposite of microservice works.
Imagine you live as a kid and your mom provides everything you need. If you need snacks, you have to ask her. If you need to go to school, you have to ask your mom to take you to school. What if your mom gets sick? All of a sudden, you are left without snacks and you cannot even go to school properly.
This is what we called a monolithic architecture. In a monolithic architecture, all the services are tightly coupled instead of being loosely coupled. If a service goes down, the rest of the services goes down. As people say, the captain goes down with the ship. If the captain is sick, rest of crew members sunk along with it. Not a very promising way of looking at it right?
How will a microservice architecture make things easier?
With microservices, you can separate all the functionalities into different services. For example, if you build an ecommerce platform you can separate your key functionalities into multiple services. I can have:
- authentication service
- a service for retrieving all the items on sale
- a payment service to pay for my item list
- a service that shows my list of shopping cart items.
If one of my services burn more memory and cpu than the other services, I can always scale up and allocate more resources to this service. In a monolithic architecture? I would have to do the same for the service as a whole. That might not make sense because other components might not need extra resource or cpu to run.
Another advantage that microservice offers is the flexibility in which we can implements these different services. Some services we might want to implement in node, other in Django as well as java. In a monolithic architecture, you stick to one framework. Here is the problem: some services such as an authentication service might be better suited to be coded in java and spring boot, others might be better suited using node and django.
If I had to write my whole backend in java, it might be a bit of an overkill for functionalities such as getting retrieving all the items and feature that does not need as much as security. If I wrote my backend all in node, then it might not offer as much as support when it comes to security.
With microservices, I can write my authentication service in spring boot, while writing my item service in a much more lightweight framework as node.js.
What’s more important about microservices is that some of the services can be used in more than one places. For example, the authentication service can be used for the ecommerce application as well as other applications. If we build a monolithic application, we cannot really reuse authentication service for multiple other applications.
We talked about everything that’s great about microservices. How about its disadvantages?
First of all, while it improves the flexibility and maintainability of an application, it does make communication between different services more complex. In a monolithic application, all the services are interconnected with each other and communication between services are much more direct.
With microservices, these services are maintained separately. Now we have to build some type of messaging system that handles the communication between these services.
If something breaks in the application, we now have to go through logs from different services to understand what is going on. In a monolithic application, there is only one log to look at.
Deployment of services onto a server would also be more complicated and time consuming since we are deploying multiple services instead of one service. Extra coordination would be required to ensure a smooth deployment process.
In summary, if you are deploying a single page application that does not need much going on, you probably do not need to implement microservices. If you have a complicated application that is going to be used by million of users, microservice architecture will serve you well!
