Hi reader :). The PiseWigeon here. Welcome(back) to my blog. In today's article, I will be talking about Microservices. Since it's the title. But, you can't really talk about Microservices without talking about Monoliths. So I'll start with Monoliths and finish the show with Microservices. As always, if you know little to anything about the subject, read the article till the end and tell me if it has been useful to you and if you are an expert in the subject, please do read and tell me if I say something wrong :) Without further a do, let's get started
What is a Monolith
Well, a monolith in software development, refers to an application that is built with a Monolithic architecture. The Monolithic architecture consists in building the application as a one "block". That block is self contained and independent from other applications. Sounds confusing? Look at these illustrations. Let's assume that we are building an ECommerce application. Now in our application, we have these functions that are responsible for pretty much everything our application will need to do
As you can see, all the functions are in the same box. That box is our application, it is self contained, which means that all it needs is already in it. A simple scenario of our application being used would look like this:
As you can see, all the requests are managed by the functions contained in that same Box. Some people think that Monoliths can't be scaled, which is wrong. A monolith is not a huge computer running the whole code, it's a "huge" codebase that contains everything it needs to function.
Monoliths are written using a single tech stack; they are developed, deployed and scaled as a whole unit. This means that if, for example, the developers that are working on the authentication function update their code logic, they have to make sure it doesn't conflict with existing logic, and the whole application has to be built and redeployed again.
Now that we have an idea about what monoliths are, let's take a look at
"There is nothing micro about microservices" Gaurav Sen
The microservice architecture, consists in breaking the application's logic into "small" or micro components. These components are called services. So our PigeonShop would look like this after we break it down into microservices
Each service has to implement one isolated function and they are based on business functionalities. They should also be self contained and independent of one another. It means that any modifications that happen in the Authentication service should not affect other services. And they are also developed, deployed and scaled individually.
Now as you can see in the illustration, a service might need some information from another service. How do they do so? They use Network calls. Think of each service as an API. So maybe the payment service needs the product cart information to determine the total cost, so he might make a request to that service's endpoint and get what it needs from there.
Unlike with monoliths, Microservices don't require a unique tech stack. For example, the team working on the authentication service might choose Python, the one working on the payment might choose NodeJS....it results in a great flexibility in development, it's very fast to deploy because each service is deployed and scaled individually.
I will wrap things up here, and write another article to discuss about the key differences between these two architectures and whether you should use one or the other.
I hope, you learn something new by reading this article. If so, mind following me and let me know in the comments if I got something wrong :) I know that I still have so much to learn and will be very happy to hear from more experienced people. I'll catch you in the next one. Peace.