4 ms·
OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separat
by jayd16 6y ago
OP just said they don't talk at all. They sound completely decoupled already. You could put them in the same app and share routes if you want and just separate by package or compilation unit if you really want to. The hard part is already done though.
They could be managed and deployed by completely different teams with no overhead now. It really depends what we're tuning for.
- neuronic 6y agoScaling is another factor that comes to mind, also resilience. If one part in the monolith goes haywire so will the entire application. If you can decouple and split the software into 4 applications with their own concerns, at least you have 3 applications left running (assuming they are decoupled). If app 1 wants 5000% more CPU than app 2, maybe you can have different instance types running and save costs/resources.
- systematical 6y agoA good reason no doubt and if that comes to bear sure. But at least code in a monorepo and split to microservices in your pipeline. Cake and eat.
- systematical 6y agoRead my reply further up, they have a lot in common. We had to build a shared library that goes in as a dependency and even with that we have to still copy/paste code between services. Because a data structure change in one must often be reflected in another HELLO multiple PRs for one task.