News for hackers. Stuff that matters.
Re:Decoupling a core service from your monolith the right way by Tyr42 on Sunday June 04, 2023 @09:53AM (#36185624)
I think they wanted their own deploy timelines.
Re:Decoupling a core service from your monolith the right way by treis on Sunday June 04, 2023 @10:21AM (#36185801)
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 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.

Re:Decoupling a core service from your monolith the right way by wtyyasdf on Sunday June 04, 2023 @12:00PM (#36186633)
This seems to side step governance of the repository pulling said module version
Re:Decoupling a core service from your monolith the right way by marcosdumay on Sunday June 04, 2023 @01:14PM (#36187376)
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 by przemo_li on Tuesday June 06, 2023 @05:49AM (#36210395)
If you allow at most 2 versions and expect team introducing change to rewrite all code...

At small size of code, tooling for that may be off-the-shelf for monolith.

Are there any rewrite told that work cross repos though?