I will defend the FAANGs just a little bit-- at least Amazon, Google and Microsoft-- in that they are now large SAAS providers and so "building it here" is essentially the same as eating your own dogfood, which is very much a good thing.

I would also add that everyone is evaluating the tech stack of these companies in today's context. Google was founded in 1998. Facebook was founded in 2004. Uber was founded in 2009. Microsoft was founded in 1975.

Amazon EC2 was first offered in 2006 and was super new and immature for a number of years. Kubernetes was first released in 2014. Mesos was a research idea for a number of years starting in 2009 and didn't reach version 1 until mid 2016. Etc. Etc.

These companies generally invent their own solutions because the solutions everyone here thinks they should be using didn't exist or were not stable at the time they had a problem they needed to solve.

By the time those new solutions exist and are stable enough, it requires quite a bit of investment to migrate to the newer solution as these companies already have much of their tech stack stable and bringing in revenue on their in-house solutions.

Rebuild $infra from large company and provide it as SaaS was a pretty good recipe for a decent software business for a while. It might still be. For example, PagerDuty came out of monitoring systems at Amazon.

I feel like what's pointed out in this comment is so obvious that it shouldn't be needed ... but evidently it is.

Sadly, it does need to be pointed out, pretty much every single time. Same with the "Why does company X need so many employees?" question, which you can just reply to with this link: https://danluu.com/sounds-easy/

It's also a risk mitigation strategy. As your company's size grows, so does the liability of your dependencies that you don't control. If you can throw a few engineers at a problem and save yourself tens of millions of dollars in risk, it's worth it.

It’s not risk mitigation, more a risk swap between “unknown risk”—we don’t know if this third-party product is going to meet our future needs—and “known risk”—we have full control while we are willing to write checks to fund it.

In the latter case there’s still plenty of risk: you might be spending valuable time building something that doesn’t work, is obsoleted by future change or future products; and the one that most people dismiss, you will be at the mercy of its creators. The people who build your critical technologies will have power over the organization you might regret later, and if they do leave, finding replacements can be hard and/or expensive.

The net risk reduction of course depends on specific situations, it is not always better and it is not always a "swap". In some cases, eliminating unknowns reduces more risk than is added by building in-house, which is when it makes sense to build in-house.

Spot on! Never thought about it from this perspective. :-)