HTTP APIs don't magically remove Coupling (Part 2)
Вставка
- Опубліковано 29 тра 2024
- What used to be a method call in-process turned into an HTTP call over the network. You have the same amount of coupling. Possibly worse off because you've now introduced the network. All for the need to deploy independently. Did you really have that need?
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Наука та технологія
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.
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.
Thanks for the video
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
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
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
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.