Monolithic vs Microservice Architecture: Which To Use and When?

Hello friends, welcome back to the channel, so in this video we will cover the differences between

monolithic

and

microservice

architecture

and more importantly,

which

one you should use in your next project. Each

architecture

has its own pros and cons, so hopefully, by the end of this video you will understand

which

one you should use. So what is a monolith before we had

microservice

s? Everything was built as a monolith. A monolith is an application where everything works as a single piece of code. It is generally the starting point for anything new. application, whether it is an API or an interface, and usually ends up with an executable in a repository, your application is then developed, deployed and scaled as a single component, if you are working in a team on the same application you need to ensure that don't step on each other's toes, anyone who has had to work on a big code change all at once, like a big refactoring, will know the pain of having to merge everyone else's changes into your code now before So let's go and cover the issues with monoliths they have a number of key advantages over microservices, firstly, monoliths are really easy to develop, all your code is in one place, you don't have to worry about querying a lot of different repositories and

when

it comes to actually testing your app you only have to worry about one app, if you are working on a small app this makes a big difference in the time it takes to develop it, most apps start out as monoliths simply because it is much more quickly achieve them.

The number two monoliths on the market are really easy to implement. After all, you only have one application to worry about, on top of that you only have one CI CD Pipeline and one infrastructure to worry about. Number three is that they are easier to debug if you only have one application, then you only have one place to look. If there is a problem, the real benefit comes

when

you debug your application locally. Going through one application is much easier than having to go through several, and if you are running multiple applications, you need to make sure they are all running on different ports.

The last advantage of

monolithic

architecture is performance. Now I won't go as far to say that monoliths have more performance in microservices, however with a monolith you don't need to worry about latency if you only have one application then there will be negligible cost between the different parts of your code that are being run. call each other, what we'll see with microservices gets a little more complex, so if monoliths are so cool, then why should we bother with microservices despite the benefits? Monoliths have some glaring issues that typically cause teams to move to microservices later. The first is that monoliths tend to get really big after all if you only have one app.

To include all those features will eventually become bloated, every developer starts with good intentions and applies clean code practices to make sure their app is easy to maintain, but even the best designed app starts to look like a giant mess once that comes to an end. a certain size if it takes more than a month to onboard a new developer to your team after explaining all the different parts of your app, then you probably need to look at other options. Number two is that your release process is taking too long if your app has a lot of different features, which is a lot of different things that you need to test before each release, since your app is just one big component, even the smallest changes require you to release the entire application each time, depending on your application and the maturity of your CI.

CD pipeline, it can take a long time to do a release, especially if you need to worry about switching traffic between green and blue services, as well as monitoring logs. Lastly, the main problem with monoliths is that they are really difficult to scale if one part of your application is receiving a lot of traffic then you have no choice but to scale the entire application, this means spinning up more instances of your API or beefing up the CPU or your server memory, either way it will cost you a lot of money because your application is so big now that you have seen all the disadvantages of monoliths, especially as your application grows, we can take a look at the solution which, for Of course, it's microservices with microservices, we take your big monolithic application and break it.

It is divided into individual components, each component has a single responsibility and is generally in charge of a single business functionality. If you take Netflix for example, you might have one component in charge of search, another in charge of streaming videos, and another in charge of recommendations. Each service is autonomous and independent of all the others, they all have their own infrastructure. and your own database for example each microservice is its own application, has its own version and is released separately from all the others if you split your application into microservices how can you get them all to talk to each other?

There are three main ways that microservices can communicate. The first is through API. Each microservice has its own endpoint that the other microservices can call. This should be used when synchronous communication is needed between your component microservices usually also have a status endpoint to make sure you can ping them to know they are still operational, since with all HTTP requests, this will introduce some latency in your application you should take it into account as possible. use things like grpc and compression to speed up communication, the second option is to use a message broker, if what your application needs to do can be done asynchronously then you'd better use a message broker to do this for example , if your app needs to send an email, it's usually not important for your app to get a response from the SMTP server, it's much easier to just put that message into a message queue and have your app continue doing what it was doing, then you can have a microservice that listens to that message queue, picks up the message, and sends it as an email.

