[vasco]

Even with an abstraction layer like kubernetes you still have a lot of duplicate work if you're multi-cloud. Services need to be exposed with load balancers, and those will have different configurations to be setup. Same with any Volumes. And then you have platform updates on both sides, bugs, quirks. plus the maintenance and upkeep of two clouds - two bills to inspect, two account managers to deal with, two sets of permissions and overall account configuration to setup, maintain and audit. Multi-cloud is really a set of requirements that changes the whole game in terms of operational overhead. And we limited our example to kubernetes. I imagine any non-fictional-for-the-sake-of-example company would want to make use of other platform specific tools as you mention.

[onlyrealcuzzo]

I think a lot of this speculation requires inside knowledge of what the DoD's use cases actually are.

Are they doing a lot of compute, a lot of ingestion, a lot of output, and a ton of networking? Are they primarily just doing one of these things?

Who knows?

There's a lot of cases where having multiple clouds could be fine -- maybe even a big benefit. There's also a lot of cases where it could be a major headache.

[Diederich]

> Who knows?

I know a little about it from a previous employer.

Even the narrow slice I saw was all of "a lot of compute, a lot of ingestion, a lot of output, and a ton of networking", and more.

I think that the internal inefficiencies in the DOD datacenters are so enormous that any kind move to something more 'standardized', no matter what company it is, even with all of the artificial overhead, etc, will likely be a big win.

[syshum]

>>DoD's use cases actually are.

We all saw T3, we know it is skynet