Discussion
Loading...
@purinkle the real problems with a monolith are:
- the size of the codebase (I have no idea how this works) - not a problem now, because of LLMs
- I need to change the database; test the migration; run it in production … it takes 40 minutes, then oh shit, some weird anomaly in the live data means I’ve just deleted 70m rows - you get this with small, interconnected apps too, but the blast radius is smaller
@rahoulb, fair points. The codebase size point is interesting. The problem is often less about the monolith and more about how well we organise the code. Bounded contexts inside the monolith help a lot there, even before LLMs.
The migration risk is real, though. It is more about deployment practices than architecture. Blue-green, feature flags, and smaller batches can help. You are right that the blast radius is different when it is all one app.
@katafrakt, that is true. I always run the whole suite, too. The discipline is keeping it fast enough that you do not mind. Ten minutes is my ceiling. If it creeps past that, it is a sign that something needs attention. That might be test design, parallelisation, or trimming unnecessary coverage. But that is work you have to do regardless of architecture.
@purinkle this is another problem with monoliths that gets rarely mentioned in my opinion. You may be super disciplined with your team about fast and reliably tests. But then there's another team that does not care (that much), they write slow and flaky tests - and you suffer as a result.
I've been there many times.
@katafrakt, yes, that is the pain that is hard to architect away. I have been reading Aaron Dignan’s Brave New Work lately. It frames this as a breakdown in working agreements between teams. It is not a technical boundary problem. Eileen Uchitelle’s “Myth of the Modular Monolith” makes a similar point. Architecture cannot fix human issues, but fixing human problems improves architecture.
@katafrakt, yes, that is the pain that is hard to architect away. I have been reading Aaron Dignan’s Brave New Work lately. It frames this as a breakdown in working agreements between teams. It is not a technical boundary problem. Eileen Uchitelle’s “Myth of the Modular Monolith” makes a similar point. Architecture cannot fix human issues, but fixing human problems improves architecture.
2 more replies (not shown)