"Cloud-first" became a slogan, and slogans make poor architecture decisions. The honest answer to where your systems should run is: it depends on the workload, the rules, and the trade-offs you're willing to make. Here's a way to reason about it.
Start with the constraints, not the preference
Some decisions are made for you. If a regulation or a customer contract requires data to stay in-Kingdom, that narrows the options before cost or convenience enter the picture. Map the hard constraints first — residency, latency to critical systems, and any air-gapping requirements — then optimize within them.
Public cloud: speed and elasticity
Public cloud is usually the fastest way to start and the easiest to scale up and down. You trade some control and can pay more than you expect if workloads aren't right-sized. It suits variable demand and teams that would rather not run infrastructure themselves.
On-premise: control and predictability
Running on your own servers gives you the most control and can be more cost-predictable for steady, heavy workloads. The trade-off is that you own the operational burden — patching, capacity, resilience — and the upfront investment.
In-Kingdom and hybrid: the middle ground
For many organizations in the region the practical answer is in-Kingdom hosting, or a hybrid that keeps sensitive data local while using cloud elasticity elsewhere. Good software should let you deploy the same system as SaaS, in your own cloud, or fully on-premise, so the deployment model follows your rules rather than the other way around.
Decide per workload
- What are the residency and regulatory constraints?
- Is demand steady or variable?
- How sensitive is the data, and who must not see it?
- What latency do critical, connected systems need?
- Do you want to run infrastructure, or have someone run it for you?
Don't pick a deployment model as an ideology. Map your hard constraints, then choose per workload — and favour software that can run as SaaS, private cloud, or on-premise so the choice stays yours.