Thread by @zackkanter

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's unfeasible to recreate noncommodity infra. 1/n

https://twitter.com/martin_casado/status/1397989124682903554

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'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're effectively buying autoscaling, on-demand top talent. 4/n

Bear in mind that "profit" is always an opinion. It'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'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'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'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'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't possibly do better ourselves? This is called "servicefull" architecture – using your provider's cloud-native services to replace server code. 9/n

If you're using AWS/GCP to run vanilla servers, you'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 'software is eating the world.' If you believe that superior software is paramount, then you shouldn'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.

Also: if you’re an engineer who is horrified to be working at a company where leaders say hurtful things like “we’re going to rebuild AWS to save money” or “maybe we should rebuild AWS to save money,” you should come work with us instead.

This thread can be summarized as: any technology strategy requiring significant effort, whose alleged primary benefit is a strictly measurable decrease in cost, is wrong.

Even the cherry-picked examples in the author's piece don't check out; compare the returns of repatriation poster child Dropbox vs AWS-spendy Datadog.