Let me introduce you to a guy named David Heinemeier Hansson. He’s generally known as DHH.1
DHH is a programmer, a race car driver, and a man of forceful opinions. He invented Ruby on Rails, maybe the most important thing to happen to web development in the last 20 years. He has also invented, or at least mastered, a particular combination of tech thought leadership and lifestyle influencing - built on insisting that his personal experiences are universal principles. This is a time-honored way to get people to pay attention to you, which is probably part of the reason why on top of everything else he’s a New York Times-bestselling author.
“What is DHH disdainful of today?” could be a recurring feature of this newsletter. Right now what he’s disdainful of seems to be the cloud. His software company—which is officially called “37signals” but is often referred to as “Basecamp” after the name of their biggest product, a project management tool—recently completed a cloud exit, moving half-a-dozen products they were running in AWS back into their existing data center.
DHH says they expect to save about $1.5 million per year in infrastructure costs by leaving the cloud. And while he does leave a tiny door open for nuance in the case of small startups or hugely variable workloads, his universal principle drawn from personal experience is clear:
[M]ost established companies that can amortize capital investments over a few years should seriously reconsider the cloud craze. The benefits have been vastly overstated. The cloud is often just as complicated as running things yourself, and it's usually ridiculously more expensive.
Shots fired!
I’ve been snarky so far (it’s okay, DHH can take it) but kudos to him, he’s been reasonably transparent with his numbers and I have no reason to doubt that he’s saving the money he says he is.2 Neither does Adam Jacob, the cofounder of Chef and a longtime DevOps guru:
Nostalgia as a service
We’re paying for what we’ve forgotten how to do. There’s a certain elegiac tone to this discourse, isn’t there? A sense that things were better in the good old days before the “cloud craze”, when every company had a data center and knew how to use it.
Anytime you hear an appeal to nostalgia, your instinct should be to distrust it. I was around for some of the good old days and I can assure you they were terrible. At least, they were terrible from where I was sitting, which was far from Silicon Valley and surrounded by accidental IT people (including me) who were just making stuff up as we went along. I well remember the all-hands-on-deck calamity every time we did a midnight maintenance window, the water leaks, the endless procurement cycles and weeks-long “release trains,” the manual processes, the pet servers. A colleague of mine once deleted a bunch of un-backed-up production data off a NetApp filer and had to plead with NetApp support to help reconstitute the file pointers before the physical bits got overwritten on disk.
For us, the cloud represented a hope that things maybe could be better, because they really could not be worse. There’s a reason that even now when I talk to VP types at large enterprises, the first words out of their mouth are often “We want to get out of the data center business.” Because when you have low overall technical competency, the data center business suuuucks.
Cloud or Data Center?
So, okay. DHH has anecdotes; I have anecdotes. It’s just important to keep in mind that he runs a very specific type of business (a portfolio of mostly-legacy SaaS products) and, even with all his fame, he sits in a particular tech-centric bubble, selling books to an audience that is impressed by feats of technical skill. When DHH tells you his existing employees can run his stuff more efficiently on-premises than in the cloud, he is making a universal principle out of a brag.
But just like not every company runs at Google scale, not every company has the competence (high) or growth aspirations (low) of 37signals.
Here, I made a “Cloud or Data Center?” 2x2:
Expand, you say!
High IT Competence / Low Growth (bottom left) - This is the DHH quadrant. You are sunsetting a bunch of your products but have committed to run them as long as they still have customers, you have kickass people working for you and no plans to hire any more, sure, sign a data center contract. I’m not gonna argue with you.
High IT Competence / High Growth (bottom right) - You are running things At Scale™ and you have snowflake needs (maybe even Snowflake needs). Maybe you are investing a billion dollars in your AI strategy and need cloud GPUs, maybe you have low-latency stuff that has to run on a bespoke version of Ethernet designed by your in-house Turing Award winner. You are smarter than me, so I’m not going to tell you what to do.
Low IT Competence / High Growth (top right) - To be clear, “low IT competence” isn’t a criticism; it could be a considered strategy! A lot of tech startups fit into this bucket, like Fathom. Their founder says “We actually ran the numbers recently and serverless still works great for us. …We pay a premium for managed services to not have a DevOps team.” Cloud and SaaS help these companies pour all their energy into building new stuff.
Low IT Competence / Low Growth (top left) - This one is the kicker. These are the established enterprises, outside of the tech-industry bubble, that I spent most of my career working in and around. These are the companies DHH says should “seriously reconsider the cloud craze.”
But, like … should they?
Come with me outside the tech-hub bubble into an average midsized US city. Say, Greenville, South Carolina, where I lived and worked for the better part of a decade. There are like five significant employers there that hire IT people. The same people boomerang back and forth between those five companies throughout their career.
Most of these companies are now running on the cloud to one extent or another. As a result, they have finally started to get that local talent pool on board with basic cloud concepts like ephemeral instances and automated deployments.
If you, running one of those companies, make the bold decision to leave and go back to the data center today, what kind of talent is going to come with you? It is not going to be DHH’s brilliant visionaries who see the limitations of cloud. It is going to be the crabby people with pet servers who just want things to go back to the way they were.
Travis Cole, who ran data centers for decades and knows whereof he speaks, says he would choose cloud under these circumstances:
[I]f your team just doesn't have the skillset or desire to do any of the DIY stuff. …[Or] when it's easier to spend money than hire people with the skills to do all this stuff. Also giving teams their own AWS accounts to do stuff in is powerful.”
That’s why for the low competence/low growth quadrant I say “choose cloud, but seek help”. Your goal should be to raise the skill level of your people by forcing them into contact with cloud practices and tools. Take away their learned helplessness by giving them throwaway cloud environments they can spin up without asking procurement. Make friends with your cloud TAMs, maybe some good consultants (I know a few), and inject their competence into your team.
The cloud is a great place to raise your competence level, because you have a real-time feedback mechanism keeping you honest called “the bill”. Once you get down into the “high competence” half of the quadrant you can start reducing that bill by making choices that go against the defaults.
Don’t take the cloud for granted
In a macro sense, we shouldn’t be surprised by the sudden refrain of “cloud is overrated.” Interest rates are high; margins are king; of course every budget line item is under a microscope. I wouldn’t be surprised if quite a few other tech-first companies followed DHH’s lead back to the data center over the next couple of years, only this time taking the cloud’s tools and knowledge along with them.
As Kelsey Hightower points out, over the last 15 years cloud helped build the standards and practices needed to run on-prem better. And even DHH agrees that they could not have made their cloud exit without the advances the cloud provided.
I wish him and his team the best in taking those cloud advances - declarative infrastructure, containerization, all the rest - and applying them back in the data center world. But the data center world was managed the way it was for a reason. I think for most teams, it’ll be a constant fight to keep the economic pressures of the Data Center Way from bleeding back into their technical practices.
The scifi author Donald Kingsbury put it this way:
“Tradition is a set of solutions for which we have forgotten the problems. Throw away the solution and you get the problem back. Sometimes the problem has mutated or disappeared. Often it is still there as strong as it ever was.”
Throw away the cloud, and you might get the problems of the data center back. I remember those days. Yuck.
Guys known by three initials are generally either heroes or supervillains. You’re FDR or you’re SBF, there’s not much in between.
I don’t think he’s giving us the whole story, though, particularly around staffing. DHH claims that “[r]unning our applications in the cloud just never provided the promised productivity gains to do with any smaller of a team anyway”. But he fails to mention that something like 35% of 37signals staff abruptly quit in 2021 over an argument about politics in the workplace. (Man, remember 2021? Wild times.) So the team definitely did get smaller, one way or another.
When I did a cost calculation 7 years ago, even the AWS spot market was 3x as expensive as renting CPU time in a datacenter.
So, size-competence matrix aside, companies for whom the main cost is computing time would be ill-advised to use a cloud provider (except maybe as fallback to absorb rare load spikes that correspond to income spikes).
And Ruby is still among the 30x slower languages in the benchmarksgame¹, so I expect that the break even is hit earlier with Ruby. And if you have a significant amount of essential logic in Ruby, moving to a datacenter might be the cheaper option compared to rewriting in Java or Rust.
¹: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
While I think Rails was a truly great creation and something that has shaped a lot of frameworks and influenced a lot of other tech, and as someone who was a big Rails fan and used it for arguably my most successful company, I couldn't agree more with your statement about DHH "insisting that his personal experiences are universal principles." Anytime someone writes these kinds of things where they make blanket statements that they think apply to every other company, it instantly significantly reduces the value, weight, and trust I'd give that article. I think the cult of DHH is long gone, but his writing obviously still gets attention. Thank you for writing this.