[derefr]

> We put databases on Oracle that should be handled by Postgres or MariaDB since DoD prefers Oracle.

I mean, if you’ve already budgeted the CapEx for some additional Oracle licenses, the OpEx efficiencies of having unified tooling and a unified ops doctrine are no joke.

I haven’t worked with an Oracle DBMS, but I think this is analogous: I’d sure hate to have to manage a cloud infrastructure where parts were on AWS, parts on GCP, and parts on Azure. Sure, there are generic tools that treat all three the same, or over-layers like K8s that don’t care about substrate—but what if the projects on each platform were taking advantage of that platform’s specialties? What if I was using SNS on AWS, or BigQuery on GCP?

To bring that back through the analogy, what if our Oracle projects were tuned using Oracle-specific query-planner hints, while our Postgres projects did their ETL using PG-specific Foreign Data Wrapper connectors?

In both cases, the only real solution is hiring and retaining O(N) specialized ops headcount, one team for each stack. And that cost gets a lot higher than just paying for another darn Oracle license.

[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

[awinder]

I'm sure that these deals are complicated at the size they're going at and maybe laymens pricing models just get tossed aside, but one of the biggest things I spend time on in cloud architecting is all around data ingress/egress in order to control costs. I simply don't understand how it's possible to go multi-cloud and control those costs, I feel like you'd either blow costs out not caring, or blow costs out throwing engineers at very complex solutions.