,
17 tweets,
3 min read
Read on Twitter
Ok the quiet period is over so welcome to my thread on "high" levels of ☁️ spending.
There has been a lot of coverage lately on how much 💰 companies are spending on public cloud. Lyft, > 10M per month, Apple > 30M per month, etc. This seems like a ton of 💰 right? Clearly all of these companies can do better in-house, right? Wrong!
Don't get me wrong, 10M+ per month is a lot of 💰 in absolute terms, but the real question is whether a company can actually do better than that when considering TCO.
TCO is total cost of ownership. This includes CAPEX (1 time capital costs, possibly amortized) and OPEX (ongoing operational expenses). As an industry, we do a good job of calculating CAPEX, but a terrible job of accurately calculating OPEX.
SW development costs technically might be considered CAPEX, but for the sake of discussion I'm going to bundle them in with OPEX, as a thing we are terrible at accurately estimating.
OPEX includes support, initial/ongoing development, maintenance, repairs, etc.
Now, the math that a company using public ☁️ needs to do to see if they will come out ahead is "simple:" can the company replicate the features AND reliability for an amortized price less than what they are paying per month?
But if we agree that as an industry we are horrendous at estimating true OPEX costs, how can one approach these calculations?
I would propose the following very simplified model for thinking about this: let's start by thinking about how much engineers cost per year, and then thinking about whether that many engineers can replicate the existing functionality.
In our current highly competitive job market, let's say that an average engineer costs around 500K per year "all-in" (salary, office space, benefits, etc.). (I don't know the real numbers used, but I think this is probably conservative and the cost might be higher for top-tier.)
So if a company is spending 100M per year on ☁️, the question is can that company replicate both the features AND reliability with 200 engineers. This is not even considering CAPEX for DC build out.
When framed like this, I hope it becomes obvious that it's absurd to think that 200 people can instantaneously replicate what AWS, Azure, etc. are providing. We are talking about raw DC build (HVAC, power, etc.), racking, physical networking, provisioning, managed services, etc.
Additionally, 200 people cannot be hired overnight, and they certainly cannot quickly replicate the years of outage learnings which allow the ☁️ vendors to run at high reliability.
So the question becomes: where is the break even point at which it does make sense? Obviously the answer is situation dependent, but for a "diversified" usage portfolio (compute, storage, networking, managed services), I would not consider private before spending ~50M per month.
At ~50M per month, a 200M DC build (multiple locations, redundancy!) can be amortized across multiple years of hundreds of engineers replicating that stack.
At less than ~50M per month spend, a company is going to get far greater value and velocity by focusing on reducing ☁️ spend, vs. reinventing the wheel at an almost guaranteed higher TCO if the company tries to go private.
Summary: replicating what the public ☁️ provides is VERY expensive. Building features is expensive. Building reliability is even more expensive. Focus on TCO and creating value for your company, not reinventing the wheel at what is very likely to be higher cost.
