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

41–50 of 51 posts

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

#41

Post by rco8786 »

treis wrote: post #39
adra wrote: post #37

Earlier quoted context omitted.

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.

> splitting up tech isn't much more overhead.

This is the fallacy. Splitting up tech has huge overhead.

There’s lots of good reasons to do it. But “operational efficiency” is not one of them, even though it’s oft cited as one.

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

#42

Post by rco8786 »

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…

There are plenty of genuinely good reasons to split up monoliths. I’m not attempting to say that all SOA is bad.

What I am saying is that companies who break apart monoliths as a code organization tool are making a very bad decision. They’re getting all the downsides and none of the upsides of microservices.

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

#43

Post by brundolf »

__MatrixMan__ wrote: post #17
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.

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

Yeah, I think this is the realistic answer. Technical solution to a social problem etc

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

#44

Post by liampulles »

This is building a SOA distributed monolith, which is kind of cutting off your nose to spite your face. I've been there - would not recommend.

It makes the system brittle, slow, and forces strong commitments that dependent services remain up (rolling releases with non breaking migrations, etc).

If I were to do it again, then I would first ensure that the infrastructure is there for inter-service communication to be done asynchronously, and that changes are eventually consistent. Maybe using a workflow manager like Camunda or Temporal. Or even just event choreography between services - either of those is better than a synchronous HTTP call chain of what will become 7 dependent services.

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

#45

Post by tra3 »

liampulles wrote: post #44

This is building a SOA distributed monolith, which is kind of cutting off your nose to spite your face. I've been there - would not recommend. It makes the system brittle, slow, and forces strong commitments that dependent services remain up (rolling releases with non breaking migrations, etc). If I were to do it again, then I would first ensure that the infrastructure is there for inter-service communication to be d…

I agree that asynchrony would be a stronger technical solution, but it’s not the defining characteristic of SOA. They author mentions circuit breakers so seems like they did think about network resiliency.

Other then async what would make it less of a “distributed monolith”, can you say?

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

#46

Post by gitgud »

The article suggests using gitsubmodules, which I wouldn’t recommend.

Mainly because depending on another repo can be flakey. If you depend on another repo’s tag i.e. “submodule@v1.3” that tag commit could be changed, which could break the build.

If you depend on another repo’s commit hash i.e. “submodule@hash” then you depend on nobody rebasing or “git push -f” which could remove that hash from the git history.

All these problems disappear if you use a mono-repo, rather than a git submodule…

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

#48

Post by liampulles »

tra3 wrote: post #45
liampulles wrote: post #44

This is building a SOA distributed monolith, which is kind of cutting off your nose to spite your face. I've been there - would not recommend. It makes the system brittle, slow, and forces strong commitments that dependent services remain up (rolling releases with non breaking migrations, etc). If I were to do it again, then I would first ensure that the infrastructure is there for inter-service communication to be d…

I agree that asynchrony would be a stronger technical solution, but it’s not the defining characteristic of SOA. They author mentions circuit breakers so seems like they did think about network resiliency. Other then async what would make it less of a “distributed monolith”, can you say?

I am using SOA out of place and I should not have included it in my comment - I agree.

I guess distributed monolith is a nebulous term, and I'm sure people have their own criteria. To me, the defining characteristic IS the size of that synchronous call chain. If to serve some of the public operations of your system you need to make a synchronous HTTP call that spans more than one service, then I consider those services to be too tightly coupled and the system is closer to being a distributed monolith then a set of independent services (I'd make an exception if the first service is an API gateway or is very explicitly a kind of middleware service, and not defining business logic).

The degree to which the system is a distributed monolith, and how much one should care about that fact or invest effort to steer away from it is a function of how big the biggest one of those call chains is. I don't have a binary definition, more of a sliding scale. The way to avoid sliding more into the direction of a distributed monolith (at least the way I reckon it) is to avoid making those call chains from the get go.

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

#49

Post by jupp0r »

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.

You have to draw the line somewhere, or Chrome would have to ship with the whole WWW.

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

#50

Post by tra3 »

liampulles wrote: post #48
tra3 wrote: post #45

Earlier quoted context omitted.

I agree that asynchrony would be a stronger technical solution, but it’s not the defining characteristic of SOA. They author mentions circuit breakers so seems like they did think about network resiliency. Other then async what would make it less of a “distributed monolith”, can you say?

I am using SOA out of place and I should not have included it in my comment - I agree. I guess distributed monolith is a nebulous term, and I'm sure people have their own criteria. To me, the defining characteristic IS the size of that synchronous call chain. If to serve some of the public operations of your system you need to make a synchronous HTTP call that spans more than one service, then I consider those servic…

Thanks @liampulles, appreciate your insight. Going through the same exercise you've helped me crystallize my thoughts.
Post reply on HN