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.

[–] rizzothesmall@sh.itjust.works 1 points 1 week ago (2 children)

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.

[–] douglasg14b@lemmy.world 3 points 1 week ago* (last edited 1 week ago)

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

[–] zalgotext@sh.itjust.works 2 points 1 week ago

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.