729
Old timers know
(sh.itjust.works)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 22 Jun 2024
729 points (98.7% liked)
Programmer Humor
19551 readers
494 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 1 year ago
MODERATORS
Somehow I miss those days. Now you need weeks of training to understand the black magic behind all the build/deployment stuff in whatever cloud provider your company decided to use…
We got our own platform based on kubernetes and cncf stuff and we don't have to care anymore about the metal underneath. AWS? OTC? Azure? Thats just a target parameter, platform does the rest. It's great.
How often do you switch cloud providers that this is even a real rather than a hypothetical benefit? (Compared to the cost of dealing with a much more complicated stack.)
It's not about switching, it's about hosting our services on different platforms at the same time.
I manage a stack like this, we have dedicated hardware running a steady state of backend processing, but scale into AWS if there's a surge in realtime processing needed and we don't have the hardware. We also had an outage in our on prem datacenter once which was expensive for us (I assume an insurance claim was made), but scaling to AWS was almost automatic, and the impact was minimal for a full datacenter outage.
If we wanted to optimize even more, I'm sure we could scale into Azure depending on server costs when spot pricing is higher in AWS. The moral of the story is to not get too locked into any one provider and utilize some of the abstraction layers so that AWS, Azure, etc are just targets that you can shop around for by default, without having to scramble.