7 ms·
There's two very different ways to interpret the "don't worry about scaling" stance and I think that's where things go sideways. On the one, people take it as
by brightball 6y ago
There's two very different ways to interpret the "don't worry about scaling" stance and I think that's where things go sideways.
On the one, people take it as literally "don't worry about it, just make it work" and don't think through simple decisions.
On the other, with some basic analysis you can identify where your likely bottlenecks are going to be and make some preparations to dramatically simplify scaling when you need to do it. Sometimes minor architectural decisions, that don't take much time, can lead to a happier long term life.
But I 100% agree with designing for horizontally scaling.
It's one of the reasons I always try to steer people in the direction of Heroku for new projects, because while it reduces your ops burden and makes your life easier...it also forces you to design for horizontal scalability from day 1 via 12 Factor.
- acdha 6y agoThat’s how I take this, with a related point of thinking about how you’d replace components when the time comes. Maybe you have a monolith-leaning design but you have tests, a clean API with some idea of ownership, etc. rather than a bunch of code directly making SQL calls, copying the same logic instead of using a function, or touching the shared files so when you do split things out and redesign them the process is safe. (Having flashbacks to the same code in 3 PHP repos, maintained by one person, no two copies identical)