What is a MICROSERVICE ARCHITECTURE and what are its advantages?
Summary
TLDRThe video script explores the debate between monolithic and microservices architecture in software engineering. It clarifies misconceptions about monoliths not needing to be single machines and microservices not being about tiny machines. The script outlines the advantages of monolithic architecture, such as ease of deployment and faster execution, and its disadvantages, including complexity for new developers and the risk of system-wide crashes. Conversely, microservices offer easier scaling, focused context for developers, and parallel development but require careful architectural planning to avoid unnecessary complexity. The script suggests microservices are often preferred for large systems, with examples like Google and Facebook, while Stack Overflow successfully uses a monolith.
Takeaways
- 🏢 Monolith architectures are not limited to a single machine; they can be horizontally scaled across multiple servers with clients connecting to any of them.
- 🔍 The misconception that monoliths are massive single systems is debunked; they can be distributed across several machines.
- 🛠 Microservices are not about small size but rather about focusing on single business units, with all relevant data and functions encapsulated within.
- 🔑 A key advantage of monoliths is their suitability for small, cohesive teams where the overhead of microservices might be too high.
- 🚀 Monolithic systems benefit from simplicity in deployment and testing, as everything is contained within a single service without the need for network calls.
- 🔄 One of the main disadvantages of monoliths is the complexity for new team members to understand the entire system's context.
- 📈 Monoliths can face deployment challenges as changes require redeployment and monitoring of the entire system.
- 🔄 Microservices offer the advantage of easier scaling, focusing on individual services and their dedicated databases.
- 👥 New developers can be onboarded more easily with microservices, as they only need to understand the context of their assigned service.
- 🔄 Parallel development is facilitated in microservices due to reduced dependencies between different service teams.
- 🛑 A potential pitfall of microservices is the complexity in design, which requires a skilled architect to avoid unnecessary fragmentation.
- 📚 Large systems are often better suited to microservices, but it's important to justify this choice in system design interviews.
Q & A
What is the primary difference between a monolithic architecture and a microservices architecture?
-A monolithic architecture consists of a single, large system running on one or more machines, with all clients connecting to a single system. In contrast, a microservices architecture is composed of small, independent services, each running its own function and connected to its own database, with clients typically interacting with a gateway that communicates with the services internally.
Is it true that a monolith must run on a single machine?
-No, a monolith can be deployed across multiple machines and does not necessarily mean a single large machine running the entire system. It can be horizontally scaled to handle more load.
What misconception is there about the size of microservices?
-The misconception is that microservices are tiny machines. In reality, a microservice is a single business unit with all relevant data and functions encapsulated, and it can vary in size depending on the business logic it handles.
What are some advantages of using a monolithic architecture?
-Advantages include easier deployment, less duplication of setup code, faster execution due to local calls within the same system, and suitability for small, cohesive teams that may not have the resources to manage a distributed system.
What are the disadvantages of a monolithic architecture when it comes to new team members?
-New team members need to have a comprehensive understanding of the entire system, as the monolith contains all the logic, which can be overwhelming and time-consuming to learn.
How do deployments in a monolithic architecture differ from those in a microservices architecture?
-In a monolithic architecture, any change in the code requires a new deployment of the entire system, which can be complex and needs to be monitored closely. In contrast, microservices allow for more granular deployments affecting only the specific service that has changed.
What are the main advantages of a microservices architecture?
-Microservices offer easier scaling, as each service can be scaled independently based on demand. They also facilitate easier onboarding for new developers, enable parallel development due to reduced dependencies, and allow for more targeted scaling of services under load.
What is a potential disadvantage of microservices in terms of system design?
-A disadvantage is that microservices can be challenging to design correctly. If a service is overly granular or only communicates with one other service, it might not be a true microservice and could lead to unnecessary complexity.
How does the complexity of tests differ between monolithic and microservices architectures?
-Tests in a monolithic architecture can be more complicated due to the tight coupling of components. In a microservices architecture, tests can be more focused and isolated to individual services, which simplifies the testing process.
What are some examples of companies that successfully use a monolithic architecture?
-Stack Overflow is a well-known example of a company that uses a monolithic architecture effectively.
Which companies are known for their extensive use of microservices?
-Companies like Google and Facebook are known for their extensive use of microservices in their architectures.
Outlines
🤖 Monolith vs. Microservices: Understanding the Basics
This paragraph introduces the debate between monolithic and microservices architecture in software engineering. It clarifies misconceptions about monoliths not necessarily being single machines and microservices not being tiny, but rather single business units. The monolith architecture is scalable, suitable for small cohesive teams, has fewer moving parts, easier deployments, and faster execution due to local calls. However, it has drawbacks like steep learning curve for new team members, complex deployments, challenging tests due to tight coupling, and the risk of a system-wide crash due to server errors.
🚀 Advantages and Disadvantages of Microservices Architecture
The second paragraph delves into the advantages of microservices, such as ease of scaling, simplified onboarding for new developers, ease of parallel development due to less dependency, and more transparent load management for deployment. It also touches on the disadvantages, including the complexity of designing a microservices architecture, the potential for unnecessary fragmentation, and the need for a skilled architect. The paragraph concludes with advice for system design interviews, advocating for microservices in large systems and referencing successful implementations by companies like Google and Facebook, while also pointing out Stack Overflow's successful use of monolithic architecture.
Mindmap
Keywords
💡Monolith
💡Microservices
💡Scalability
💡Cohesive Team
💡Deployment
💡Remote Procedure Call (RPC)
💡Context Switching
💡Parallel Development
💡Decoupling
💡Gateway
💡System Design Interview
Highlights
Monolith and microservice architectures are compared in software engineering discussions.
Monoliths are often misunderstood as single machines; they can scale horizontally across multiple machines.
Microservices are not defined by size but by the single business unit they encapsulate.
Monoliths can be advantageous for small, cohesive teams due to less complexity in deployment and maintenance.
Monolith architecture simplifies testing and reduces the need for code duplication across services.
Monoliths offer faster execution as they avoid network calls and RPC overhead.
New team members in a monolith setup may struggle with the large context required for understanding the system.
Deployments in monoliths can be complicated due to the need for frequent and monitored updates.
Monoliths can be risky as a single point of failure can crash the entire system.
Microservices provide easier scaling by focusing on individual services and their dedicated data.
New developers can quickly integrate into a microservices architecture by focusing on specific services.
Parallel development is facilitated in microservices due to reduced dependencies between teams.
Microservices allow for more granular scaling and resource allocation based on service load.
Designing microservices requires careful planning to avoid unnecessary complexity and service fragmentation.
Microservices architecture is often preferred for large systems in system design interviews.
Examples of successful monolith and microservices architectures include Stack Overflow and companies like Google and Facebook.
The discussion invites viewers to share their thoughts on the monolith vs. microservices debate in the comments.
The video provides relevant links in the description for further reading on the topic.
The video encourages viewers to subscribe for more content and to like the video if they enjoyed it.
Transcripts
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
Browse More Related Video
5.0 / 5 (0 votes)