Archive

The Dulin Report

Browsable archive from the WordPress export.

Results (27)

Strategic activity mapping for software architects May 25, 2025 On the role of Distinguished Engineer and CTO Mindset Apr 27, 2025 My giant follows me wherever I go Sep 20, 2024 The day I became an architect Sep 11, 2024 Form follows fiasco Mar 31, 2024 On Amazon Prime Video’s move to a monolith May 14, 2023 One size does not fit all: neither cloud nor on-prem Apr 10, 2023 Comparing AWS SQS, SNS, and Kinesis: A Technical Breakdown for Enterprise Developers Feb 11, 2023 Why you should question the “database per service” pattern Oct 5, 2022 Monolithic repository vs a monolith Aug 23, 2022 All developers should know UNIX Jun 30, 2022 There is no such thing as one grand unified full-stack programming language May 27, 2022 Most terrifying professional artifact May 14, 2022 Best practices for building a microservice architecture Apr 25, 2022 TypeScript is a productivity problem in and of itself Apr 20, 2022 Tools of the craft Dec 18, 2021 TDWI 2019: Architecting Modern Big Data API Ecosystems May 30, 2019 Which AWS messaging and queuing service to use? Jan 25, 2019 Let’s talk cloud neutrality Sep 17, 2018 What does a Chief Software Architect do? Jun 23, 2018 Singletons in TypeScript Jul 16, 2017 Online grocers have an additional burden to be reliable Jan 5, 2017 What can we learn from the last week's salesforce.com outage ? May 15, 2016 IT departments must transform in the face of the cloud revolution Nov 9, 2015 Top Ten Differences Between ActiveMQ and Amazon SQS Sep 5, 2015 What can Evernote Teach Us About Enterprise App Architecture Apr 2, 2015 Docker can fundamentally change how you think of server deployments Aug 26, 2014

One size does not fit all: neither cloud nor on-prem

April 10, 2023

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:





  1. 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,




  2. Most applications don’t need to collect and index 27 gigs of data per user (8 petabytes divided by 300000 HEY users),




  3. 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?