Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decoupling a core service from your monolith the right way

betterprogramming.pub

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Decoupling a core service from your monolith the right way

#21

Post by zug_zug »

treis wrote: post #6

I don't understand why people choose to put an HTTP barrier in their code. It would have been much better if they had stopped at a Billing module. They get all the code factoring benefits they seek without the performance and operational overhead of an additional service.

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.

Re: Decoupling a core service from your monolith the right way

#22

Post by rco8786 »

treis wrote: post #6

I don't understand why people choose to put an HTTP barrier in their code. It would have been much better if they had stopped at a Billing module. They get all the code factoring benefits they seek without the performance and operational overhead of an additional service.

Yes! I call them “modular monoliths” and fight tooth and nail to get people to stop introducing network when it doesn’t need to be there.

I want to make people do Bart Simpson style writing on the chalkboard “Microservices don’t make things easier” 200 times

Re: Decoupling a core service from your monolith the right way

#23

Post by wtyyasdf »

treis wrote: post #14
Tyr42 wrote: post #11

Earlier quoted context omitted.

I think they wanted their own deploy timelines.

In practice there's not much difference if you use a wrapper application. The wrapper application sets the version of modules and provides whatever glue they need. For Rails that would be gems in the Gemfile and mounted engines. To deploy a new version of your module you bump the version in the Gemfile and roll the nodes. Essentially you have: Modules = Microservices Wrapper = Terraform/Helm Charts And practically th…

This seems to side step governance of the repository pulling said module version

Re: Decoupling a core service from your monolith the right way

#24

Post by zrail »

treis wrote: post #12
golemotron wrote: post #9

Earlier quoted context omitted.

Scaling and load balancing.

This is one of those things that was true in like 2008 but is no longer true in 2023. Scaling a monolith is slightly more expensive in memory consumption but in practice it's irrelevant for most cases. In this particular case it's worse due to how Rails works. Usually people deploy one Rails thread per core and that core is blocked by the thread. If that's the case when Service A calls Service B, Service A is blockin…

Ruby threads suspend on IO so a blocking HTTP request is very low cost.

Re: Decoupling a core service from your monolith the right way

#25

Post by wtyyasdf »

zug_zug wrote: post #21
treis wrote: post #6

I don't understand why people choose to put an HTTP barrier in their code. It would have been much better if they had stopped at a Billing module. They get all the code factoring benefits they seek without the performance and operational overhead of an additional service.

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 htt…

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

Re: Decoupling a core service from your monolith the right way

#26

Post by __MatrixMan__ »

marcosdumay wrote: post #19
__MatrixMan__ wrote: post #17

Earlier quoted context omitted.

It's because the code smells bad and they're having a hard time getting motivated to clean it up piece by piece because even when their piece is clean they'll still have to deal with the smell of the adjacent pieces. Http lets you say: > That dumpster fire over there is not my problem Without having to say: > I want to rewrite the whole thing from scratch, you'll have to deal with it being down for a few months

Again, you don't need HTTP for that either. The GP's proposal achieves exactly the same thing. IPC (networks, FIFO, pipes or whatever) decoupled services solve problems more on the ops side, from binary compatibility to resource segregation. They do very little on the dev side.

Of course you don't need it technologically speaking. Between DNS and SSL and stuff like openAPI, HTTP comes with a lot of baggage that is redundant when used on the back end.

My point is that it's not a technology problem in the first place. It's a problem of clashing senses of style and taste. It's a culture problem. If you need to dress up your culture problem fix with a technology explanation, http is the way to go because it's widely understood and so boring that nobody is going to ask you to explain it in too great of detail.

Re: Decoupling a core service from your monolith the right way

#27

Post by rco8786 »

treis wrote: post #12
golemotron wrote: post #9

Earlier quoted context omitted.

Scaling and load balancing.

This is one of those things that was true in like 2008 but is no longer true in 2023. Scaling a monolith is slightly more expensive in memory consumption but in practice it's irrelevant for most cases. In this particular case it's worse due to how Rails works. Usually people deploy one Rails thread per core and that core is blocked by the thread. If that's the case when Service A calls Service B, Service A is blockin…

I don’t think most modern Rails deployments have this problem anymore. Puma does pretty well with parallelization

Re: Decoupling a core service from your monolith the right way

#28

Post by rco8786 »

wtyyasdf wrote: post #25
zug_zug wrote: post #21

Earlier quoted context omitted.

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 htt…

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

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.

Re: Decoupling a core service from your monolith the right way

#29

Post by brundolf »

> and since everything lived in the same monolithic, the billing codebase was coupled with other core modules like transfers and authorization

This doesn't follow, but everyone always seems to think that it does. They even demonstrate that it doesn't in Phase 1! "Decouple billing logic within the monolith"

Re: Decoupling a core service from your monolith the right way

#30

Post by Scubabear68 »

wtyyasdf wrote: post #25
zug_zug wrote: post #21

Earlier quoted context omitted.

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 htt…

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

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.

Post reply on HN