I don't think 37signals is a very strong example that this could become a trend. They are in the goldilocks zone where they're big and stable enough to save a lot of money with self-hosting, but not big enough that they can negotiate meaningful discounts with Amazon.

In reality cloud is too convenient, and the tradeoffs for self-hosting just don't make sense for the majority of companies. The talent to run your own servers with modern HA and reliability expectations has largely been consolidated into the giant cloud providers and other large companies at this point. As much as I think a lot of cloud is wasteful and more diversity would be beneficial, I don't see any meaningful change to cloud dominance on the horizon.

> modern HA and reliability expectations

For most businesses, this is a fiction. Typical users are just as accustomed to outages and feature failures as they were twenty years ago, which is to say that they swear for a couple hours but almost never migrate to competitors just because a service goes down now and again. They anticipate that the other service will be down just as much, and the friction of moving to a new service means there's got to be a real gain, not just a speculative one. Even in retail, users typically come back to where the catalog and price is right, and where they've had good post-sales experience and loyalty points, just like when a shop around town in unexpectedly closed because of a water leak or whatever.

Further, it's unclear that cloud vs managed hosting vs experienced self-hosting vs fairly naive self-hosting has a particularly different net reliability or availability profile for most use cases. That was the sales pitch of the cloud and it became acargo cult saying for a while, but it's very hard to demonstrate in a scientific way. It turns out cloud services fail plenty and of course the vast majority of services hosted in other ways do just fine.

There are exceptions to all this, but they're rare, not routine.

Agreed, but this matters little if you can't hire people to manage your on-prem infra. 25 years ago everyone had a sysadmin and a DBA, now they are outnumbered by "devops engineers" who just know AWS and K8s.

I think one key requirement is a strong centralized directive on allowed technologies. If every team is allowed to run whatever they want, you’re likely going to struggle to run it on-prem, if for nothing else it’s unlikely that a dev team has the knowledge or resources to operate and maintain Kafka, for example.

Running HA services on your own is not as difficult as it’s made out to be. Anything stateless can just be another endpoint behind a load balancer. Stateful things like RDBMS require more thought (not only for HA, just in general), but this is also a solved problem.

The other thing this requires is a more careful and performance-oriented approach to development. “It works, ship it” will likely wind up consuming far more resources than you’d like. Taking the time to profile the code – which can be done in CI – and addressing hot spots will greatly help.

> The talent to run your own servers with modern HA and reliability expectations has largely been consolidated

I kind of learned how to do all of this from Homelab communities. Claude 3.5 does really well with eliminating the toil of configuration documentation. If anything people vastly underestimate their capability to do this stuff themselves.

That said, AWS RDS is a unique product that people will not migrate from. As long as Postgres developers and ecosystem continue to work for Amazon for free, companies will be overcharged by it.

> homelab communities

Yes! Moving past “I want to run Plex” is possible and encouraged.

> toil of configuration documentation

IMO, if you don’t understand what you’re configuring and why, you’re not really any better off. And especially with the Linux community, if you can’t demonstrate that you’ve personally read docs and explain what you’ve tried, you’re gonna have a bad time.

DHH did mention in the article that if you are just starting up and finding market fit, you should use the cloud and not buy your own hardware.

I hope so. We were considering migration from on premise to AWS or GCP. Did a couple of simulations, went with renewing hardware for our on premise. It was the right choice. Storage alone is almost 3 times more expensive on cloud, compared to a netapp appliance with financing... Stil using GCP for couple of use cases (e.g. BigQuery, Vertex), some backup infra, but 95% works on our hardware in rented racks.

cloud computing is way too expensive for what it is. you'll have most of the benefits with a managed database and a good cdn

Only in that the growth of cloud migrations might slow. The cloud is a great option for a lot of workloads and companies. Cloud native applications and services can be cost effective. Lift and shift is the most expensive way to go and can end up costing more than on-premise.

Any views or experiences evaluating OpenStack instead of one of the big ones AWS/Azure/GCP? OpenStack has a bad rep due to added complexity and limited developer tools that may lead to ultimately higher TCO but I wonder if this similar to what Linux was like roughly pre-2005 before becoming commercially robust and refined enough to replace many corporate-level server operating systems.

Linux was a corporate-level operating system as far back as the mid-90s. It was the late 90s when it started getting enterprise software for example https://en.wikipedia.org/wiki/Oracle_Database released Oracle 8 was released for Linux in 1997.

Enterprise Linux was getting going for real in the late 1990s but in my view it was more 2005-ish that it became "mainstream" in these sphere. Sun Computer for example started to support Linux in 2006 and was a Hail Mary to try to save itself as SunOS was being eaten away by Linux.

