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

31–40 of 51 posts

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

#31

Post by treis »

rco8786 wrote: post #27
treis wrote: post #12

Earlier quoted context omitted.

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

Yeah, and with Fibers things are getting even easier to do. But there are other performance issues and ultimately the benefits are minor.

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

#32

Post by marcosdumay »

__MatrixMan__ wrote: post #26
marcosdumay wrote: post #19

Earlier quoted context omitted.

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…

So, I have to disagree again.

Your language's module system is boring. An specialized web server is about as close to the opposite as a corporate structure will allow.

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

#33

Post by [deleted] »

__MatrixMan__ wrote: post #26
marcosdumay wrote: post #19

Earlier quoted context omitted.

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…

[deleted]

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

#34

Post by Groxx »

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.

One of HTTP's biggest strengths here are that it's essentially perfectly language-agnostic (in practice, not just theory) and it lets you solve basically all networking problems (hardware and software) in normal, off-the-shelf, trivial-through-Google-scale ways without having to change it. And if you want to build something custom, there are more experts and documentation and examples than any other system.

I agree it's suboptimal for performance. But it absolutely cannot be beat for business stability and flexibility. And your IPC costs generally do not dominate your request times anyway.

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

#35

Post by marcosdumay »

wtyyasdf wrote: post #23
treis wrote: post #14

Earlier quoted context omitted.

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

You need governance of the client choosing a specific version of the service too.

Or, in other words, you can't have teams cooperating without governance.

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

#36

Post by marcyb5st »

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 that while the approach is good, there was a better option (IMHO). Specifically, I would:

1. Create protobuffers (or similar) messages that wrap the requests and responses. E.g. CheckSubscriptionPaidRequest and CheckSubscriptionPaidResponse.

2. Refactor your code so that the fields in the messages defined in #1 are your only mean to pass/retrieve information.

3. If need be, expose the service through GRPC or similar.

4. Repeat for each service/endpoint.

This way, you don't incur in any overhead apart from the negligible creation of the protobuffer messages instances.

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

#37

Post by adra »

rco8786 wrote: post #22
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

When you're releasing changes daily, a dozen groups are all touching the same code, and all of a sudden one of those ten changes kill the application with OOMs galore, your ops people are going to have a bad day. Oh some minor component written by a newer dev added a non-reversible DB migration in that same push? You're having a very bad day(s). Microservices are not the panacea that will work for all organizations/products/workflows, but damn do they do amazing things for others. Running a platform with dozens of teams with loose organization, distributed timezones, conflicting priorities abound, it's nice to not worry about other teams poofing our perfectly happy chunk of the company from doing it's thing.

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

#38

Post by sroussey »

adra wrote: post #37
rco8786 wrote: post #22

Earlier quoted context omitted.

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

When you're releasing changes daily, a dozen groups are all touching the same code, and all of a sudden one of those ten changes kill the application with OOMs galore, your ops people are going to have a bad day. Oh some minor component written by a newer dev added a non-reversible DB migration in that same push? You're having a very bad day(s). Microservices are not the panacea that will work for all organizations/p…

Yes, but these services need not be “micro”.

If someone twist my arm and off and convinces me to do some consulting, I’ve seen thousands of services started by individual developers, where there is no accounting, so the ops people don’t know what needs to be kept up or what can be shut down.

Definitely separate regulatory differences (marketing vs credit card processing for example). Generally, separate out high velocity code changes from slow velocity code if possible.

I wouldn’t get in the habit of database migrations having anything to do with code pushes. Unless you have no users, I guess. Yikes. So much to say on that topic alone.

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

#39

Post by treis »

adra wrote: post #37
rco8786 wrote: post #22

Earlier quoted context omitted.

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

When you're releasing changes daily, a dozen groups are all touching the same code, and all of a sudden one of those ten changes kill the application with OOMs galore, your ops people are going to have a bad day. Oh some minor component written by a newer dev added a non-reversible DB migration in that same push? You're having a very bad day(s). Microservices are not the panacea that will work for all organizations/p…

I do agree that at some point it breaks down. But dozens of teams probably should be split for organizational reasons anyways so splitting up tech isn't much more overhead.

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

#40

Post by AtNightWeCode »

myvoiceismypass wrote: post #13
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.

In theory, separate teams can manage separate deployment schedules, etc more closely aligned with their feature work.

In theory, you mean if there were like separation of concerns. Like the billing address being in the billing service instead of the customer service?
Post reply on HN