7 ms·
Decoupling a core service from your monolith the right way
- besus 3y agoA very pragmatic use of SOA / microservice.
- neonate 3y agohttps://archive.ph/2fWeS https://archive.ph/2fWeS
- R3ll1K7 3y agoI work with a large monolith, and we have been trying to decouple some of out core features for the past couple of years. The one lesson I learnt is that you have to start by making sure new features are not built on your legacy app. Feature flags is also a must.
- victor106 3y agoWhy do people still use Medium?
- revskill 3y agoBecause Large is expensive, and Small is limited ?
- mteam88 3y agoMy blog is hosted on GitHub pages on astro[1]. I'm considering mirroring to Medium and Substack to get more SEO. In the spirit of POSSE: https://indieweb.org/POSSE https://indieweb.org/POSSE [1] https://mteam88.github.io/ https://mteam88.github.io/
- treis 3y agoI 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.
- golemotron 3y agoScaling and load balancing.
- Berone 3y agoFrom a business perspective, unlocking this precision for infrastructure is only worth the investment at the highest levels of scale.
- treis 3y agoThis 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 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.
- zrail 3y agoRuby threads suspend on IO so a blocking HTTP request is very low cost.
- rco8786 3y agoI don’t think most modern Rails deployments have this problem anymore. Puma does pretty well with parallelization
- treis 3y agoYeah, and with Fibers things are getting even easier to do. But there are other performance issues and ultimately the benefits are minor.
- Tyr42 3y agoI think they wanted their own deploy timelines.
- karmakaze 3y ago> If a rollback were needed, some features would have to be implemented in both the monolith and Billy. This was time-consuming, so moving fast to remove that code from the monolith and rely 100% on Billy was essential. 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.
- brundolf 3y ago> 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"
- liampulles 3y agoThis 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.
- tra3 3y agoI 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?
- liampulles 3y agoI 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.
- 3y ago
- gitgud 3y agoThe 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…
- klysm 3y agoGrug don’t understand why take decoupling and add network call