Anything but that cloud

"Anything but that cloud."

I asked why.

"Our biggest customer is a giant retailer," he said. "That hyperscaler's parent company is the retailer's biggest competitor. So our customer refuses to do business with anyone who uses that cloud. We use that cloud, we lose our biggest customer. Full stop."

That was the entire conversation about cloud choice. It wasn't a technical preference. It wasn't a pricing optimization. It wasn't a sovereignty concern. It was a single downstream customer, doing a long-running piece of competitive gamesmanship with a specific hyperscaler, and the ripple of that choice landed on my prospect's entire infrastructure strategy.

I’ve thought about that meeting a lot over the years. The shape of the problem kept showing up in other calls.

The cloud decision you made before you needed to

When you pick an application platform, cloud choice rarely feels like a decision. You pick the platform for the developer experience, the preview flow, the framework support. The cloud underneath is an implementation detail somebody else's operations team thinks about. That's mostly fine.

Mostly.

There's a specific business moment where "an implementation detail somebody else thinks about" becomes "the one thing standing between you and a contract." My retailer guy is one version. The other versions show up under different labels. A regulator asks where data is processed. A large customer's procurement team requires deployment in a specific region. A CFO brings down a consolidation mandate to line up cloud spend with an existing committed-use agreement on one of the hyperscalers. An acquisition brings a different cloud into your org that now has to line up with the rest of the stack.

None of these show up in the evaluation spreadsheet when you pick the platform. All of them can block revenue when they show up later.

Why most platforms hand you the answer

The platforms that popularized modern full-stack DX built their abstractions on top of their own infrastructure. That's what makes them feel magic. Push, preview, deploy, scale. It works because the platform operator owns the substrate.

Which also means the platform is the cloud. "Which region?" is a menu the platform operator controls. "Which cloud?" is not on the menu. If that prospect had been on one of those platforms, the conversation would have been short and final. "We don't support running outside our infrastructure." Deal over.

Here's the part that's easy to miss. Most teams never hit this wall until they start selling into a segment that cares. Then the wall moves from invisible to load-bearing overnight.

It's a passport that works in one country. You can have a great life inside that country. The day you need to cross a border is the day you learn which kind of passport you have.

What Upsun does

Upsun deploys the same application, described by the same .upsun/config.yaml, to AWS, Azure, GCP, IBM, or OVH, across dozens of regions. Not with a different configuration per cloud. The same configuration.

When a customer's security team needs you in Europe, it's a regional decision. When a prospect tells you their biggest customer won't work with vendors on one particular cloud, you can pick a different one. When a CFO wants the cloud spend to count against an existing AWS, Azure, Google, or IBM commitment, Upsun is on all four marketplaces, so the answer is yes without rewriting the application.

The capability is multi-cloud deployment with a single declarative configuration, available through the hyperscaler marketplaces your company already buys through. The business capability is a yes, instead of a ninety-day project.

The sentence you weren't expecting

The customers I talk to who need multi-cloud options rarely start the conversation there. They start somewhere else, talking about preview environments or backend runtimes or compliance scope. Multi-cloud comes up later, usually in a throwaway sentence. "Oh, and we have a customer who needs us on the west coast, is that doable?" Or: "we've got a procurement review where they're asking about a specific hyperscaler."

The throwaway sentence is the one that decides whether the deal closes or turns into an eighteen-month engineering project.

My prospect didn't know his biggest customer was going to land in his infrastructure strategy until the day they did. He was lucky. He was evaluating platforms, and we could provide him with options. The fact that his platform choice happened to align with his biggest customer's preferences was, in the most literal sense, an accident.

Most teams don't get to rely on that accident.

A question to sit with

If your largest prospect this quarter asked you to deploy in a specific region, explicitly not in a specific hyperscaler, or on a cloud where their committed spend already lives, how would you answer, and how long would the project take?

If the answer is "we could, it's a simple drop down choice," you're in a good spot. If the answer is "we'll have to replatform," that might not be a crisis today. But it's a constraint you should know about before the customer asks, not after.

The "anything but that cloud" prospect signed with us, for what it's worth. Still servicing his biggest customer, last I heard. The preference has never shifted. What has shifted is that now, a platform that lets you answer "sure, which one" to a cloud question isn't a nice-to-have. It's the difference between a deal and a ninety-day project.

Pick the passport that works in more than one country.

Further reading

• Upsun platform overview
• Upsun multi-cloud and multi-region deployment