I personally think multi-cloud is over hyped and the complexity isn’t worth it for most organizations. The apps I am responsible for are one AWS region / 3 AZ and we have sufficient uptime. We could be multi-region but the added cost wasn’t worth the benefit and complexity. Multi-cloud makes zero sense.
Multicloud makes sense once you get to megascale where you have a dedicated team negotiating with CSPs over your discounts. If you can credibly flip a switch and move your multi-million dollar workload to a competitor, you can save big money.
This comes on top of the benefit that architecting for multi-cloud at that scale usually forces you to simplify/rationalize/automate ruthlessly and so is probably beneficial for a "mature" org with lots of cruft anyway.
That said there may only be a few dozen companies in the world where this makes sense. I happen to work for one, but most engineers don't. Even then, this is at the extreme right of the maturity curve, meaning that there is lots of lower-hanging fruit to pick first
Multicloud is just an inevitable reality--the default. The only time I have run into homogenous cloud architectures has been in large organizations and even then I was removed from the multi-cloud concerns because I was focused on a single product/service that was hosted in a single cloud infrastructure.
> Understood. But what if you have a multi-cloud setup or you want to migrate to a different cloud to efficiently use credits?
So yeah, one of the clients we were working with had to move from AWS to GCP (mostly for utilizing cloud credits). The setup was small but the estimated time was nearly 2-3 months. It's really a pain, and I think a lot of organizations don't think of doing it because when they weigh rewards and the effort/time needed, it doesn't make sense.
99% of the time it's just a docker container that connects to a database, an object store and redis.
If we need to move it then we move it... not exactly difficult or time consuming. There are always ways of half moving things too, for example we could move the container deployment to another cloud but keep our build process and object store at the original vendor and so on.
In reality we are not going to be shifting production load between cloud vendors every 2 weeks.
cebert|1 year ago
ElevenLathe|1 year ago
This comes on top of the benefit that architecting for multi-cloud at that scale usually forces you to simplify/rationalize/automate ruthlessly and so is probably beneficial for a "mature" org with lots of cruft anyway.
That said there may only be a few dozen companies in the world where this makes sense. I happen to work for one, but most engineers don't. Even then, this is at the extreme right of the maturity curve, meaning that there is lots of lower-hanging fruit to pick first
datavirtue|1 year ago
Cowsheek|1 year ago
[deleted]
pravanjanc|1 year ago
So yeah, one of the clients we were working with had to move from AWS to GCP (mostly for utilizing cloud credits). The setup was small but the estimated time was nearly 2-3 months. It's really a pain, and I think a lot of organizations don't think of doing it because when they weigh rewards and the effort/time needed, it doesn't make sense.
matt-p|1 year ago
If we need to move it then we move it... not exactly difficult or time consuming. There are always ways of half moving things too, for example we could move the container deployment to another cloud but keep our build process and object store at the original vendor and so on.
In reality we are not going to be shifting production load between cloud vendors every 2 weeks.