There are quite a few Cubase technologies out there, but the most popular are things like Rabbitmq or AWS sqs. The last option is what we call a service mesh. It handles all the communication, as well as taking care of the discoverability and reliability of your services. Obviously, no one would use microservices if they didn't have a number of key benefits over the monolithic design. A well-designed microservice is only responsible for one thing. and as a result, they are much easier to maintain. In many cases, you may not need to touch a microservice at all if you take the email microservice we mentioned above, chances are the requirements won't change for that microservice. therefore, it will continue to run doing what you programmed it to do without requiring any updates.

Compare it to a monolith where you redeploy your application with every change and then add the potential for something else to work. incorrect in another part of your application as you only need to deploy a single microservice when something changes, the other microservices are not affected, as a result your application becomes more reliable as there is less chance of your entire system crashing due to a problem with a component, this is why if you see outages like GitHub, it is very rare for the entire system to fail, usually only one or two functionalities are affected, it may be web links that stop working or you cannot confirm your code. but it's very rare for the entire application to go down unless it's an infrastructure issue like a DNS failure.

The next advantage of microservices is that each team can choose their own technology stack. This can be a blessing and a curse in some languages. are better suited for particular tasks than others, take machine learning for example, it's much better to write that in Python than C Sharp for example, however if teams have complete freedom over their own technology stack then they can end up reinventing the wheel. Whenever you build a microservice, it's much more efficient to use the same technology stack for all of your microservices and only deviate when it makes sense to do so.

Being able to have multiple teams working independently on the same application is one of the big selling points for microservices, the next advantage for microservices around scalability, as we saw with monoliths, if you have a part of your application that receives more requests then you have no choice but to scale your entire application, but at least if it's a microservice then you can scale. that microservice and will therefore save you some money in the process. Lastly, if you want to get to the point where you're releasing multiple times a day, you need to make sure each change can be easily tested and automated if you're working. in a monolith this is really hard to do as even the smallest change can affect the entire application;

However, with microservices, your change is limited to a small component that can be easily tested and deployed independently. It's not all good news for microservices, there are several. of disadvantages that you should be aware of if you plan to use it in your next project if your microservice depends heavily on other microservices to function then it will be very difficult to run your application locally when you need to develop you can resort to mocking all other endpoints or then you need to spin up Docker containers for all the different microservices. It can be done, but it's a little harder to do than running a single application.

Microservices are also harder to debug when you have a problem in production, you have to review multiple different services to determine where the problem originated. That's why it's important to have good monitoring when using microservices to know when a particular component is down. or not behaving correctly, this is where using a service mesh comes in handy. I mentioned earlier how microservices can save you money on infrastructure but that only happens when your app is trying to scale if you have a small app however then you have a lot of infrastructure that you have to pay for that you didn't need before with a single app if your app is large and you have an uneven distribution of requests and it is generally cheaper than trying to scale a monolith if If you have a small application, you will see a large upfront cost in infrastructure when using microservices.

Lastly, microservices increase the complexity of your entire system, make your information structure more complex, you have multiple cicd pipelines to deal with and you also need to worry about communication between your services, on top of that you need to have a good monitoring to know what all your microservices are doing, this may not seem like a big deal when you only have a handful of microservices, but once you have hundreds it can become an operational nightmare now that we've gone over the pros and cons of each of architectures, so which one should you use in your next project if you're starting a new application that doesn't go into any existing one. of a structure, then I recommend starting on a monolith, there is no point in trying to solve scale problems that you don't have yet.

If you are in a startup, then your main concern should be trying to get to market as quickly as possible. You can deal with scaling issues when you actually have them and you have some paying customers, most apps, even Netflix started out as a monolith, it was only when they needed to scale that they decided to break things up into microservices. There is a scenario where you should do it. you will probably start with microservices and that is, if you are connecting to an existing workflow, if you know that your application is going to receive a million requests from day one, then you need to plan accordingly, in that case it is usually better to start with microservices or at least a semi monolith with key components split into their own services once your application is live you can see if it makes sense to split that semi monolith into multiple microservices.

This is how I would consider splitting a monolith into a microservice. Check it out. in your monolith and see which components would make sense to run on their own, look at which parts of your application have scaling issues, and which ones can be run synchronously or asynchronously if you're not sure which architecture you should use for your microservices. then you need to watch this video about hexagonal architecture. Thanks for watching and see you in the next video.