3 ms·

I've been building systems for two decades as well and two lessons: 1) Never act like you're smarter than other developers. This is an industry with a lot of i

I've been building systems for two decades as well and two lessons: 1) Never act like you're smarter than other developers. This is an industry with a lot of incredibly smart people and with a thousand different ways to solve every problem. There is no right way to do anything. Just the best effort given the cards you are dealt. 2) Anyone who has been involved in re-platforming knows how traumatic, destructive and error-prone it is. Statistically most are a failure. That is why so many developers don't gravitate towards your approach of building a basic architecture and then building something scalable later. They try to do it all in one go. And especially for startups where everyone goes into it assuming they will be building the next Google or Netflix.

blixt 2y ago
Good points, and I agree. I think what bothers me is that a lot of the advice you might read out there is biased towards what you should build if you already had hundreds of employees and millions of users. Sprinkle in a bit of incentives from cloud providers, and you end up with a world where it only seems reasonable to start out with a Kubernetes cluster or multiple distributed communication systems from the get-go. I do think a lot of developers would intuitively start out with a much simpler system, but it almost looks wrong if you do. But it's not wrong, you can't predict the future so if you try to predict and set up your infrastructure for future success, "just in case", you'll still have to re-platform it, as you say. I should add that some form of re-platforming is pretty much inevitable at some point in the lifetime of a business no matter which approach you take. Because infrastructure is informed by the structure of your organization as much as the needs of your product. If your number of engineers increases by a couple of orders of magnitude, it's likely any infrastructure you set up will need to reshape to account for that.

blixt 2y ago

Good points, and I agree. I think what bothers me is that a lot of the advice you might read out there is biased towards what you should build if you already had hundreds of employees and millions of users. Sprinkle in a bit of incentives from cloud providers, and you end up with a world where it only seems reasonable to start out with a Kubernetes cluster or multiple distributed communication systems from the get-go. I do think a lot of developers would intuitively start out with a much simpler system, but it almost looks wrong if you do. But it's not wrong, you can't predict the future so if you try to predict and set up your infrastructure for future success, "just in case", you'll still have to re-platform it, as you say. I should add that some form of re-platforming is pretty much inevitable at some point in the lifetime of a business no matter which approach you take. Because infrastructure is informed by the structure of your organization as much as the needs of your product. If your number of engineers increases by a couple of orders of magnitude, it's likely any infrastructure you set up will need to reshape to account for that.