You know what else is rarely mentioned explicitly in debates on monolith Vs micro services? Human side of it. For a 1-5 ppl project having microservices bring a lot of overhead. When you get 10ppl working on each "microservice" each with it's own roadmap and release cadence - having that decoupling is worth the overhead. I guess one's perspective on the question is mainly based on the scale of service one has experience with.
Every architecture decision proffers both capabilities and constraints. This extends through define, design, development, deploy, and manage [which includes scale, cost, security, governance, observability,..]. A couple of critical factors, it can't cost too much, and it needs to get data transformed and delivered into consumable information in a timely manner. Oh, make sure the data is safe, recoverable, and CORRECT. The technical details we can and will spend endless hours discussing, just don't mess up what we're paid to provide.
One type of coupling has decreased. You're now able to serve the endpoint using a different language/framework. I think this is almost never used though
I believe microservices is a step forward in computer solutions. It's true it comes with increased complexity but once you get a hang of it it delivers great power.
I don't see any benefits of the microservices trend, which wasn't there in SOA. This 'micro-' prefix brings attention to making them as small as possible, which has little benefit over splitting system into modular services which represent bounded contexts, even if they're not small There was a communication style change though. Instead of some service buses, microservices tend to communicate directly and use infrastructure only to find each other. But I'm not sure if this count as part of microservices trend or maybe rather REST
I like the form of the talk, but I'm not entirely convinced to slicing it in parts and posting one by one. You can easily get only to particular part without the context. And if you watch it right after publishing - you're already out of context when new arrives At least please put it in one playlist
my advice: you guys are all over the place, please stay concise and focused on an agenda, hard to follow your videos usually, and not because I am not technically minded, but you are attacking technical topics with a weird and hard to follow approach, feels like a Tom Sawyer story rather than science
it's completely the other way around. It's all about coupling and you can scale endpoints/features independently with both monolith and microservices architectures
@@piotrkowalski3460 scaling a monolith is hard and can lead to outages (bugs/deployments, etc). This was born as a solution to scale systems not to decouple for fun or ease of development or maintenance.
I think the biggest lesson we learned from microservices is about coupling and cohesion and now we are back to monoliths with that knowledge.
You know what else is rarely mentioned explicitly in debates on monolith Vs micro services? Human side of it.
For a 1-5 ppl project having microservices bring a lot of overhead.
When you get 10ppl working on each "microservice" each with it's own roadmap and release cadence - having that decoupling is worth the overhead. I guess one's perspective on the question is mainly based on the scale of service one has experience with.
Every architecture decision proffers both capabilities and constraints. This extends through define, design, development, deploy, and manage [which includes scale, cost, security, governance, observability,..]. A couple of critical factors, it can't cost too much, and it needs to get data transformed and delivered into consumable information in a timely manner. Oh, make sure the data is safe, recoverable, and CORRECT. The technical details we can and will spend endless hours discussing, just don't mess up what we're paid to provide.
One type of coupling has decreased. You're now able to serve the endpoint using a different language/framework. I think this is almost never used though
we use it heavily with georeferenced image data processing since .NET is terrible when it comes to that, compared to python.
"HTTP APIs don't magically remove Coupling" Do queues next!
I'm about to, as well as events! Thanks for the suggestion.
I believe microservices is a step forward in computer solutions. It's true it comes with increased complexity but once you get a hang of it it delivers great power.
I don't see any benefits of the microservices trend, which wasn't there in SOA. This 'micro-' prefix brings attention to making them as small as possible, which has little benefit over splitting system into modular services which represent bounded contexts, even if they're not small
There was a communication style change though. Instead of some service buses, microservices tend to communicate directly and use infrastructure only to find each other. But I'm not sure if this count as part of microservices trend or maybe rather REST
Thanks for the video
I like the form of the talk, but I'm not entirely convinced to slicing it in parts and posting one by one. You can easily get only to particular part without the context. And if you watch it right after publishing - you're already out of context when new arrives
At least please put it in one playlist
my advice: you guys are all over the place, please stay concise and focused on an agenda, hard to follow your videos usually, and not because I am not technically minded, but you are attacking technical topics with a weird and hard to follow approach, feels like a Tom Sawyer story rather than science
Curious, did you watch part 1? I'm wondering if it feels disjointed because it's a 45 min conversation and this is the middle of it
@@CodeOpinion Thanks , I will take a look at that one as well. Thanks for the reply
The video format is great. Two heads are better than one.
Thanks for the comment. I'll try and do more of these in the future if I can.
it's not about coupling. It's more about ability to scale endpoints/features independently.
it's completely the other way around. It's all about coupling and you can scale endpoints/features independently with both monolith and microservices architectures
@@piotrkowalski3460 scaling a monolith is hard and can lead to outages (bugs/deployments, etc). This was born as a solution to scale systems not to decouple for fun or ease of development or maintenance.
Ability to scale independently is one of advantages of decoupling - infrastructure coupling to be more precise