Monolithic vs Microservice Architecture: Which To Use and When?

[@olter1000]

Thank you very much. You stopped me from overengineering and solving problems which doesn't exist for now in my startup.

[@dreamsachiever212]

me too lol

[@guyrandalf711]

What did you decide to do then? Please, share

[@olter1000]

@@guyrandalf711 I just started coding monolithic application and trying to focus on a quick implementation rather than perfect architecture and code style (it was not easy since I always want to build something in a best possible way, but reality is your first alpha/beta release won’t be ideal in any case).

[@muhammedkhaled8128]

@@olter1000 The good thing is that you will be able to pinpoint the issues coming from a monolithic initial version and if you need to go for micro-services, that's even better than trying to have the best architecture from the start which is practically impossible.

[@thabangmotaung9637]

The structure of your content delivery makes it easy for me to understand these concepts in a snap.

[@alexhyettdev]

That's awesome, I am glad to hear it!

[@purdysanchez]

Before microservices a lot of systems were just separated into normal sized services as web APIs. Microservices IMO advocated building everything with FaaS for dubious scalability reasons. Most systems weren't monoliths before the advent of microservices.

[@codewitgabi]

I love how you explained when to use http calls instead of message brokers for service communication. HTTP calls for synchronous requests and AMQP for asynchronous calls

[@MaximePoulain]

A topic that could be interesting to delve further into is the Modular Monolith. In contrast to microservices where the boundary is just physical, modules in a monolith are logically isolated from each other. This brings benefits like faster deployment and helps avoid issues of creating 'spaghetti code' that could cause problems for others. However, designing a modular monolith can be challenging, as it requires expertise in the design of your domain and the identification of its sub-domains (bounded context in DDD terminology) but also with the communication when an operation span accross multiple modules. Overall, I believe this approach combines the pros and cons of both monolith and microservices architectures effectively for many use cases.

[@hyper_channel]

This right here is my go to. A monolith where the different services / features can be extracted as a microservice if needed, (usually those hurting for resources / performance). Microservices just have too much overhead and moving parts to make sense as the starting point without a very good reason.

[@cflowlastname548]

Before the Microservice hype, these system were just called modular systems. I actually wrote one myself based on my own intuition and experience. It was not until a couple of years later when I saw the word "Modular monoliths" in my youtube feeds I realized there was an exact word for what I had done.

[@masickboi]

kzbin.infoBZxSDkVcwhU?si=HkQ2Ly-GnzI66pnE

[@bamienbillard]

Well explained. Thank you!

[@PieterWigboldus]

If microservices are ride coupled, you have monolith microservices. It runs a monolith just on multiple services/processes. Microservices are very nice if you can break the most lines between the different parts, and you have the most benefit. But it takes a lot of time to learn how to do. And be aware that you dont have more microservices than active users 😊

[@mishamovdivar]

Scaling is not an issue for Monolithic application and it's not gonna cost you fortune. Look at the Path Based Load Balancing which results in the similar flexibility when it comes to scalability for monoliths as for microservices. "When deploying one microservice, other microservices are not affected" - well, no, more often than not, they are affected

[@resistance_tn]

This is high quality work thank you ! Would love to see more advanced topics on networks or protocols or anything related to backed ! Keep up the great work :)

[@alexhyettdev]

Thank you! Yes I will be definitely be covering more backend topics.

[@puliranjit]

Love your learning videos ..well-structured , short and to the point

[@alexhyettdev]

Thank you! I am glad you like them!

[@adp8704]

this is beautifully explained - thanks for this.

[@vktop2]

Nice video, I have a question, for example in a system I have a microservice customer and this service will have in its database a table with the types of customer document, in this system could also exist a microservice user and could also have in its database a table type of user document, in this case how to work these data that concern several microservices since the types of documents are common between both entities; should I create 2 tables document type 1 in each microservice? Thank you

[@alexhyettdev]

Microservices should always have their own database. If you have data that is common between them, then you can have copies of the same data in each database. Not ideal, but it is quite common practice. Each domain only stores the data they are interested in. One option for you would be to have a document microservice that all the other microservices use for file storage. This is particular useful when you have strict requirements such as encryption or access restrictions that you need to adhere to. It can all be done in one place without needing the same logic in every microservice that needs to store documents.

[@xiiEJRAM]

Your videos quality and the content you made are epic , I really love your channel 👌🏻

[@alexhyettdev]

Thank you very much!

[@franciscodevia7446]

Ñ😊ñññ😊ññññ😊ññññññ😊😊😊😊

[@franciscodevia7446]

00pp0p00pppp0pp0ppppp0ppppp0pp0ppppppppppppppp0ppppppp

[@eleojoadegbe]

Thank you @Alex great video answered all my questions and more

[@somevids6230]

For most business processing, you can get A LOT of mileage out of specific purpose built monoliths, and all of their inherent advantages. Spreading function calls out over vast networks should almost always be a last resort.

