What I Got Wrong About Cloud Choice, and What I Ask Now

By Eric Kalin, Alpharetta, GA

A Belief I Held for Years

For a long time, I treated cloud choice as a loyalty decision. Which provider is the company "on." Which stack does IT support. Which vendor gets the multi-year commitment. I spent years inside AWS, IBM, and Microsoft Azure, and in every one of those rooms, the conversation started the same way: pick a side, then build around it.

That framing made sense when applications and data mostly lived in one place. It stopped making sense once companies had real workloads spread across AWS, Azure, and Google Cloud, often for good reasons that had nothing to do with indecision. A team picked Azure for its developer tools. Another picked AWS for its AI services. A third stayed on Google Cloud for analytics. Meanwhile, the database underneath all of it, the part running the mission-critical systems, was often Oracle, sitting somewhere else entirely.

I used to see that as a problem to fix. Now I see it as a starting point to design around.

What Changed My Mind

The shift came from watching how much latency and cost gets created just moving data back and forth between an application and a database that live in different clouds. Every cross-cloud call adds delay. Every transfer adds expense. None of it adds value for the customer.

Oracle's multicloud approach solves this in a specific way: it runs Oracle's Exadata-based database services inside AWS, Azure, and Google Cloud data centers themselves, through Oracle AI Database@AWS, @Azure, and @Google Cloud. An application running in Azure can reach an Oracle database sitting nearby in that same environment, instead of reaching across the internet to a separate cloud entirely.

That is a small architectural fact with a large practical consequence. The company keeps its applications, its AI tools, its analytics and developer tools right where they already are. It keeps using Oracle Database with the same features, operations, and support it has always had. It can still connect to services like Amazon Bedrock, Azure AI, or Google Vertex AI and BigQuery. And it can still use Oracle Cloud Infrastructure directly where that is genuinely the better fit, for integrations, connectivity, disaster recovery, or Oracle SaaS.

None of that requires picking a side.

What I Do Now

I stopped asking "which cloud is this company on." I ask where the applications already live, and whether the database needs to be closer to them.

That question surfaces the real motivations behind a multicloud decision, and they are rarely about avoiding lock-in. Most of the time it is one of these:

• Protecting an existing investment in AWS, Azure, or Google Cloud without forcing a full move to OCI.
• Getting better performance by keeping the app and the database in the same environment.
• Avoiding a rebuild of database operations and tooling across every environment the company runs in.
• Keeping Oracle as the core data layer while using whatever AI or analytics service the preferred provider does best.
• Modernizing in steps, rather than in one disruptive migration that risks the whole system at once.
• Meeting data residency and compliance requirements with more consistent governance across environments.
• Reducing the operational load of running different database setups in every cloud.
• Cutting the cost of moving data and duplicating infrastructure. Savings vary a lot by architecture and by contract, but the direction is the same.

Once those motivations are on the table, the cloud conversation stops being about allegiance and starts being about where the business actually gets value. That is the real difference between a data platform and a data strategy. One sits underneath the business. The other moves it forward.

The Part I Still Push Back On

I do not tell people multicloud makes anything simpler by default, because it does not. Running a database close to an application in another provider's environment still requires clear ownership of who manages what, a real identity and security design, networking that someone actually monitors, and a cost governance plan, not just a cost hope. It also needs an exit strategy, because every architecture decision should have one.

Where I get excited is when the database is genuinely central to the business and the applications are already anchored somewhere else. That is not a rare setup. It describes most enterprises I have worked with over the past twenty five years. The question was never whether to be multicloud. Most companies already are, whether they planned for it or not. The question is whether the data platform underneath that reality is working for the business or just sitting there, waiting to be asked to do more.