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.

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

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 2 points 1 day ago (3 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 day ago* (last edited 1 day 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

load more comments (2 replies)

load more comments (9 replies)