4 ms·
But where does the difference come from? A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in
by ProblemFactory 10y ago
But where does the difference come from?
A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in-process function calls instead of remote API calls.
If you do large-scale integration tests that cross module boundaries in the monolith, then you should also have the same tests of the full deployment with microservices. If you test each microservice independently, then you could also run tests for each module independently.
- sokoloff 10y agoMy experience (sample size of 1) is that long-lived monoliths tend not to evolve along "well-designed" lines, but rather along "what can I possibly do to get this to work in the time I have?" lines. Further, it's an impossible hurdle to schedule big dig to make substantial architectural improvements on a large monolith, so refactorings and improvements tend to be shallow and localized. A decade later, and you have a lot of business logic in stored procedures in your database and now hear grumbling from coders who don't know or don't want to learn SQL. (And, to be fair, it does make it harder to scale the engineering team if everyone needs to be proficient at SQL.) Neither availability nor technical scaling concerns were the reason we started to transition away from our monolith. We were regularly hitting 4 nines of availability (measured by "orders coming in") and had scaled to well over $1BB in revenue essentially on a single database for most of the site functionality. Above average engineers and ops, and way above average DBA team was key to making that happen.