Comment by capableweb
6 years ago
> just means "monolith", and usually "unscaleable monolith"
Hm, monolith != unscaleable monolith. Monolith just means you'd have to do vertical scaling instead of horizontal scaling, which arguably is easier and less error prone, as you still are only dealing with one instance and not building a distributed system all of sudden.
I usually try to keep to vertical scaling for as long as possible, until either the performance starts to plateau or the product/project becomes big enough that it needs different backend dev teams working on different things concurrently.
I did not say "monolith" equaled "unscaleable monolith", I said that such a setup is usually an "unscaleable monolith".
Thee reason for this is that writing anything at all to be scalable is quite difficult, and larger monoliths tends to reflect a laziness and false sense of simplicity that tends to also be reflected by the internal design. For this reason, I'd consider "large but scalable monoliths" to be in the minority.
Furthermore, I'd argue that if scaling of a monolith isn't a problem, it's simply because its load is insignificant in the first place. Once the scaling game starts, vertical scaling quickly ends up being infeasible.
Of course, that does mean that you can start out and experiment with a monolith while a product is young, but I'd prefer to have hashed out the overall design before I start dealing with production systems.
I'd design components around clearly distinctive areas of functionality rather than the distinctive teams that need to write it.