What is a MICROSERVICE ARCHITECTURE and what are its advantages?

Summary

The 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

00:00

🤖 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.

05:00

🚀 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.

Keywords

💡Monolith

A monolith in software architecture refers to a single, unified system that runs as one application. It is traditionally viewed as a large, all-encompassing system but, as the script clarifies, it can also be horizontally scaled across multiple machines. The monolith is central to the video's discussion on architectural choices, contrasting with microservices as an alternative approach. The script mentions that monoliths can be advantageous for small, cohesive teams and when there's less complexity in deployment and testing.

💡Microservices

Microservices represent an architectural style where an application is composed of small, independent services that communicate over a network. Each service runs a unique process and is often developed around a specific business capability, as highlighted in the script. The video emphasizes that contrary to the name, 'micro' does not refer to the size but to the focus on a single business function. Microservices are a key point of comparison to monoliths in the video, showcasing their benefits in scalability, team collaboration, and deployment.

💡Scalability

Scalability is the ability of a system to handle a growing amount of work by adding resources or by making efficient use of existing resources. In the context of the video, both monoliths and microservices offer scalability, but they do so in different ways. Monoliths can scale out by adding more machines, while microservices inherently support scaling by focusing on individual services that can be independently scaled based on demand.

💡Cohesive Team

A cohesive team is one where members work closely together towards a common goal. The script suggests that monolith architecture might be more suitable for a cohesive team due to the unified nature of the codebase, which can simplify the development process as opposed to the potentially fragmented view in a microservices architecture.

💡Deployment

Deployment in software development refers to the process of making a software application available for use. The video script discusses how deployment can be simpler in a monolith due to the single codebase, whereas in microservices, each service may require individual deployment strategies, which can complicate the process but also offer more flexibility.

💡Remote Procedure Call (RPC)

RPC is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand the network's details. The script contrasts RPC calls, which are used in microservices to communicate between services, with local calls within a monolith, which can be faster due to the absence of network communication overhead.

💡Context Switching

Context switching is the concept of moving attention from one task to another. In the script, it is mentioned as a potential disadvantage of monoliths for new team members, who need to understand the entire system's context, compared to microservices where they can focus on the context of a single service.

💡Parallel Development

Parallel development refers to multiple developers or teams working on different parts of a project simultaneously. The video script points out that microservices facilitate parallel development due to reduced dependencies between services, which is a contrast to monoliths where changes in one part of the system can affect others.

💡Decoupling

Decoupling in software architecture means creating a system where components have minimal dependencies on each other. The script discusses how microservices inherently support decoupling by having services that operate independently, which is beneficial for maintenance and updates, unlike monoliths where components are more interdependent.

💡Gateway

In the context of microservices, a gateway is an entry point that clients connect to, which then routes requests to the appropriate services. The script explains that clients may not connect directly to microservices but instead to a gateway that manages communication internally, which is a key architectural pattern in microservices.

💡System Design Interview

A system design interview is a technical interview process where candidates are assessed on their ability to design large-scale systems. The script mentions that justifying the use of microservices over monoliths is a common scenario in such interviews, especially for large systems, as microservices are often considered the default choice for their scalability and flexibility advantages.

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