Decoupling a core service from your monolith the right way

Re:Decoupling a core service from your monolith the right way by zug_zug on Sunday June 04, 2023 @11:24AM (#36186336)

I think it's a branding thing. Basically the cargo cult (which copies what's new/hype/difficult) latched on it. Most of these hype things die in a few years with no lasting legacy or resume value though (mongo, serverless, et al).

Someday hopefully some genius proposes "hyper-sidecar-ification" where you take microservices and package them together in a sophisticated way to avoid the limitations and latency of an http barrier. As long as it's new & complicated & buzzwordy (even if it's just monorepo again) it can catch on.

[ Parent | on HN ]

Re:Decoupling a core service from your monolith the right way by wtyyasdf on Sunday June 04, 2023 @12:06PM (#36186692)

The latency is kind of a FUD with topology aware routing.

[ Parent | on HN ]

Re:Decoupling a core service from your monolith the right way by Scubabear68 on Sunday June 04, 2023 @12:27PM (#36186922)

It’s not FUD if you are making hundreds or thousands of calls. Many “chatty” apps slow down dramatically when the wrong network boundary is drawn in the code.

The difference between a function call and a network request is vast for even modern networks.

[ Parent | on HN ]

Re:Decoupling a core service from your monolith the right way by rco8786 on Sunday June 04, 2023 @12:18PM (#36186837)

This is true when you have 1 microservice. When you have dozens of them waterfalling requests through each other it starts adding up really fast.

[ Parent | on HN ]