[@fahadaslamtanoli]

very good explanation can you explain when to use service endpoint or service bus

[@expirationstrategist]

Very informational, thanks

[@alexhyettdev]

Thanks Marcin, I am glad you liked it!

[@gangstaberry2496]

I love your videos ❤ I recommend them to everyone

[@bvreddy1074]

content and delivery at it's best, Thank you so much for your time and efforts, keep inspiring and educating 😊.

[@gabrielnzete8913]

Fantastically explained

[@Ramin_Esfandiari]

Very well done and concise video. Thank you.

[@alexhyettdev]

Thank you 🙏

[@Jabali04]

**Summary: Monolithic vs Microservice Architectures** 1. Monolithic Architecture - All functionalities reside within a single codebase or project. - Simpler to develop and maintain initially, as it involves managing just one "component." - Internal communication is seamless, eliminating performance concerns between functionalities. - Challenges arise as the application grows: - Larger, more complex deployments. - Scaling issues: the entire application must scale, even if only one feature demands it. - Longer development and release cycles due to tightly coupled components. 2. Microservice Architecture - The application is divided into independent, smaller services, each focusing on specific functionalities. - Advantages: - Independent maintenance, development, and scalability of components. - Greater flexibility to scale individual services based on demand. - Challenges: - Increased complexity in development, testing, and debugging, especially for multi-service environments. - Difficult to simulate the entire application locally. - Higher infrastructure costs for small-scale applications. Communication Between Microservices: 1. API (Synchronous): Direct communication between components, often via REST or GraphQL. 2. Message Broker (Asynchronous): Tools like RabbitMQ enable decoupled communication by passing messages between services. 3. **Service Mesh:** Ensures service discoverability, communication reliability, and monitoring across microservices.

[@Venkatesh-vm4ll]

Really thank you for the word , start business with monolithic, i am confused in that

[@alexhyettdev]

Microservices are usually a bit overkill if you are starting out with a new application with no traffic. In these cases one big application (monolith) is usually better until you have scaling problems and need to split it up.

[@eugenek777]

Thanks for a very useful overview

[@muhammadwaqasiqbal8243]

Hi there Alex, Lovely video and It has cleared a lot of misconceptions regarding both architectures, I have a question however, Is there any metric value or any parameters defined based on which we could choose one or the other? I would really appreciate your take on this. Thanks

[@Pankecal-v4k]

this is such a gold content. Thank you so much Alex

[@alexhyettdev]

You're welcome, thank you for commenting!

[@amitev]

Great content and great video quality! What microphone are you using?

[@alexhyettdev]

Thank you, I am using a Blue Yeti X. I have had the same microphone for all of my videos but the sound quality wasn't as good to start with. The key is to have the microphone as close as possible and to make sure you have lots of soft furnishings in your room to absorb any echos. I now have curtains, cushions, a rug and a fluffy blanket to absorb the sound. Video wise I am just using my iPhone XR with the OBS Camera app. My earlier videos used a Logitech Brio 4K but the colours were always a bit off.

[@amitev]

@@alexhyettdev thank you very much for the comprehensive answer! Ideas for next videos - how to manage complexity; how to manage work/technical debt in a huge legacy code base, hope to cope with toxic cowerks/arrogant seniors.

[@alexhyettdev]

Thanks for the ideas, I will add them to my backlog!

[@elifantshoos708]

Dying. The stock footage of code magically getting manifested on the scenes as the person is waving around their finger. LOL

[@abelmillion4341]

Good Job man, am grateful for your videos

[@alexhyettdev]

Thank you! I am glad they are useful for you.

[@brayanjpm]

What do you think about tools like TurboRepo ? I mean, we can use that tool for our apps minimizing the disadvantages of monoliths ?

[@yourownazog8069]

amazing content and the level of my production. Thanks for what your doing

[@celsoguerra2234]

Many thanks. This information is super informative

[@hmatpin]

In the case of Netflix, will different UI components talk to the same API and share the same authentication? If the JS talks to different APIs, how are the cross domain requests authenticated? Or is it that only one API talks to all microservices on the backend, and only one API returns the UI data?

[@yankluf]

Sooo clear!! Thanks a lot! 😁

[@alexhyettdev]

You're welcome 😊

[@vijayas8007]

Wow Alex very well explained .. I went through many videos finally i got the difference as I come back from a break in my IT career. Thanks looking forward for more of such. Do you have anything on API manager

[@Nicetrycutiepie]

great in detail explanation. thank you so much Alex.

[@blakeacheson9387]

The scale argument against a monolith doesn’t hold any water … if a certain part of your application is getting accessed more frequently it doesn’t matter … the other dormant areas of the system are just taking up a relatively small amount of disk … there is almost zero penalty to scaling replicas of everything

[@sosyalant]

you deserve more subs. Fantastic job

[@alexhyettdev]

Thank you! Hopefully one day!

[@mumasmusic]

