Remember when the Internet was supposed to be decentralised for resilience?
this post was submitted on 20 Oct 2025
57 points (100.0% liked)
Programmer Humor
27182 readers
1072 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
No, sorry, I’m not that old :P
Remember: you're never too young to have a Vietnam flashback!
Yes. Then these assholes came along...
The cloud is just someone else's computer. And that computer is busy printing AI videos of the President pooping out of a fighter jet, so now your files are inaccessible
Can you imagine this sentence 1 year ago much less 5 years ago?
One year ago? Easily.
Five years ago? Depends on whether I was visiting 4chan at the moment.
The President of course being a convicted felon and rapist, Donald J Trump.
That's convicted felon, rapist and pedophile, Donald J Trump, to you, mr. Twopi.
If you properly divide your instances between providers and regions and use load balancing which uses a corum of 3 availability model then it can be zero downtime pretty fairly guaranteed.
People be cheap and easy tho, so 🤷♂️
Yup. And I think I'll add:
What do you mean we've blown our yearly budget in the first month.
Screw the compute budget, the tripled team size without shipping any more features is a bigger problem here.
I've seen the opposite. "Oh, you moved your app to the cloud and rebuilt it to be full cicd and self healing? Cool. Your team of 15 is now 3."
I'm not sure if you are referring to the same thread.
I'm talking about the effort to build multi region and multi cloud applications, which is incredibly difficult to pull off well. And presents seemingly endless challenges.
Not the effort to move to the cloud.
Dividing between providers is not what people would be doing if the resilience of cloud services were as is being memed about.
Doing so is phenomenally expensive.
Doing so is phenomenally expensive.
It's demonstrably little more expensive than running more instances on the same provider. I only say -little- because there is a marginal administrative overhead.
It's phenomenally expensive from a practical standpoint, it takes an immense amount of engineering and devops effort to make this work for non trivial production applications.
It's egregiously expensive from an engineering standpoint. And most definitely more expensive from a cloud bill standpoint as well.
We're doing this right now with a non trivial production application built for this, and it's incredibly difficult to do right. It affects EVERYTHING, from the ground up. The level of standardization and governance that goes into just making things stable across many teams takes an entire team to make possible.
In my experience using containers has removed requirements for additional engineering cost to deploy between providers because a container is the same wherever it's running, and all the providers will offer container hosting, and most offer cluster private networking.
Deployment is simplified using something like octopus which can deploy to many destinations in a blue-green fashion with easy rollback.
Yes, containers make your application logic work.
That's the lowest hanging fruit on the tree.
Let's talk about persistence logic, fail forwards, data synchronization, and write queues next.
Let's also talk about cloud provider network egress costs.
Let's also talk about specific service dependencies that may not be replicatable across clouds, or even regions.
Oh, also provider specific deployment nuances, I AM differences, networking differences....etc
Containers are nice, but don't really cover things like firewalls, network configuration, identity management, and a whole host of other things, the configuration of which varies between providers.
I mean, technically, you could containerize all the elements you need. Firewall, load balancers, identity management, etc. but at that point, you are creating your companies own version of the cloud services that are generally one of the big draws to the cloud already since you aren't directly developing and maintaining those systems anymore. Once you have made "aws lite" in container form, you can then deploy that directly to the compute instances on any cloud provider. But now you need to maintain everything like you were running on prem (i.e. more developers and network engineers again) all while paying a pretty penny to multiple cloud providers and now that your infrastructure containers need to run 24/7 instead of only having your compute resources being ran on demand your costs will skyrocket so at that point why not just move back to on prem hosting.
I remember SLAs including 'five nines' ensurances. That meant 99.999% uptime or an allowance of 26 seconds of downtime a month. That would be unheard of nowadays because no cloud provider can ensure that they will have that uptime.
Amazon has so much redundancy built into EC2 that I genuinely thought they’d be able to avoid this.
I may be mistaken, but I really could've sworn that a lot of the really strict SLA guarantees Amazon gives assume you are doing things across availability zones and/or regions. Like they're saying "we guarantee 99.999% of uptime across regions" sort of thing. Take this with a grain of salt, it's something I only half remember from a long time ago.