If your application is not built as cloud-native, then you won’t benefit from the cloud
David Heinemeier Hansson of 37signals wrote a series of posts discussing how much his team will save by moving away from the cloud. Seven million over five years is his estimate.
I’ve been building cloud-native architectures for over a decade now. The arguments against cloud adoption have always revolved around cost and security. I’ve heard all sorts of things ranging from assertions that the cloud is more expensive than data centers to absurd arguments that Amazon will steal your product inventory data from your RDS instances for their competitive advantages. As I wrote in my InfoWorld post in 2016, there is no genuinely neutral cloud provider that won’t compete with you either.
But let’s get back to David’s reasoning. Without knowing the details of the software, and how it works, we can’t truly judge the architecture, though we can deduce some of the aspects. In 2022, HEY and some legacy apps architecture revolved around the following:
- Full Rails application running via EKS,
- MySQL via Aurora RDS,
- Redis via Elasticache,
- Search via OpenSearch
If you are starting your architecture with a full Rails stack, that is not a cloud-native architecture. Full Rails stack is not server-less. You are considering your architecture in terms of continuously running servers that must be up 24/7.
Anchoring your architecture to having some servers running 24/7 is not how things are done in the cloud. My gut tells me that had the architecture been built around AWS Lambda instead of a full Rails stack, the cited $759983 spent on compute capacity in EC2 instances would be orders of magnitude lower.
37signals isn’t revealing what is actually stored in S3, what features of OpenSearch are used that cannot be provided by MySQL, and what Redis is delivering that is not effectively done by MySQL query caching.
Most applications don’t need the tech stack they have. Vicki Boykis eloquently covered this back in 2019. Most applications don’t need the complex stack that they have — they can run on a Raspberry Pi sitting on one’s desk connected to the Internet via a consumer-grade Xfinity connection.
Fernando Alvarez from 37 Signals writes:
In 2023, we hope to dramatically cut that bill by moving a lot of services and dependencies out of the cloud and onto our own hardware. We don’t operate our own data centers, but work with our friends at Deft to lease rackspace, bandwidth, power, and white glove service. That isn’t cheap either at our scale, but it’s far, far less than what we spend on the cloud.
It also means that nobody from 37signals is actually roaming around a data center, racking equipment, or pulling cables. We order from Dell, have it delivered straight to the data center, and then we see the servers appear online, and then we get to work.
One could argue that HEY is a cloud service in and of itself. In 2016 it made perfect sense for Dropbox to leave AWS for a simple reason: Dropbox is in the business of providing a cloud service. Building a cloud on top of a cloud probably makes no financial sense. Given that HEY may be a cloud service in its own right, I see no reason for them not to build their own cloud.
I am not trying to argue that HEY is making bad choices. Quite the opposite: they are making choices that make sense for their company. Everyone has different experiences and needs. I always argue against Shakespearizing, i.e., doing something for your project just because some tech company is doing it for theirs. Only you know your project and your needs — so if the cloud makes sense to you, use it; if it doesn’t, don’t. Please don’t Shakespearize.
If I am going to leave you with something to take away from this post, it is this food for thought:
- Most applications do not need the stack they are using. They can run on a Raspberry Pi with a 1 gigabit Xfinity connection out of your basement,
- Most applications don’t need to collect and index 27 gigs of data per user (8 petabytes divided by 300000 HEY users),
- If you are thinking in terms of EC2 instances and continuously running servers, you are not thinking cloud-natively
It is worth having this debate. What are your thoughts?
The Dulin Report 