3 ms·
At my work we’re one step past where it sounds you’re at. I’ve been around since the very early days so I’m both part of the original problem and the solution.
by Moto7451 6y ago
At my work we’re one step past where it sounds you’re at. I’ve been around since the very early days so I’m both part of the original problem and the solution. Now our biggest problem is we don’t like to work with the things we built to handle scale. I’m not sure how common that is but I don’t believe we’re alone. A lot of the problem from my point of view was trying to chase trends.
We have Kafka in places the article’s author would suggest are inappropriate. We have a lot of “one true systems” that hid horizontally scaling instead of making it easy to build clusters of micro-services. Now we’re riding micro-services pretty hard and that isn’t going well since we have too many mixed architectures in use.
I think it’s correct to push out worrying about scale while you seek product market fit. I think that once you do need to scale you really need to put thought into the process. This is difficult if everything is on fire and failing. If it’s not, burn some time to plan. It’ll pay off. Be sure you don’t reinvent things you can cheaply buy. Make sure developers still like their day jobs after the changes are made before making more changes with the same underlying design theories.
- Person5478 6y agoAs companies grow there will be "pain points" that come up due to scaling (performance, architecture, development, etc). When you get to that point it's normal to wish the pain didn't exist by "doing it right" the first time, but I think it's still better to wait until you have the pain. Because that pain tells you unequivocally what you need to value in the scaling.