Monolithic vs Microservice Architecture: Which To Use and When?

[00:00] So in this video, we are gonna be covering the differences between monolithic and microservice architecture, and more importantly, which one you Each architecture has its own pros and cons.

[00:12] which one you should be using. Before we had microservices, everything was built as a monolith. It's usually the starting point for any new application, whether that be an API

[00:28] or a front end, and you usually end up with one executable in one repository. scaled as one single component. you don't step on each other's toes.

[00:41] as a big refactor, will know the pain of having to merge everyone Now, before we go and cover the problems with monoliths, they do have a number

[00:53] First of all, monoliths are really easy to develop. You don't have to worry about checking out lots of different repositories. one application to worry about.

[01:07] in the time it takes to develop. lot quicker to get them to market. After all, you've only got one application to worry about.

[01:22] infrastructure to worry about. If you've only got one application, then you've only got one place that The real benefit comes when you come to debug your application locally.

[01:36] multiple, and if you're running multiple applications, you need to make sure that The last advantage of monolithic architecture is around performance.

[01:48] performant than microservices. However, with a monolith, you don't need to worry about latency. cost between the different parts of your code calling each other.

[02:01] So if monoliths are so great, then why should we bother with microservices? Despite the benefits, monoliths do come with some glaring issues that usually that monoliths tend to get really big.

[02:17] in is going to get bloated over time. practices to make sure that their application is easy to maintain. But even the best designed application starts to look like a giant mess

[02:32] If it takes over a month to onboard a new developer to your team, after are you need to look at other. If your application has lots of different features, that's a lot of different things

[02:49] As your application is just one big component. whole application each time. Depending on your application and the maturity of your CI/CD pipeline, it

[03:02] Especially if you need to worry about switching traffic between green and blue Lastly, the main problem with monoliths is that they're really difficult to scale.

[03:14] If one part of your application is getting a lot of traffic, then you have no choice This either means spinning up more instances of your API or beefing Either way, it's gonna cost you a lot of money because

[03:28] Now that you've seen all of the disadvantages of monoliths, especially We can have a look at the solution, which is of course microservices. it down into individual components.

[03:43] of a single business functionality. If you take Netflix for example, they might have one component in charge in charge of the recommendations.

[03:57] Each service is self-contained and independent from all the. For example, each microservice is its own application. If you split your application into microservices, how do you get

[04:12] Well, there's three main ways that microservices can communicate. Each microservices has its own endpoint that the other microservices can call. Microservices usually have a health endpoint as well to make

[04:29] As with all HTTP requests, this is gonna introduce some latency to your application However, you can use things such as gRPC and compression

[04:41] The second option is to use a message broker. If what your application needs to do can be done asynchronously, then you're better For example, if your application needs to send an email, It's not usually

[04:55] important that your application gets a response from the SMTP server. and have your application carry on doing what it was doing. You can then have a microservice that listens to that message, queue, picks up

[05:08] There are quite a few queue based technologies out there, but the most popular ones are things like RabbitMQ or AWS SQS. The service mesh handles all of the communication as well as dealing

[05:22] Obviously no one would use microservices if they didn't have a key number of A well-designed microservice is only responsible for one thing, and as a

[05:34] In many cases, you might not need to touch a microservice at all. are that the requirements aren't gonna change for that microservice.

[05:46] without you needing to make any updates. application with every single change. another part of your application, as you only need to deploy a single

[06:01] The other microservices are unaffected. As a result, your application becomes more reliable as there's less chance that your whole system is gonna come crashing down because of a problem with one component.

[06:13] This is why if you look at outages such as GitHub, it's very rare It's usually just one or two functionalities that are affected. It might be web hooks that stop working or you can't commit your code, but it's

[06:25] issue such as the DNS failure. their own technology stack. Some languages are more suited to particular tasks than others.

[06:41] You're much better off writing that in Python than you are in say, C#. However, if teams have completely free reign over their own technology stack, then you can end up reinventing the wheel every time you create a microservice.

[06:54] your microservices and only deviate when it makes sense to do so. application is one of the big selling points for microservices.

[07:07] as we saw with monoliths. requests, then you have no choice but to scale up your whole application. microservice and therefore save you some money in the process.

[07:23] Lastly, if you want to get to the point where you are releasing multiple times per day, then you need to make sure that each change can be easily tested and automated. do as even the smallest change can impact the whole application.

[07:36] However, with microservices, your change is limited to a small component. It's not all good news for microservices. There are a number of disadvantages that you need to be aware of if you're

[07:49] If your microservice is highly dependent on other microservices to work, then it's development, you can either resort to mocking out all of the other endpoints, or

[08:02] you have to then spin up docker containers for all of the different microservices. running a single application. Microservices are also harder to debug when you have a problem in production.

[08:14] where the issue originated from. you're using microservices, so you know when a particular component This is where using a service mesh comes in handy.

[08:29] Now, I mentioned earlier how microservices can save you money on infrastructure, If you've got a small application, however, then you've got a lot before with just one application.

[08:43] requests, and it usually is cheaper than trying to scale up a monolith. If you've got a small application, then you're gonna see an initial large cost on Lastly, microservices increases complexity of your whole system.

[08:58] You have multiple CI/CD pipelines to deal with, and you also need to worry about On top of that, you need to have good monitoring in place so you know what This might not seem like a big deal when you only have a handful of

[09:12] microservices, but once you have hundreds, it can become an operational night. So which ones should you be using in your next project? any existing infrastructure, then I recommend starting on a monolith.

[09:29] If you are in startup, then your main concern should be trying to get You can deal with the scaling problems when you actually have them, and you Most applications, even Netflix started as a monolith.

[09:45] things out into microservices. microservices, and that's if you're hooking into an existing workflow. then you need to plan accordingly.

[09:59] or at least a semi monolith. Once your application is live, you can see if it makes sense to break down that This is actually how I would look at breaking down a

[10:15] Have a look at your monolith and see which components would Look at which parts of your application are having scaling problems and which ones can be run synchronously versus a Synchron.

[10:28] microservices, then you need to watch this video on hexagonal architecture. Thank you for watching, and I'll see you in the next video.