So I guess it depends on the workload - smaller demand - monolith. Honestly for me debugging is such an important part and if debugging a microservice is harder I say high availability is arguable. Thank you Narendra! I was looking for a web primer and your channel is fantastic.
Event driven design with messaging. The services persist data in a DB but they do that usually as a result of a notification by subscribing to events from other services. I think of it as shifting away from extensive table joins you would do in a monolithic approach to microservices querying alternatives like CQRS.
Notification is not a business domain, it is a common stable infrastructure, just like a db, doesn't change every often, hence, it does not need to be a microservice. It could be better modeled as a packaged module shared by all the microservices. Usually, each service or microservice has its app/api, domain, and infrastructure layers, and common infrastructure code is shared using packages by all services that need that piece of infrastructure. So, every module of a monolith doesn't map one to one to a microservice, infrastructure modules are not treated the same way as business/domain modules, like you don't have a db access service, or a api logging service, or a db logging service, these are built-in infrastructure modules/packages used across the system.
Regarding the point where each microservice can use a different kind of database... couldn't we just design a monolith service which connects to multiple DB's? So we get the same advantage regardless of if we choose a monolithic or microservice architecture.
Greetings @Kamal..well not really a option every scenario I wanna share an example here pls consider a scenario where service I's making data available Through course of logic apps keeping the atomicity and redundancy upfront Then yes this kind of service is way to go, so you need to be decisive beforehand the nature of what precisely your service achieving. .if its there to solve i/o king of work pls go ahead else You need to figure out other as options like in scenarios wherein some long running computations are involved
Usually, the answers to these problems are defined by the scale and problem at hand. Monoliths are not bad just they have problems beyond a scale and required characteristics. If you have to deliver something super fast and the team is not knowledgeable enough to do micros services then the project will be doomed. These kinds of problems appear when the product starts getting mature and consequently seams begin to crack open.
basically they are part of the same application. speaking of containers you can see the use of orchastrators and setting a dockermanifest file for multipule containers and volumes. they just acces different ports on your host.
This series of design videos are really really good, Narren! Big thank you. Really good videos
Does anybody know someone better that this guy ? . the number one explain it on youtube
The best explanation I have ever had.Keep doing this good work.
Take a bow Narendra. This is as good as the explanation of microservices can get.
The best explanation of microservices 👍
Very good explanation!!! Keep up the good work!
Really amazing!
Perfect case to apply domain driven design
So I guess it depends on the workload - smaller demand - monolith. Honestly for me debugging is such an important part and if debugging a microservice is harder I say high availability is arguable. Thank you Narendra! I was looking for a web primer and your channel is fantastic.
nice lovely superb
so good, thank you!
👍
I am not sure if all the services having separate DB will be good approach. What if we need a joint data from all these separate databases?
Event driven design with messaging. The services persist data in a DB but they do that usually as a result of a notification by subscribing to events from other services. I think of it as shifting away from extensive table joins you would do in a monolithic approach to microservices querying alternatives like CQRS.
Notification is not a business domain, it is a common stable infrastructure, just like a db, doesn't change every often, hence, it does not need to be a microservice. It could be better modeled as a packaged module shared by all the microservices. Usually, each service or microservice has its app/api, domain, and infrastructure layers, and common infrastructure code is shared using packages by all services that need that piece of infrastructure. So, every module of a monolith doesn't map one to one to a microservice, infrastructure modules are not treated the same way as business/domain modules, like you don't have a db access service, or a api logging service, or a db logging service, these are built-in infrastructure modules/packages used across the system.
That moment, when you come up with some cool idea for video special effect, but shooting and editing takes forever)
Narren thank u so much
Regarding the point where each microservice can use a different kind of database... couldn't we just design a monolith service which connects to multiple DB's? So we get the same advantage regardless of if we choose a monolithic or microservice architecture.
Greetings @Kamal..well not really a option every scenario I wanna share an example here pls consider a scenario where service I's making data available
Through course of logic apps keeping the atomicity and redundancy upfront
Then yes this kind of service is way to go, so you need to be decisive beforehand the nature of what precisely your service achieving. .if its there to solve i/o king of work pls go ahead else
You need to figure out other as options like in scenarios wherein some long running computations are involved
IMHO, Polyglot persistence would be difficult in monoliths.
Usually, the answers to these problems are defined by the scale and problem at hand. Monoliths are not bad just they have problems beyond a scale and required characteristics. If you have to deliver something super fast and the team is not knowledgeable enough to do micros services then the project will be doomed. These kinds of problems appear when the product starts getting mature and consequently seams begin to crack open.
rest is not a protocol. what you mean is http.
Way too good.i work on spring webflux with microservices
One doubt.
So are the microservices deployed on the same host(like using containers)? if yes , then will the API gateway be also present on that host?
basically they are part of the same application. speaking of containers you can see the use of orchastrators and setting a dockermanifest file for multipule containers and volumes. they just acces different ports on your host.