4 ms·
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other
by fluoridation 2y ago
Same-process modularization should solve that problem. Splitting the architecture into separate processes means a crash in one module doesn't propagate to other modules, but the whole system still breaks down if the process is essential.
- jamalaramala 2y agoNot all bugs are crashes. It could be a copy text or price calculation.
- thfuran 2y agoA system can break without crashing. Incorrectly processing financial transactions due to a bug in price calculations would be a good example of a serious breakage that may well be worse than crashing.
- fluoridation 2y agoFor bugs that don't cause crashes the effect is the same regardless of how you architect the system.
- zbobet2012 2y agoWhat same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours. Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.
- SideburnsOfDoom 2y agoYes. With the microservice as the unit of deployment, the design is about team structure as much as it is anything else. The team of 4-12 people owns and deploys a service at their own pace, without needing to be part of a larger and slower batch. If you're interested in iterative development and continuous deployment, which of course I am, it is a natural fit. It is productive in that case.