Are rainy days ahead for cloud computing?
bbc.com
bbc.com
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.
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.
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.
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.
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.
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.
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 have no confidence in my ability to configure Postgres on K8s with backups, however.
It all comes down to architecture and design. Many applications aren't designed for the cloud, and of course those systems are costly and painful to run in the cloud.
Cloud will always be cheaper up to a point. I then question why that point needed to occur and if we couldn't find some new way to arrange the problem so that it stays under that point.
I feel like "on-prem is cheaper" is often one of those self-fulfilling prophecies where wanting it to be true makes it become true.
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?
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.
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.
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.