4 ms·
To know what the ROI actually was we'd need to know both the costs and returns of this type of work. Proposing a way to save $[redacted]M per year doesn't mean
by mike_hearn 4y ago
To know what the ROI actually was we'd need to know both the costs and returns of this type of work. Proposing a way to save $[redacted]M per year doesn't mean the ROI was high because it depends on the cost of having a kernel/compiler team. A team of specialised kernel hackers, in a place where you're competing against Google for them, in the Valley which already has high salaries, will be an expensive team to have. It's not going to be enough to deliver some improvements to the kernel scheduler that could save a lot of money if you only do it once. You'd have to yield massive savings like that every single year.
Technically to really understand this, you'd also need to do a calculation of what it'd cost to just outsource to a more specialized company like Red Hat or (for the JVM) Oracle itself, where the knowledge of what to do is already present and can be amortized over more companies. For example what was the ROI of Twitter writing its own compiler optimizations vs just making a deal to buy Graal Enterprise which has far more optimizations in it that improve Scala than the ones Twitter wrote? How much would their kernel changes have cost if they'd acquired them through a high-end support contract with a Linux distro company? How much money would they have lost from migrating to the cloud DB and suffering higher tail latencies, vs the added cost of writing and supporting their own database from scratch?
I don't know, maybe at Twitter the engineers were doing this sort of calculation on a regular basis, but my experience when I was at Google was that most engineers weren't doing so and indeed could not, because there was no solid basis on which to compare the cost of engineering time vs machine costs. Neither were exposed to the bulk of the staff in comparable units. Obviously at some level up the management hierarchy these costs started to become relevant and must have been taken into account but a lot of projects were bottoms-up and never did any sort of build vs buy cost/benefit tradeoff. In fact I don't recall anyone buying off the shelf tech or even proposing to do so, other than in the early days with Orkut and that was a maverick approach that was quickly rewritten onto internal platforms. In my time there I saw a document that compared the costs of using home-grown infrastructure vs open source commodity stuff exactly once (for Gmail) and it didn't even take into account salary costs yet the commodity stuff won by miles. Needless to say, that analysis was a very obscure document. They didn't need to care much, due to the prevalence of money and skilled engineers. Twitter doesn't have the same prevalence of money.
So overall this list looks to me more like a list of cool and fun projects rather than a concrete financial argument that it actually had a positive ROI. We just don't have enough information to know that.