11–20 of 51 posts
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 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.
Scaling and load balancing.
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 blocking a core and waiting until Service B completes. That's effectively doubling resource consumption during that call. You have one server waiting on another server to do work it could have done itself.
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 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 they wanted their own deploy timelines.
Essentially you have:
Modules = Microservices
Wrapper = Terraform/Helm Charts
And practically they work the same way.
This is another thing that used to make sense but no longer does. Back in the day we had pets and not cattle. You couldn't just roll someone's servers and expect everything to be fine. But today we write stateless cattle that can be killed at any moment.
This is the hardest bit, where if the monolith is relying on a shared db transaction between the client and service the network boundary makes them separate. Even without explicit rollbacks, at any high scale/load there can be timeouts/failures leaving an inconsistent data state.
The article suggests migrating a less critical client first, then developing such consistency mechanisms before migrating the more critical clients.
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 they wanted their own deploy timelines.
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.
> 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
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.
The end of the article covers why they felt complete isolation was worth the network costs. Maybe this true for their organization.
From working on one of the largest ruby code base for the last 5+ years, I see the massive benefits of isolation without introducing the http barrier. Yes, service isolation can let you ship faster. In practice, the network barrier will make some kinds of rollbacks easier and other far more difficult.
The reliably of the whole system is a lot more costly with the added network failure modes.
Over time, the proliferation of services impose an ever growing maintenance tax to keep libraries up to date and mitigate security vulnerabilities across an organization.
Tl;dr there are no free lunches.
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
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.
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.
If your concern is code health, a compile-time dependency works great.
If your concern is resource management, then you need a runtime dependency.