Read on Twitter
Excellent *financial* analysis of using *commoditized* cloud infrastructure (vanilla servers). It misses: i) the (long-term devastating) cultural cost of recruiting world-class engineers to do undifferentiated heavy lifting; ii) it& #39;s unfeasible to recreate noncommodity infra. 1/n https://twitter.com/martin_casado/status/1397989124682903554">https://twitter.com/martin_ca...
On i: saving 50% on COGS sounds great – until you realize that it means recruiting & retaining engineers instead of paying an AWS/GCP invoice. Opportunities to buy technical competence with a credit card are extremely rare; you can& #39;t buy core product competence per API call. 2/n
Every sufficiently-funded software CEO on earth will tell you that their constraining factor is hiring great engineering talent – repatriating commodity servers to save on COGS means increasing engineering headcount requirements, definitionally making the constraint worse. 3/n
It follows that the optimal strategy is to do *the exact opposite* of reducing third-party API COGS: fanatically review labor COGS and shift it to third-party API COGS wherever possible – regardless of cost! You& #39;re effectively buying autoscaling, on-demand top talent. 4/n
Bear in mind that "profit" is always an opinion. It& #39;s easy for cloud repatriation to look great margin-wise because labor costs are up to interpretation (COGS vs R&D, etc), whereas third-party API (i.e. cloud) spend is unequivocally COGS. Long term EV is what matters. 5/n
The author showcases Dropbox as a cloud repatriation success story (i.e. company& #39;s accounting opinion is margins improved); market is unimpressed. Series C in 2014 at $10B – flat, +7 years. 6/n
An unfair example, you might say – Dropbox& #39;s core product has been commoditized during that time period! Sure is tough to innovate when your engineers are focused on repatriating undifferentiated cloud infrastructure to save money. 7/n
Part ii [it& #39;s unfeasible to recreate noncommodity infra]: if you look at what your cloud provider is doing for you & your takeaway is "we could do this cheaper ourselves," then your problem is you& #39;re using the cloud incorrectly by choosing lowest common denominator services. 8/n
Instead of saying "we can run servers ourselves for cheaper," you should be asking: how can we use AWS/GCP in ways that we couldn& #39;t possibly do better ourselves? This is called "servicefull" architecture – using your provider& #39;s cloud-native services to replace server code. 9/n
If you& #39;re using AWS/GCP to run vanilla servers, you& #39;re building software to work the same way it did when companies ran servers in their office 15 yrs ago. That should be a wake up call about your technology choices – not a call to put servers back in your figurative office. 10/n
All in all, a strange take from a firm founded on the idea that & #39;software is eating the world.& #39; If you believe that superior software is paramount, then you shouldn& #39;t be choosing the cheapest software – you should be choosing that which compounds at the fastest rate. Our guidelin
End.
tl;dr
Adding an FAQ:
Q: Aren’t there exceptions? What about ______?
A: No.
Q: Aren’t there exceptions? What about ______?
A: No.
