3 ms·
Mmmm I don't know if I agree with that logic. I'd argue the opposite -- as a startup, you can't afford to micro-optimize. Labor, time and opportunity cost dwa
by bpodgursky 7y ago
Mmmm I don't know if I agree with that logic.
I'd argue the opposite -- as a startup, you can't afford to micro-optimize. Labor, time and opportunity cost dwarf all but the grossest resource waste. If you need to use 100GB/k8s node instead of 50GB, it will have 0 effect on the success of your venture.
At Google scale, it becomes worth it to optimize:
- You are delivering more product per engineer, and more product means more resources. Instead of a single customer instance which costs $1/month more, you have 100,000 customer instances, costing a significant amount more. It becomes worth trimming margins.
- You have economies of scale, and it might be worth it for an engineer to spend a month trimming 2% of the cost of a software deliverable.
The common refrain for startups is "do things that don't scale", and this is for good reason. Google has to actually worry about fixing things AFTER they are scaled.
- fwip 7y agoI think you're both right. A 125MB binary is relatively beefy, but still easily fits in RAM. The amount of disk that you're spending on a single executable (your database, in this instance) is tiny in comparison to the amount of data stored in that database. It's definitely worth it for Google to trim 2% off of their storage requirements - but if your binary is 0.1% of your storage, it's barely even worth glancing at.
- TheReveller 7y agoThere are plenty of efforts and tooling that reduce the number of dependencies and the deploy size of binaries at Google. The notion that we don't care about size isn't true. But it's true that it's not worth optimising first, it's done by first evaluating the impact across the fleet and then prioritising the most effective changes.