Problem
At work, we are considering breaking up our very large monolith that's being maintained across several teams into separate microservices. The motivation is to reduce codebase size, give different teams more control over their release cycle, and give teams more freedom in terms of languages/frameworks/libraries used. We can reduce codebase size by refactoring to a well-designed modular monolith, but the use of traditional modules would require everyone to opt in to the same language and it also may not be possible to independently deploy modules. Microservices would solve these issues, but they would also introduce unnecessary complexities, increase hosting costs, and negatively impact latency.
Proposed Solution
We can develop the modules as standalone applications similar to how things would work with microservices. However, all modules would deploy to the same host and they would all communicate locally over some predefined protocol (gRPC is probably best here). This would allow us to take advantage of the shared infrastructure, and we would also avoid the latency penalty. In order to implement this architecture, there would need to be some on-host daemon service that orchestrates module deployments and handles failures. I think this is worth implementing though (I wonder if something similar exists already).
Has anyone encountered a similar situation? What may be some disadvantages of this architecture? Has anyone actually tried this?
Thank you
submitted by /u/sudoaptupdate
[link] [comments]
from Software Development – methodologies, techniques, and tools. Covering Agile, RUP, Waterfall + more! https://ift.tt/R7DGg4r