8:44 Many companies mention, that picking too many languages that "you like" makes the project too difficult to maintain. It is recommended to use a very limited amount of languages and limit the toolset as much as possible, to make the whole architecture more reliable and stable
Haha some companies like Netflix use whatever language. But most companies stick to a couple. My company is only .NET/C#. Someone even tried to write F# and it was blocked.
@@hellowill I agree with that policy, as the more things you use, the more rigid parts you have to maintain. For companies that are not Netflix this is a pain in the ass, really
## Table of Content 01:30 Traditional Services Explained: 04:00 Microservices Example 08:00 Microservices Pros 12:20 Microservices Cons Microservices technology is a new pattern of software engineering that has been popularized recently. In this video, we will explain what microservices are, their pros and cons by example. Microservices Pros: - Polyglot architecture - Easy scaling for microservices that needs scaling. - Better Team management, each microservice is a team - Easier to innovate certain areas. - Each microservice can pick their own database - Scale busy services instead of the entire system Microservices Cons: - Very complicated to implement, network call, service discovery - Very Difficult to debug - Hard to find where the fault is - Network calls fail adds complexity.
Great video. But in the cons, there are two more: 1, data in sync (can use event sourcing as a method). 2, make security more complex(use methods like Oauth2, review for security model of each microservice ) .
Hussien, keep doing your thing brother, it’s great to see content like this. I think it’ll also be cool to mention here that there are managed services one can pay for to handle all the networking and communication between servers and applications running on them (such as cloud managed kubernetes). Maybe this could be a good segue into teaching kubernetes. I’ll be happy to contribute as well, I think your content is really amazing.
Thanks man. After I watch this video I'm going to try to build just a simple microservice and then I'm going to apply the pros and cons that you talk about here.
Another con (maybe somewhat covered by the "complicated" umbrella) is that each team now has a fairly significant burden in terms of supporting the interface to their service. Splitting the monolith up allows things to be more isolated, and for teams change/deploy their service more independently - but this doesn't come for free! Now the API to each service is almost like a public API in that you have a bunch of "external" customers who you need to support, in the form of the other teams. Teams may need to maintain multiple versions of their API simultaneously if they ever change the interface, and there is work which comes with that. They probably also need to document their API to an extent which might not have been necessary if it was just a module within a single codebase. Another con is that resources are potentially being used less efficiently than with a monolith - you have extra network calls, serialization/deserialization, authorization between services, and overhead associated with more instances existing in general (e.g. JVM memory overhead if these are Java services, or overhead from more OS / container instances existing overall). This one is offset of course by the ability to tune, scale, and pick the most appropriate tech for each service independently though.
A challenge that I face with this architecture is code reusability among services, especially if it involves business logic. But personally, I prefer this pattern rather than the old monolithic approach. Good video!!!! Regards!!!!
Thanks Alain, Code reusability is interesting, you would still need to import some libraries in your clients However I suspect you will need to architect your system such that you don't have to reuse the code but instead ask another service to execute it for you.. this will be expensive of course as a result
( i am a jr. dev lol. please correct me) Not having a single point of failure. Always thought that is one of the most important pros for using microservices. Didn't see it mentioned here. Is it not that imp like I thought? (for polygot usecase) Isn't using multiple languages is always possible with interoperability? Why use multiple services? (for better team management argument) Team management can be done well in monolith as well. Can't git submodules be used or some other tech? Only provide developers with the code they need. Developer flexibility should never determine where my servers are being placed right? That is a problem that can be solved with code , right?
It is so fun to watch and learning Hussein, you developed a didactic to grab the student attention, punctuating the important topic (word) when you are explaining. Really good stuff on this channel, I'm watching a lot of CS and "basic" protocols, databases, architectures, etc that any developer must know. I'm very glad that UA-cam recommended rapidly when I was searching for serverless and microservices resources. Great job so far, keep it up! p.s: I have an idea for you, to gather all this base knowledge for a developer. Reach me if you want chat about it :)
Matheus Felipe thanks 😊 Im really glad your enjoying the content. Would love to hear your idea shoot me an email h@husseinnasser.com and if you have any feedback on how I do better or what topic to cover next to let me know as well. Cheers
Your videos and the way you explain is so clear and helpful. One question: you said that network calls failing is considered one of the cons of microservices, but in monolith system, you would lose all your service if network call fails to the main server right? So microservices is still the better architecture there because only one service would go down. Am I right is missing something obvious there? Thanks.
Shane M thanks for your comment! So in monolith compared to microservice, a method call or a function call is replaced with a network call internally. You have far more network calls internally in microservices vs in monlith where you have everything is function and library calls. Yes both microservice/monthlith receive external requests through network, and this can also fail. Thats why we need load balancer even in the case of monolith and put copies of different monlithos behind it. But its far more expensive to scale and spin up monolith vs microservices as i explained Hope that helps! Thanks
Lots of benefits but lots can go wrong too. Personally not a big fan of everyone moving to cloud. Big dependency on AWS, Google etc. If they go down half the internet is down.
finding faults in micro-services is easier, you just need status code reports per service... finding it in a single service doing many things is harder because you have to add custom instrumentation
Great introductory video! I watched it at least 2 times. You mention how often you want two microservices to securely communicate with each other, in case a hacker already broke in (zero trust microservices?). How widely is this adapted today? Because it seems pretty costly to do TLS (+ maybe more crypto?) on the CPU for each and every communication between microservices.
Thanks Dennis Its actually important to do TLS between two services specially in the cloud or cross region communications The cost is cheap and fast with TLS 1.3 ECDH low bit size curves. Single handshake and fast crypto, plus its a one time cost at connection establishment only
@@hnasr Thanks for your reply. I’ll be sure to use those kinds of key exchanges. I was worried about the added cost of having to do the symmetric cipher for every message (after the handshake). But I guess that’s pretty cheap? If not, would it be realistic to use multiple CPU cores in your microservice’s container to pipeline decrypt request, encrypt response, process plaintext response if you know you have a lot of independent traffic going in? Or is it better to just parallelize separate requests as a whole rather than dedicating CPU cores solely to the crypto steps?
symmetric encryptions are fast and cheap and their cost is negligible, but if you are worried you can move to chacha which people proved thats its 3 times faster specially on mobile devices. On the cloud powered devices not really big difference. With encryption just watch out for large bit size such as RSA 2048 or 4096 that is very costly and insecure too
Hi Hussein. At the end of this video, you mention the sidecar pattern service mesh as one way to resolve the complexities brought about by microservices. After seeing your content, I am understanding that the sidecar pattern is another way of implementing microservices within a localhost. I don't see how the sidecar pattern offers a solution to some of microservices' cons. Can you please help me clarify this? Much love to you Hussein.
Andres Castillo hey Andres! Thanks for your comment and excellent question. Checkout the video I made on sidecar patterns. ua-cam.com/video/zcJWvhzkPsw/v-deo.html It helps elevate the complexity of communication to another layer
The Pros & Cons are always debatable. someone may argue that the design of a complex system as loosely coupled microservice will enhance the maintenance of the system and thus improve the debug process.
Hussain, Can microservice have one DB? What about if one microservice has a dependency of another if there are different DB? Like if comments service has a dependency of users services. Does they make a network call to that services or they directly connect the users DB in comments services?
Thanks Pule! Yes I do have this video explaining the evolution of containers ua-cam.com/video/8qU3hZOXlBE/v-deo.html and also I have a playlist called Docker with all my docker videos check it out ua-cam.com/play/PLQnljOFTspQWsD-rakNw1C20c1JI8UR1r.html Enjoy
I actually did here Check it out! Step by Step Basic Microservices System (3 NodeJS + 1 Load Balancer containers) with Docker ua-cam.com/video/9sAg7RooEDc/v-deo.html
hows that different from having multiple databases and multiple controllers for the url end points that can requests from those DBs? you can integrate postgresql and mongodb etc in one app or even multiple apps/servers and scale the dbs if needed. I dont understand whats the deal here
The example shown in this video is a kind of simplification to help to understand the concept at a general level. At this level of abstraction, you can find other alternatives like the one you have mentioned. In my opinon, the key point of Microservice is to achieve "extreme" horizontal scalability. In these kinds of scenarios, you will need to deploy the application on many servers (hundreds?). Even the term application needs to be redefined because each functionality/component has its own scalability needs. Therefore the application must be thought as a group of independent pieces of software (services). If your architecture is based on independent pieces, you also could have many development teams working in isolation and building new software very fast (working force scalability). At this point, "real" microservices architecture comes to solve these escalability requeriments. I said "real" because there are just plenty of "distributed monolothics" that are called "microservices" just because....you know.
How is referential data managed between micro-services? Tweets and InstaGram are relatively simple data-structures, what about ERP / CRM / financial systems? Are there examples of this done well?
Simon Roberts great question! Personally I did not see an ERP solution gone microservices yet. And no surprise there because as you said ERP is complex and as I explained in the “cons” section of the video Microservices are hard to implement. Its interesting, most ERPs are inherently designed to be a monolithic software with single relational database instance with extreme referential integrity and normalized structure. so breaking that down to CRM/ Asset management/ human resources /accounting microservices (with each of those potentially being more microservices each has its own database) is challenging. But as I think more about it, it is more natural for ERP to be microservices since each piece is kinda its own with some dependencies on other systems. I can imagine a CRM microservices with its own resources and database and the Accounting microservices with its own databases, then both talk through an API. If implemented correctly this could scale nicely. Again its very hard it is require complete redesign to break the referential integrity. Thanks for the question..
Great channel, and great content. One feedback I would like to make is that to me(just me) your english gets in the way of understanding, sometimes it's annoying. It would have been a lot better if you stick to the american accent with no arab-like pronunciation. Again, thanks for your work here. It's great
O my word how did I not know of this channel? These videos are truly amazing. Thanks.
thank you so much for watching and nice comments! Enjoy the content!
literally everyone’s reaction when they find this channel
@@stoic2454 INDEED! I'm now going thru the process of watching all his content and jotting down a bunch of notes into my zettelkasten notebook.
8:44
Many companies mention, that picking too many languages that "you like" makes the project too difficult to maintain. It is recommended to use a very limited amount of languages and limit the toolset as much as possible, to make the whole architecture more reliable and stable
Haha some companies like Netflix use whatever language.
But most companies stick to a couple. My company is only .NET/C#. Someone even tried to write F# and it was blocked.
@@hellowill I agree with that policy, as the more things you use, the more rigid parts you have to maintain. For companies that are not Netflix this is a pain in the ass, really
Why is this channel so hard to find ? Much underrated 🥺
I am glad you found it 🥳❤️ thanks
## Table of Content
01:30 Traditional Services Explained:
04:00 Microservices Example
08:00 Microservices Pros
12:20 Microservices Cons
Microservices technology is a new pattern of software engineering that has been popularized recently. In this video, we will explain what microservices are, their pros and cons by example.
Microservices Pros:
- Polyglot architecture
- Easy scaling for microservices that needs scaling.
- Better Team management, each microservice is a team
- Easier to innovate certain areas.
- Each microservice can pick their own database
- Scale busy services instead of the entire system
Microservices Cons:
- Very complicated to implement, network call, service discovery
- Very Difficult to debug
- Hard to find where the fault is
- Network calls fail adds complexity.
Great video. But in the cons, there are two more: 1, data in sync (can use event sourcing as a method). 2, make security more complex(use methods like Oauth2, review for security model of each microservice ) .
Thank you for breaking down complex topic into small understandable chunks.❤️
One of the only channels that keeps pushing backend knowledge. Thanks!
Very well explained. I particularly enjoyed the non biased approach to explaining the pros and cons of each architecture.
David Ross thanks Dave! Glad you enjoyed it. I try to stay non biased. Please yell at me if you see me be biased on one of my videos . Cheers!
I watched many videos explaining microservices but this is the first one that made it 'click' for me as a concept. Awesome video.
Hussien, keep doing your thing brother, it’s great to see content like this. I think it’ll also be cool to mention here that there are managed services one can pay for to handle all the networking and communication between servers and applications running on them (such as cloud managed kubernetes). Maybe this could be a good segue into teaching kubernetes. I’ll be happy to contribute as well, I think your content is really amazing.
Learned more watching this in less than an hour than my entire 3 hour uni class about microservices
Thanks man. After I watch this video I'm going to try to build just a simple microservice and then I'm going to apply the pros and cons that you talk about here.
All the best ! let us know how it goes Costantine
Keep up. This is the best and only channel that provides backend knowledge
Another con (maybe somewhat covered by the "complicated" umbrella) is that each team now has a fairly significant burden in terms of supporting the interface to their service.
Splitting the monolith up allows things to be more isolated, and for teams change/deploy their service more independently - but this doesn't come for free! Now the API to each service is almost like a public API in that you have a bunch of "external" customers who you need to support, in the form of the other teams. Teams may need to maintain multiple versions of their API simultaneously if they ever change the interface, and there is work which comes with that. They probably also need to document their API to an extent which might not have been necessary if it was just a module within a single codebase.
Another con is that resources are potentially being used less efficiently than with a monolith - you have extra network calls, serialization/deserialization, authorization between services, and overhead associated with more instances existing in general (e.g. JVM memory overhead if these are Java services, or overhead from more OS / container instances existing overall). This one is offset of course by the ability to tune, scale, and pick the most appropriate tech for each service independently though.
A challenge that I face with this architecture is code reusability among services, especially if it involves business logic. But personally, I prefer this pattern rather than the old monolithic approach. Good video!!!! Regards!!!!
Thanks Alain, Code reusability is interesting, you would still need to import some libraries in your clients However I suspect you will need to architect your system such that you don't have to reuse the code but instead ask another service to execute it for you.. this will be expensive of course as a result
This guy jokes around just like Saal Kaan;'s math videos. good stuff
Good stuff man. I am not even a developer and I managed to understand it.
Done ✔️ thanks for knowledge 🙏
( i am a jr. dev lol. please correct me)
Not having a single point of failure.
Always thought that is one of the most important pros for using microservices. Didn't see it mentioned here. Is it not that imp like I thought?
(for polygot usecase) Isn't using multiple languages is always possible with interoperability? Why use multiple services?
(for better team management argument) Team management can be done well in monolith as well. Can't git submodules be used or some other tech? Only provide developers with the code they need. Developer flexibility should never determine where my servers are being placed right? That is a problem that can be solved with code , right?
It is so fun to watch and learning Hussein, you developed a didactic to grab the student attention, punctuating the important topic (word) when you are explaining.
Really good stuff on this channel, I'm watching a lot of CS and "basic" protocols, databases, architectures, etc that any developer must know.
I'm very glad that UA-cam recommended rapidly when I was searching for serverless and microservices resources.
Great job so far, keep it up!
p.s: I have an idea for you, to gather all this base knowledge for a developer. Reach me if you want chat about it :)
Matheus Felipe thanks 😊 Im really glad your enjoying the content. Would love to hear your idea shoot me an email h@husseinnasser.com and if you have any feedback on how I do better or what topic to cover next to let me know as well. Cheers
So glad I found this channel! Incredibly useful content!
❤️❤️❤️
I love how you explain the IT things, thank you
Keep on explaining things with that humor, it makes it more enjoyable and less monotonous.
Thanks, will do!
cool.
thanks for the awesome content
Nice video. Don't forget about graceful degradation, which is typically only possible in micro-service architectures
Lots of appreciation from India!
One question sir, can I uses NGINX for services discoveries?
Yes but its not its main purpose.
thank yo so much for the channel 🙏😇
Your videos and the way you explain is so clear and helpful. One question: you said that network calls failing is considered one of the cons of microservices, but in monolith system, you would lose all your service if network call fails to the main server right? So microservices is still the better architecture there because only one service would go down. Am I right is missing something obvious there? Thanks.
Shane M thanks for your comment! So in monolith compared to microservice, a method call or a function call is replaced with a network call internally. You have far more network calls internally in microservices vs in monlith where you have everything is function and library calls.
Yes both microservice/monthlith receive external requests through network, and this can also fail. Thats why we need load balancer even in the case of monolith and put copies of different monlithos behind it. But its far more expensive to scale and spin up monolith vs microservices as i explained
Hope that helps!
Thanks
@@hnasr Thank you for explaining that.
Lots of benefits but lots can go wrong too.
Personally not a big fan of everyone moving to cloud. Big dependency on AWS, Google etc. If they go down half the internet is down.
finding faults in micro-services is easier, you just need status code reports per service... finding it in a single service doing many things is harder because you have to add custom instrumentation
Great introductory video! I watched it at least 2 times.
You mention how often you want two microservices to securely communicate with each other, in case a hacker already broke in (zero trust microservices?).
How widely is this adapted today? Because it seems pretty costly to do TLS (+ maybe more crypto?) on the CPU for each and every communication between microservices.
Thanks Dennis
Its actually important to do TLS between two services specially in the cloud or cross region communications
The cost is cheap and fast with TLS 1.3 ECDH low bit size curves. Single handshake and fast crypto, plus its a one time cost at connection establishment only
@@hnasr Thanks for your reply. I’ll be sure to use those kinds of key exchanges.
I was worried about the added cost of having to do the symmetric cipher for every message (after the handshake).
But I guess that’s pretty cheap? If not, would it be realistic to use multiple CPU cores in your microservice’s container to pipeline decrypt request, encrypt response, process plaintext response if you know you have a lot of independent traffic going in? Or is it better to just parallelize separate requests as a whole rather than dedicating CPU cores solely to the crypto steps?
symmetric encryptions are fast and cheap and their cost is negligible, but if you are worried you can move to chacha which people proved thats its 3 times faster specially on mobile devices. On the cloud powered devices not really big difference.
With encryption just watch out for large bit size such as RSA 2048 or 4096 that is very costly and insecure too
@@hnasr Got it. Thanks a lot for the tips.
Hi Hussein.
At the end of this video, you mention the sidecar pattern service mesh as one way to resolve the complexities brought about by microservices. After seeing your content, I am understanding that the sidecar pattern is another way of implementing microservices within a localhost. I don't see how the sidecar pattern offers a solution to some of microservices' cons. Can you please help me clarify this?
Much love to you Hussein.
Andres Castillo hey Andres! Thanks for your comment and excellent question. Checkout the video I made on sidecar patterns. ua-cam.com/video/zcJWvhzkPsw/v-deo.html
It helps elevate the complexity of communication to another layer
The Pros & Cons are always debatable. someone may argue that the design of a complex system as loosely coupled microservice will enhance the maintenance of the system and thus improve the debug process.
You might be right but not without a lot of tools (such as data dog or service mesh) to trace requests between services which obviously are pricy
Isn’t it still possible to use various databases with a monolith?
Thanks so much for this video.
It's also hard to make joint queries among the 3 databases
Hussain, Can microservice have one DB?
What about if one microservice has a dependency of another if there are different DB?
Like if comments service has a dependency of users services.
Does they make a network call to that services or they directly connect the users DB in comments services?
great video man. do you have a video about containers explanation doing it the sameway you did here? i loved the video by the way.
Thanks Pule! Yes I do have this video explaining the evolution of containers ua-cam.com/video/8qU3hZOXlBE/v-deo.html and also I have a playlist called Docker with all my docker videos check it out ua-cam.com/play/PLQnljOFTspQWsD-rakNw1C20c1JI8UR1r.html
Enjoy
Thanks for this amazing video
Could you make a video to implement a mini microservice system with container, reverse proxy etc. to solve a real problem?
I actually did here Check it out! Step by Step Basic Microservices System (3 NodeJS + 1 Load Balancer containers) with Docker ua-cam.com/video/9sAg7RooEDc/v-deo.html
@@hnasrBTW, what is the tool you use to zoom? Is there an alternative on Windows? I tried ZoomIt, but the quality is not asgood
Great explanations !
I finally understand, thank you!
Thanks Jack! Glad the video could help! Cheers
NICE
fabulous explanation!!
great
super clear crisp presentation !!
Sreeni Kand glad you liked it! thank you for watching
Just wow.. Thanks man!
Amazing content! You got a new sub
Thanks very much bro!
is it an anti design to run all microsercies in the same server like EC2, but each running is a different port ?
Perfect content, tnx man
really great video i understood everything, but if i have some relations in the database how can i do it and im using different databases
hows that different from having multiple databases and multiple controllers for the url end points that can requests from those DBs? you can integrate postgresql and mongodb etc in one app or even multiple apps/servers and scale the dbs if needed. I dont understand whats the deal here
The example shown in this video is a kind of simplification to help to understand the concept at a general level. At this level of abstraction, you can find other alternatives like the one you have mentioned.
In my opinon, the key point of Microservice is to achieve "extreme" horizontal scalability. In these kinds of scenarios, you will need to deploy the application on many servers (hundreds?). Even the term application needs to be redefined because each functionality/component has its own scalability needs. Therefore the application must be thought as a group of independent pieces of software (services). If your architecture is based on independent pieces, you also could have many development teams working in isolation and building new software very fast (working force scalability).
At this point, "real" microservices architecture comes to solve these escalability requeriments. I said "real" because there are just plenty of "distributed monolothics" that are called "microservices" just because....you know.
I am viewing now 2023, does anything have been updated or I can still continue to learn for now as well
How is referential data managed between micro-services? Tweets and InstaGram are relatively simple data-structures, what about ERP / CRM / financial systems? Are there examples of this done well?
Simon Roberts great question! Personally I did not see an ERP solution gone microservices yet. And no surprise there because as you said ERP is complex and as I explained in the “cons” section of the video Microservices are hard to implement. Its interesting, most ERPs are inherently designed to be a monolithic software with single relational database instance with extreme referential integrity and normalized structure. so breaking that down to CRM/ Asset management/ human resources /accounting microservices (with each of those potentially being more microservices each has its own database) is challenging. But as I think more about it, it is more natural for ERP to be microservices since each piece is kinda its own with some dependencies on other systems. I can imagine a CRM microservices with its own resources and database and the Accounting microservices with its own databases, then both talk through an API. If implemented correctly this could scale nicely. Again its very hard it is require complete redesign to break the referential integrity. Thanks for the question..
May be put also in the message queue playlist?
Sir, clean architecture different from this?
Big up
"Hash ta ta paaaay" lol
Great channel, and great content. One feedback I would like to make is that to me(just me) your english gets in the way of understanding, sometimes it's annoying. It would have been a lot better if you stick to the american accent with no arab-like pronunciation.
Again, thanks for your work here. It's great
People say he's better than college professors. anyway 08:52 LOL
subs ++
When a weed lover knows how to teach 😂
Hach TA TA PE
You are lacking the "UA-cam attention"! Nothing else.
Omar Faruk thank you so much for your comment. The facts that you guys enjoy the content is everything.
When a weed lover knows how to teach 😂