3 ms·

> The only reason I see for breaking the app this way would be to enforce low coupling. Which is a big deal... Microservices enable easier code re-use and div

> The only reason I see for breaking the app this way would be to enforce low coupling. Which is a big deal... Microservices enable easier code re-use and division of labor across teams, especially when persistent data is involved. It is a technical solution to a people/economic problem and not the other way around. At a high level, I think of all the popular APIs powering the web (Stripe, Google Analytics, Twilio, Intercom, etc.) and how they enable developers to do their work more efficiently. "Buy vs build" was mentioned as a promising attack on accidental complexity in "No Silver Bullet". If you design your microservices in a way that they're usable in different contexts and don't build at all when a paid or open source solution is available, you will boost your productivity.

fatherlinnux 11y ago
This is again, getting to the right answer for the wrong reason. You could keep these code bases separate whether they run in the same JVM in one container or in separate JVMs in different containers. As long as you enforce communication over something like REST, you will never have a problem. In fact, the application was already written this way and it was never enforced. This makes no sense to enforce if it wasn't already broken.