Last year 37 Signals (makers of Basecamp and Hey)  announced they were leaving the cloud. I wrote about the decision, and wondered if they'd look back at this as a great decision or one they'd regret and backtrack to the cloud again. They planned to build their own tooling, buy a bunch of servers, and run their own data center (or rather, rent space in someone's data center).

Recently there was an update, in an FAQ, about how the transition has gone. In short, very well. One of the founders, David Heinemeier Hansson answered several questions about the move and the financial status. They didn't hire more people, so their payroll is the same. They used a service to unpack and rack their servers, so they could just connect to them remotely and not deal with hardware. They built their own redundancy across two data centers where they rent space, and they think they will save well over $7 million in the next 5 years. They had a $3.2million cloud budget per year, so that appears to be halved (3x5=15 - 7 = 8ish) with their move.

There are some answers to various questions, which are likely of interest to many data professionals who might feel pressure to move to the cloud. First, they discuss resource optimization in the cloud. I think that's really hard, to do well and if they gave the details of what they'd done, that might help others decide if 37 Signals did a good job, or if there are things others could do. I think many people might struggle to optimize their usage, especially if you are only responsible for one thing, like the database. In many orgs, once something gets deployed, or developers build a PoC using some cool, new service, it's hard to get rid of it or even change how it's used. I think 37 Signals has some agility here that many orgs struggle to implement.

Rewriting things are cloud-native is the way to go, in my mind, and I do have customers and clients who see applications working better in the cloud. However, I might argue that rewriting applications is hard and expensive, and many companies aren't great at writing software that's efficient, so rewrites are hard. I also think in most organizations, developers struggle to understand what cloud-native means. I think DHH is a little off here, as their developers probably could make better software written for the cloud, but they didn't want to spend the time and/or money.

The points about security and reliability are fair, but I think those are a function of having good people implementing systems. You can get good security and reliability in the cloud or poor implementations of either. The thing about security is that the overall protections that detect some of the DDOS or attacks are better with Azure/AWS, but simple SQL injection or open firewalls are still a problem. Authentication and security are just hard for most people and often people do this poorly in the cloud. To be fair, most people don't do this well on-premises, so at least in the cloud, there are some services/scanners/checks that let you know when you've messed up. Whether you change or implement their suggestions is another whole debate.

Is reliability better? AGs are hard in SQL Server, as are distributed clusters. The cloud services do this better for most people, but maybe not for you. That brings me to his super engineer point. He doesn't think he has super engineers on staff, but I disagree. I think they can pick good people, especially because of their profile, and they don't need a lot of people, so their average engineer is likely better than the average engineer at most organizations. They built some great software, and they've built an amazing framework and tooling to deploy their software. Don't tell me that's even close to the capabilities of the staff at many organizations. We have really good engineers at Redgate, and I think we're above average as well. I don't know how we compare to them, but we haven't had people publicly write and release code that thousands of other developers use. At least not at quite the same high profile level.

The cloud has its place. It can work well and it can be very expensive. This journey is worth sharing with your management if they want to move to the cloud, especially if they want to lift and shift. That might create some flexibility and CapEx/OpEx changes that are worth it, but you ought to debate and question whether that's reality or marketing hype from a vendor. After all, it's not clear if a cloud move is really something that returns an ROI or one that reduces your profitability.