Hi everyone, we are talking about a topic which is intensely discussed in software engineering circles and
Interviews, which is should you choose a monolith or should you choose a microservice?
So monolith architectures are those which have huge systems. It's just one machine, which is running the entire
System while micro services are these tiny tiny?
Dots where you just have one function running on one machine and they have tiny tiny data bases with each of them connected
interconnected and you know
all the clients are connected to different micro services while this monolith has all of the clients connected to the single machine
is what most people think!
There's a common misconception that I am trying to highlight here
The first one is that the monolith doesn't need to be single in terms of the number of machines
You are running it on because there might be multiple
machines
the same monolith and
These clients can connect to them they in turn can connect to this database or two more databases
So you can horizontally scale you can scale out even with a monolith. There's nothing special about it
So the concept that a monolith is a huge machine, which is running the entire system is not true
The second thing is micro services. There's nothing micro about a micro service this
Micro service is a single business unit all data all functions
Which are relevant to a service are put into one service if you can separate it
With a lot of concerns being separated out then you probably want to separate a single service into pieces
So that's what a micro service is. It's not tiny machines which interact with each other all the time
There might be just three micro services in your entire architecture
Depending on what your system is and they themselves -
talk to , Usually talk to their own dedicated databases
The client may not be talking to the micro service it might be talking to a gateway
So these clients will be connected to the Gateway and this gateway is talking to these micro services internally
Now that we have some clarity on what microservices and own lips are let's understand. What are the advantages and disadvantages of each architecture?
Let's start with the monolith architecture
When put under a lot of load the monolith architecture scales out , just like here you have multiple servers
One of the key advantages of this architecture is when you have a small team
When you have a cohesive team and a small team, it doesn't you know?
You may not be able to afford the time and the interactions required to break this into a micro service
So if your team is cohesive go for a monolith architecture
The second thing is they're less of moving parts around this
Architecture you don't need to wonder about how do I break this into pieces and once they are broken into pieces?
How do I actually maintain different servers at different times?
so
deployments in some way are easy because everything is the same
Thirdly, you might have some code which are for setting up tests,  setting up connections,  setting up
various other things in your in your system,  all that code need not be duplicated for every service that you create
It's all the same. It's all in one service
Fourth this is faster because you're not making any calls over the network
It's not an RPC call remote procedure. It's actually in the same box
So all that logic and all that code is in the same box. So it's going to run faster
You just need to make a local call
Now let's come to the fun bit, which is
Disadvantages
so
The biggest disadvantage with this is if there's a new member in the team
they need to have a lot of context on what they are developing if you give them a
Monolith which contains all the logic they have to go through and understand the whole system
So they're to put everything in their mind in the context
The second thing is that deployments are complicated in this because any change in the code whether whatever part you're touching
Requires a new deployment your code is going to be deployed very frequently and it has to be monitored every time it is deployed
So that it's working properly
In the tests are more complicated, right because everything is touching everything this it's not really decoupled as you would like
and the final point is this too much responsibility on each server if there's a mistake because of which
The server crashes all of this servers will crash and the whole system will collapse
Instead if you had something which is serving profiles and something which is serving. Let's say some other data
Maybe this could have connected to the profiles and this could have connected data. This would have failed
This would have succeeded you would have partial success in the system and you would just need to restart this point instead you needed to
Restart all of them with the correct code
Now coming to micro-services the most obvious advantage is that it's easier to scale
because you can look at this entire system as a suite as a set of services each concerned with only its data and
Interacting with each other. So it's easier to design the system in that way
The second thing is whenever there's a new developer coming into the team
you can assign them a task which
Which concerns with a particular service so they just need to know the context of this service instead of the entire
monolith, right. We discussed this problem the monolith to
the third point is that parallel development is easy because
There is lesser dependency for the chat developers on the analytics developers now because they can develop at the same time in the monolith
Maybe one function is calling the other function and it's changing. So there's a lot of
Coupling tight coupling not just in code, but also in the developer time
the final good point is that there are lesser
parts
which are hidden.
When you are actually deploying this service if you're seeing there's a lot of load on the chat server
You can easily scale that out. You can put more machines for that chat code
With the monolith, it's more difficult to save what is being used a lot and what is being used less.
So you are more likely to be putting in more servers just directly,  instead here you can have a more streamlined approach for the problem
One of the things which are sort of a disadvantage for microservices is that they are not easy to design
So maybe the chat will be broken into far more parts which are not required
so a good indicator that you have a micro service, which shouldn't be a micro service is that if it's talking only to one
service, so if
service one is just talking to service to all the time that implies that maybe it should have been within a
Single service and they could have converted this RPC to a normal. Uh
Normal, call a function call
That's the only disadvantage it needs a smart architect to architect well for a micro service architecture
So in the argument of where the monoliths or micro services are better
What would happen in a system design interview is that you may need to justify why you are using a micro service architecture?
Ninety percent of the time the system design interview is going to be on a large system
so for a larger system a micro service architecture is
More often than not better, right?
So you're going to be going for the micro service architecture by default?
If you are asked to justify this decision
Then you should remember some of the points that we have discussed in this video and then you can put them forward
Of course if they're not good enough then maybe they're giving you a hint that you should go for the monolith
There's a very successful system which uses the monolith architecture called stack overflow
I'm sure you've already heard of it and
A micro services are used extensively in many many companies like Google Facebook
So on and so forth. So if you want to have an interesting discussion on what is better
You can have it in the comments below, I'll also be participating
And there's some relevant links in the description
If you want further notifications for videos like this, please subscribe and if you liked it hit the like button. I'll see you next time
