4 ms·
That architecture is commonly known as a distributed monolith. If you put two services on the same DB you can guarantee that someone will be joining onto a tabl
by VBprogrammer 8y ago
That architecture is commonly known as a distributed monolith. If you put two services on the same DB you can guarantee that someone will be joining onto a table they shouldn't have before the week is out.
- ljw1001 8y agoThis is another way of saying that micro-services are for easy problems, where you can avoid having many processes share the same complex database.
- wsy 8y agoIt's exactly the other way around: If you can afford all your components sharing the same database without creating a big dependency hell, then your problem is _too small_ for microservices. If your problem is so large that you have to split it up to manage its complexity, start considering microservices (it might still not be the right option for you).
- ljw1001 8y agolike all those simple airline reservation and banking systems?
- wsy 8y agoYes, they do fine as examples. I have worked both on decades old booking systems and banking software. Both were dependency hells. Refactoring was impossible. Everybody was super-careful even with tiny changes because the risk to break something was just too high. If it could be avoided, these systems were not touched anymore. Instead, other applications where attached to the front and sides.
- collyw 8y agoIsn't that a feature of old systems in general?
- wsy 8y agoI don't think so. For example, the Linux kernel is old, but still quite well maintainable. So I would say: it applies to systems where proper modularization was neglected. In the anecdotical cases I referred to, one major element of this deficiency was a complex database, shared across the whole system.
- WJW 8y agoNot to mention the endless fun that can be had when one service changes the database schema without telling the others!