Great work! One small suggestion tho. The constant bg music is quite distracting.

[@alexhyettdev]

Sorry about that. I have turned it down a lot in my newer videos. I would get rid of it completely, but it seems to improve retention.

[@halooshka1904]

love the explanation! Very easy to understand :) Thank you

[@alexhyettdev]

I am glad you liked it! Thanks for commenting.

[@korniszon68]

Wow, can't belive you have that little views. It's very nice told, all the pros and cons. You really know this stuff well. I always ask this question on the interviews and it appears that it's not that clear to most of devs :(

[@alexhyettdev]

Thank you! Yes unfortunately useful videos on software development don't always get as many views as other topics. Maybe I should do a series on topics to learn before going for an interview!

[@nikoman71326]

great video content and production!

[@geybriyel2416]

this is very clear. thank you

[@imanshirkhodaee1704]

This is a very helpful content. thanks a lot.

[@alexhyettdev]

You're very welcome!

[@faizanahmed9304]

amazing video

[@alexhyettdev]

Thanks I am glad you though so!

[@rmanjit]

Great work !! This is high quality content !!

[@alexhyettdev]

Thank you!

[@k.alipardhan6957]

why is scaling a monolith considered hard/inefficient? 3:33 if you're getting high CPU usage, just add more hosts to the cluster. isn't it that simple? it doesn't matter if 20% of code gets 80% of traffic. maybe problematic if some code is memory intensive while the highly used code is not

[@vishalkarthik.v7209]

Hello Mr.Alex if there are multiple application and we use monolith then should we use one single piece of code or respective codes for respective application Thank you !

[@alexhyettdev]

Generally with monoliths we are talking about one single application but in some cases you can have smaller supporting applications that go with it. I prefer to do one git repository per application but in the case of microservices that are closely related it can be easier to just have a mono repo.

[@vrjb100]

When you cannot write a clean monolith, what make you think you can write clean microservices? When you cannot do the ops part of a monolith, you can do the orchestration of microservices?

[@mfachrizal]

Is right, the microservice just become giant monolith

[@MalkiNawal-u1u]

This is just perfect

[@Munchopen]

Defining a monolith around how you code is organised in repositories is a complete misunderstanding of what it means to have a monolith. It’s is completely possible to have a monolith split across multiple repositories. It doesn’t make it a microservice either just because it’s a small amount of code in a single repository.

[@anjanigente4538]

can one microservice depend on the other? and also is it necessary to have separate database for each microservice?

[@mfachrizal]

Definitely will have. Depend microservice to each other is something can't be avoided

[@BenRangel]

The distinction is too blunt for my taste: i view microservices as one team separating their work into more than one service despite not really having to. And monoliths being a big service used by multiple teams. But most use something in between: pretty much one service per team

[@tk7577]

Awesome super helpful

[@thisiskartik]

Your video is awesome

[@david2am]

thanks!

[@alexhyettdev]

You’re welcome!

[@marcocoratella1556]

In fact the handsome developers, that want absolutely to show how handsome they are, they say that microservices is amazing. But indeed you need to be pragmatic and really understand what means working as a software developer sometimes first of all

[@joeddo]

great video. ty

[@bramburn]

Monolith 🌱🌱 done let's move on 😁

[@kasparsr]

modular modulyth

[@aminzuar5767]

Thank uuuuu 🙏🙏🙏

[@alexhyettdev]

You’re welcome, I am glad it was helpful.

[@ITSolutions-bl3dp]

Thanks ❤sir

[@kimberlyjacobsen4148]

No changes to Email service ? ? After changes to Azure and Outlook we now need To use 2-factor Auth.. thus Breaking the SMTP login. Add new Endpoints for MS and a Gui so we can authorize the Token. blah blah Point .. NO microservice is Imune to changes

[@alexhyettdev]

Very true. You would hope something as simple as email would be immune but very much depends on the provider. I have a few very simple Lambda functions that haven't touched in 2 years, however I am now forced to update them as the version of node they are running on will not be support soon.

[@giorgikhachidze64]

Service mesh wasn't explained clearly at all. Too vague.

[@alinaqvi2638]

Linux is a bunch of microservices that looks like a monolith.

[@jonny.rubber]

I feel the ping is unaccairy

[@xConundrumx]

I almost could not disagree more on these advantages you claim Monoliths have. Mostly because in reality nothing ever remains even remotely small enough for those advantages still hold up. Every single 'monolith' I have worked on in my 30 years turned out to be a massive app before it got to production. And that was with all the trimmings of those times. And you always, ALWAYS en up with a mess when multiple people have to work on it. Just my 2 cents.

[@alexhyettdev]

It really does depend on the scope of the application. If you have a team of 8 working on big enterprise application that you know is going to end up quite large then just start with microservices or at least mini monoliths. If you are building your own startup with just 1 or 2 developers, and you are not building into an existing architecture then a monolith will always be quicker. It is a case of not solving for problems you are not even sure you will have.