Thanks for your video! I was confused about the title. However, others have already pointed that out:) "Are you doing microservises when using containers/...?" - I guess this is what you want to say.
@@CodeOpinion It's a useful planning and communication tool. Make sure you aren't missing something in a project plan, make sure the engineers know what to build and how things fit together, communicate to the customer or management what they're paying for and why. It can also live on as documentation after project completion for support and troubleshooting so someone down the line has an idea where to start looking when there is an issue.
At 5:08 you gave an example of microservice A having a change that requires a corresponding change in microservice B. Won't the same problem exist regardless of HTTP or message broker communication? If my payload structure is changing in microservice A, it's either optional for microservice B, it's a breaking change (B has to change) or it's simply a new version of the API (B can change in the future as it sees fit).
Correct, same problem exists. How you handle versioning is going to exist no matter what. A more concrete example of the coupling that requires changes to many services to be deployed together is coupling by code or schema.
Thanks for linking me here. You've added some level of depth to what I've been thinking. I almost wanted to build the domain layer in one repo then pull the parts of the model into the different deployable units (repos) at the domain layer of each. Kind of treating the domain layer (logical view?) as a monolith, while implementing infrastructure and application layers as part of their physical view. Although, it's a shame, it seems like constrains can cause one to have a coupled logical and physical view, where physical constrains the logical.
I would say read the Domain Driven Design book (blue book). It's not about microservices or distributed systems per say, but I think it has a lot of foundational knowledge that is required before you even think about microservices.
You've made good points, but, to be honest, from the title of the video I was expecting you to talk about different options of deploying microservices(VM, containers), not how to structure logically your microservices. The name of the video is kind of misleading imo.
You dont NEED containerization. You also dont NEED visual studio/rider you can just use notepad. Sure containerization may seem like over kill if you have 3 or 4 services. but microservices can be hell if you are dealing with hundreds of services. containerization just cuts out a whole bunch of problems.
Thanks for your video! I was confused about the title. However, others have already pointed that out:)
"Are you doing microservises when using containers/...?" - I guess this is what you want to say.
Love seeing you bring in 4+1. That breakdown has been invaluable to me.
I plan on doing a video by itself on it at some point. What do you find most valuable from it?
@@CodeOpinion It's a useful planning and communication tool. Make sure you aren't missing something in a project plan, make sure the engineers know what to build and how things fit together, communicate to the customer or management what they're paying for and why. It can also live on as documentation after project completion for support and troubleshooting so someone down the line has an idea where to start looking when there is an issue.
Amazing. This is what I call a helpful video. Cheers
Great to hear!
Another great video, this 4+1 arch. diagram summarizes everything in a super powerful and simple way
Glad you liked it!
At 5:08 you gave an example of microservice A having a change that requires a corresponding change in microservice B. Won't the same problem exist regardless of HTTP or message broker communication?
If my payload structure is changing in microservice A, it's either optional for microservice B, it's a breaking change (B has to change) or it's simply a new version of the API (B can change in the future as it sees fit).
Correct, same problem exists. How you handle versioning is going to exist no matter what. A more concrete example of the coupling that requires changes to many services to be deployed together is coupling by code or schema.
Thanks for linking me here. You've added some level of depth to what I've been thinking. I almost wanted to build the domain layer in one repo then pull the parts of the model into the different deployable units (repos) at the domain layer of each. Kind of treating the domain layer (logical view?) as a monolith, while implementing infrastructure and application layers as part of their physical view. Although, it's a shame, it seems like constrains can cause one to have a coupled logical and physical view, where physical constrains the logical.
Agreed.
Nice video! By the way Derek, do you know why some of your vídeos does not have english subtitles?
Hmm I'm not sure, I'll have to look into why. RUclips creates then automatically, I don't do anything. I'll see if I can figure out why.
Hi, the subtitles of this video has some issues.
I don't create them. I believe RUclips automatically does. But I'll take a look to see if they can get fixed.
Thanks for creating qualified content, Derek. Is there a book about microservices and distributed systems which you would advise reading first?
I would say read the Domain Driven Design book (blue book). It's not about microservices or distributed systems per say, but I think it has a lot of foundational knowledge that is required before you even think about microservices.
@@CodeOpinion Thank you for your advice
You've made good points, but, to be honest, from the title of the video I was expecting you to talk about different options of deploying microservices(VM, containers), not how to structure logically your microservices. The name of the video is kind of misleading imo.
I can see how you could think that. I'll think about a different title possibly.
yagv - yet another great video :)
any plans on doing a video on the Distributed Application Runtime (Dapr)?
thanks!
Good suggestion!
Gold Found! Thank you for this information.
Hope it helps!
You dont NEED containerization. You also dont NEED visual studio/rider you can just use notepad. Sure containerization may seem like over kill if you have 3 or 4 services. but microservices can be hell if you are dealing with hundreds of services. containerization just cuts out a whole bunch of problems.
My main point I was trying to get across is it's about logical separation, not physical. Confusing the two can lead to the distributed monolith.
Gold Found! Thank you for this information.