Hacker News Reader

Comment by fluoridation | Hacker News Reader

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.

View on HN

What 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.

Yes. 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.

Not all bugs are crashes. It could be a copy text or price calculation.

A 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.

For bugs that don't cause crashes the effect is the same regardless of how you architect the system.

Reply on news.ycombinator.com