Understanding and
building Microservices.

27 Mar, 04:14 am

*cough cough*

The main purpose of this article is to get you started with microservices by providing a
quick and rough overview by explaining what it is in a very straightforward way and by building a simple application. So this series consists of 2 parts


1. Basic overview of what are Microservices
2. Building one with Nodejs, Redis and Docker. [Posting soon.]

So if you have been working on building APIs then I’m pretty sure you would have followed the conventional monolithic architecture where there is a Database from which the server queries data and sends to the client(UI). There is nothing wrong with this approach but then there is, this whole new procedure which is more beautiful and flexible.Yes! Microservices.

Microservices can be imagined as loosely coupled modules which perform a set of functionalities and are developed and deployed independently. Or to put it in another way, you develop isolated objects specifying certain functionality which together solves a complex business problem. Can these isolated modules which are called services hence microservices communicate? Yes! There are various ways they can communicate: the standard ones are communicating using HTTP or gRPC or via a bus channel using RabbitMQ.

Let’s take a social media platform like Instagram for example, we can decompose the entire system into small microservices like Feed System, Profile Recommendation System, User Management. Each of these services are developed by different teams and got their own databases. So different services are built by different teams who are responsible for deploying and maintaining it. They are incredible with fault isolation! That is, even if one service is down, the others function and hence there is no need to bring the entire system down. This is where Microservices Architecture takes an edge over the traditional approach.

And again since they are independent, you get to see which one of your services is getting highly loaded and you can scale it eventually. Another major advantage is DIFFERENT TECHSTACKS! Yay. You don’t need to stick on with the same techstack for the entire system but select the suitable ones based on the functionality that a service is going to provide. For example, one service could be based on Nodejs and MongoDB and another could be of Django and Postgres.

Coming to deployment, you can either deploy it in such a way that all the microservices run on the same operating system or each having its own operating system which is where docker’s container technology comes into play. The most efficient way is to stick with one microservice per operating system because sometimes when multiple microservices run on the same operating system, a service could slow down the other.

Now that you have some basic understanding of what "microservices" is, in the next article we will build one!


*cough cough* :p