4 ms·
> (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has
by m_mueller 3y ago
> (because it's easier to change things, it's just single pr addressing all places at once) and then, possibly few years later, whatever has crystalized and has clear boundaries with little to no changes coming in or changes contained within this boundary - can be potentially extracted.
From my experience you get the best of both worlds by having a mono-repo but try to keep your services small-ish. E.g. for a reporting framework we have separate services for source data extraction, one for view transformations and one for exports. We can always recombine that (and we do actually integrate it locally in a single process for dev/debugging purposes), but it does enforce some good practices in keeping the boundaries clean IMO.
Note that I wasn't arguing at all to just go blindly all-in on Microservices, I was just saying there is some merit and YMMV.
- mirekrusin 3y agoYes, we do it as well - we have local monolith workspace package that combines all services and simulators in single node process. We don't use it on any environments, just for local development and ci. It works very well (very fast, very little resources and with simulators for external services you can work even on a plane without internet if you want and system behaves very much like real one in production). And yes, non-microservices doesn't imply monolith. We have many services. But they're not microservices because they don't have their own data store and distinct versioning/deployment - they're part of monorepo.