Before I start, this is my specific industry niche. It's nuanced, incredibly complex, and it's a near certainty that any issues I take with the report aren't criticisms of @martin_casado or @sarahdingwang at all.
Similarly, any VC criticisms I make are broad, not @a16z specific!
We start with this graph. Clearly something momentous happened in 2020 on a global scale: you forgot to turn your EC2 instances off.
This may surprise some folks, but I completely agree with the highlighted segment. A rearchitecture for purely cost reasons is DOA unless the economic unit model is so vastly far apart that it comes down to a question of business viability.
Okay, now they're getting into the Dropbox repatriation story (ever notice there isn't a second story like this?).
It was a single very well understood, very niche workload: storing user files with access patterns that didn't (at the time) align with S3's pricing dimensions.
There's a lot of speculation in analyst circles about how "real" that savings figure is.
Hypothetically, had they not done it, what could they have focused their engineering efforts onto instead?
"Shipping that bad desktop client sooner," so it's good they repatriated!
Last year Dropbox migrated a 34PB analytics cluster to @awscloud--and there's the rub. Cloud is increasingly talking about higher level capability stories, not baseline data center primitives.
Further, if there's a post-seed company who spends more on cloud than they do payroll, I haven't met them yet. Engineers are always more expensive than infrastructure.
I'm sorry, but "should we repatriate this workload" isn't a complex decision at all.
The few slam dunk "should this workload be in public cloud" are obvious enough that the napkin math in the planning stages make it abundantly clear. It's usually data transfer driven.
I strongly disagree with this sentence. Let's be clear: I run a company that fixes the horrifying @awscloud bills. I absolutely *want* this to be true; I could buy nesting doll yachts if it were!
But it's not true.
I've talked to a wide variety of customers (duckbillgroup.com/clients are some of them); cost optimization *always* takes a backseat to decreasing time to market / feature velocity.
This is as it should be, sad though it is for my maritime aspirations.
I have tremendous respect for @halvarflake; we've chatted on the Screaming in the Cloud podcast before.
"Lies, damned lies, and TCO analyses" aside, I suspect he's directionally correct on the ballpark numbers here--with one key caveat. "Poor cloud governance."
If you're a company that struggles with effective governance... yeah. Cloud spend scales with the number of engineers you have, whereas Procurement is great at saying you can't place that SuperMicro order this quarter.
Think of it like a continuum. It looks about like this:
Managed well, the "cloudier" you are, the more efficient your spend becomes. It's true!
What then explains the drive for data centers / this mythical cloud repatriation argument?
Simply put, it's easier to *predict* and *control* your costs in data center environments, as opposed to "pay per request" models.
For companies lying about how "cloud native" they are, this is paramount.
"I will spend $2 a month over the next 36 months" is vastly preferable to "we will average spending $1 a month for the foreseeable future, but that's only accurate to within 20% or so" to an awful lot of companies.
Data centers speak to that; cloud does not.
And the report makes this assertion. I 100% agree! My only argument is "hold my tea, I can triple that sucker overnight if you want."
Your *infrastructure* bill will swell, but viewing cloud through the lens of purely infrastructure is a blunder.
I went into this in some detail a few years ago regarding Lyft's AWS bill when they went public.
(I should point out that I have no partnerships with any vendor. If it makes sense for *you* to migrate to a data center, I will absolutely tell you so.)
Lastly, I disagree with this closing item from the article.
By building for a theoretical exodus, you pay for optionality with feature velocity, and reduce your chances of getting to a position where the cloud costs even matter to your business's overall success.
My guidance remains "pick a provider (I don't care which), and go all in until you're forced to reconsider."
If I were at @a16z I'd explore alternate strategies given my exalted position in the industry. "Companies we invest in all sign on under a custom agreement that we negotiate with the cloud providers ourselves." Not many folks have the cachet to pull that off, but I'd try it.
Fundamentally companies that focus more on cost optimization / reduction than they do growth tend to be companies in decline. That's not who @a16z invests in; it's not their market.
I come away with the conclusion that this report is right a lot, but misses some key context.
There's more that I'll go into in longer form elsewhere, but its foundation is solid. Really, the only thing @martin_casado and @sarahdingwang "missed" was not exclusively focusing on this problem for a few years. I suppose that's forgivable. 😉
• • •
Missing some Tweet in this thread? You can try to
force a refresh
And now, reply to this tweet (or DM me) with your career questions, and I will advise you in the form of a shitpost.
I'd take a look at what salaries in this industry have done over the past 18 months and seriously question whether you've maxed the salary, or merely maxed it at your company.
Oh hey, to install RedHat OpenShift on AWS I have to grant @RedHat administrator access to the entire @awscloud account.
“You mean Administrator access to the ROSA service principals?”
No, I do not.
I should point out that this is significantly broader than AWS's own accesses into your account. You will have no secrets from RedHat if you do this. KMS keys? Theirs. Passwords? Theirs.
These are the only things RedHat can't do with that role:
So in tonight's thread I want to change things up a bit, and talk about things I like about @awscloud. Strap in.
First, the folks working in the tech field, including training and certification as well as @awssupport are miracle workers. I mean, think about it—they have to deal with you people!
IAM is complicated and tricksy, with dangers all about. The identity + security folks have what are functionally impossible jobs, but somehow they consistently deliver.
Back up any personal (NOTE: NOT CORPORATE IP!) data on my work laptop whenever I get a context-less "let's talk" message.
Putting all of my corporate expenses on my personal card, then expensing them instead of the other way around to avoid giving them the "well technically this might be embezzlement" stick if they disagree with a decision.