Redhat Inc became part of the Nasdaq-100 in 2005.

I make this comparison as the question is whether OpenStack still has the potential to become a full go-to alternative in the way that clients consider closed cloud systems from AWS/GCP/Azure as substantial equivalents.

I see your point but disagree. Sun was the last holdout of the propriety Unix vendors to support Linux because they had underpriced the other Unix vendors like Linux was underpricing them. Sun's whole idea was to create cheap Unix workstations by using commodity parts and having a low-cost Operating System in SunOS and then Solaris.

Becoming a Nasdaq-100 company is a trailing indicator of going mainstream. By 2005 RedHat and Enterprise Linux had won, and Sun had about 5 years before Oracle purchased them.

OpenStack is great if you want to manage your own data center and some companies should do that. It is a cost/benefit analysis that some will make on the side of doing their own thing.

I would like to be able to use commodity hosted compute and storage and then build all the fancy stuff on top using open-source components. The generic providers like Linode are commodity at this point so this seems like the best of both worlds.

I have no confidence in my ability to configure Postgres on K8s with backups, however.

How many engineers does 3M buy? Enough to risk running your own hardware? Maybe.

I think so, but it's also funny to see some companies (my current included) struggling to get there to replace their on prem private Cloud, driven in large part by the VMware Broadcom situation.

It depends on where you are coming from. If you are a startup going from 0->N then sure cloud makes sense and you can architect for cloud.

If you are a 50 year old Fortune500 that was cargo culted into "we must migrate to cloud", it turns out that lift-and-shift to VMs is hideously expensive. But also, re-architecting 50 years of internal software is also hideously expensive.

Also, you are also already the scale that you had your own DCs / rented space in DCs, with the internal expertise to operate there.

So lots of CapEx to get to a place where you have.. possibly higher OpEx?

> If you are a 50 year old Fortune500 that was cargo culted into "we must migrate to cloud", it turns out that lift-and-shift to VMs is hideously expensive. But also, re-architecting 50 years of internal software is also hideously expensive.

One underappreciated aspect of this is that it really isn't possible to control cloud costs in a large enough enterprise even aside from the costs of running your actual applications.

You can have all the tagging and chargeback and finops as you want but at the end of the day trying to manage cloud costs is a losing battle.

Not only do you have the costs of running the applications you actually need which are far beyond the costs to run them on prem because suddenly your app that could run on a single server is running on a 12 node EKS cluster spread across several AZs. You also have the additional costs of all the additional grey matter resources that can't be traced to owners anymore but might still be used somewhere.

There will be 50 dev EKS environments that nobody knows for sure who owns or whether they can be shut down. There will be non-compute resources with monthly charges like the 5000 kms keys at $1/key/month without any easy way to know if there's an object in S3 somewhere that used that key and is subject to a legal retention policy. They all add up.

Sure you can say "Well just be more disciplined" but discipline and large enterprises are orthogonal concepts, especially when the people who start cloud migrations are the type who don't think ahead and usually bounce to another job before the costs of their poor decisions come due.

None of this would really matter if it were just enterprise companies padding Amazon's bottom line but the expansion of data centers has real world costs in the destroyed ecosystems and usage of energy and water for all these unused and useless resources.

Yes, having to go to someone senior and justify $1M in server purchase periodically does introduce actual cost discipline.

Cloud offers rapid scaling which also means uncapped incremental OpEx, which for large established enterprises presents some unique challenges.

You can try to be permissive so teams can iterate more quickly than on-prem, which then leads to ever growing spend. Or you can be restrictive, and then the flexibility and rapid scaling of cloud is slowed to that of datacenter ops.. but with the added overhead of cloud margin padding.

I have seen some amount of the needle flipping in the financial service space as well.

10 years ago you saw some first movers to cloud, the last 5 years have been a lot of followers for the sake of it (hey are smarter/bigger peers did it! - CTO).

Numerous shops have become a lot more selective on what workloads truly belong in the cloud. This might mean cancelling migrations or rolling workloads back. Many of these firms are large enough that they have historically operated their own DCs anyway. Others have simply rented space in places like equinix.

In a lot of ways this makes sense. JPM alone claims to have 50K "technologists". These are the kind of numbers that match or exceed the hyperscalers themselves. Even many of the big hedge funds / asset managers have only gotten bigger, with 1000+ engineers of various sorts on staff.

As others have pointed out, things like big predictable stable workloads and storage are heavily marked up in cloud and you are lighting money on fire at scale if you are already big enough to rent/run your own DC.