What Is Sovereign Enough for You?

What Is Sovereign Enough for You?

Digital sovereignty has become one of the defining topics for governments, regulators, and organizations that operate with sensitive data. Everyone wants to know how much control they truly have over their cloud environment. But the question that should be asked first is: what is sovereign enough for you? Because sovereignty is not a binary choice. It comes in different layers, with different levels of autonomy, control, and dependencies on global vendors like Oracle.

Oracle has designed its portfolio with exactly this variety in mind. Not every government or regulated organization needs or wants a fully isolated environment. Some are fine with Oracle managing the service end-to-end, while others require absolute control down to operations and staffing. Let’s walk through the different operating models and connectivity dependencies, so you can decide where your needs for sovereignty fit in.

1) Building a Full Sovereign Cloud With Local Personnel

At the very top of the sovereignty spectrum sits the option to build a national or regional sovereign cloud that is completely separated from Oracle’s global public regions (separate realms). These environments are staffed and operated by locally cleared personnel, and the legal entity running the cloud sits within the country or region itself.

A graphic depicting OCI realms with separation.

Examples today are the UK Government & Defence Cloud and the Oracle EU Sovereign Cloud. Here, sovereignty is not only a technical matter but also an organizational one. Governments get the guarantee that operations, compliance, and support are entirely bound by local regulations and cannot be accessed or influenced from outside.

Full operational autonomy by design. The control plane, the data plane, and the people managing the systems are all local. Oracle provides the technology, but the control and day-to-day operations are delegated to the sovereign entity.

From a policy-maker’s perspective, this is the gold standard. Independence from foreign jurisdictions, complete local control of staff, audits, and processes, and guaranteed resilience even without global connectivity. It comes with the highest costs and commitments, but also the strongest assurance.

2) OCI Dedicated Region

OCI Dedicated Region is a full public cloud region deployed directly into a customer’s data center. It includes all Oracle Cloud services, runs on dedicated infrastructure, and provides the same service catalog as Oracle’s global regions.

Diagram of OCI in a dedicated region, description below

From a sovereignty perspective, this model ensures that data never leaves the country if the customer so desires. The region is connected to Oracle’s global backbone (still separate realms), which allows it to remain consistent in updates, operations, and service integration. However, the control plane still depends on Oracle. Updates, patches, and lifecycle management (~15’000 changes per month) are performed by Oracle engineers, who operate under strict contracts and compliance rules.

Examples in practice:

  • Vodafone has deployed six Dedicated Regions across Europe (Ireland, Italy, Germany) to modernize core systems, ensure compliance, and keep data inside the EU while leveraging Oracle’s global innovation cycle.

  • Avaloq, the Swiss banking software leader, runs its own Dedicated Region to provide compliant, modern infrastructure for financial services, combining local control of data with Oracle’s managed operations.

Dedicated Region is often sovereign enough: sensitive workloads stay in-country, under national regulation, while Oracle ensures consistency, security, and ongoing modernization. Operational autonomy is not fully local, but the trade-off is efficiency and scale.

3) Oracle Alloy

Oracle Alloy takes sovereignty one step further by introducing a cloud-as-a-service model for partners. Service providers, system integrators, or governments can license Oracle’s technology stack and operate their own branded cloud. Alloy provides the full OCI service catalog but allows the partner to take over customer relationships, billing, compliance, and front-line operations.

Becoming an Oracle Alloy partner  diagram, description below

This is highly attractive for countries and organizations that want to build their own cloud business or national platforms without developing hyperscale technology themselves. Still, Alloy maintains a technical tether to Oracle. While the partner gains control over operations and branding, Oracle remains in charge of certain aspects of lifecycle management, support escalation (tier 2 and tier 3 support), and roadmap alignment.

Examples in practice:

  • In Saudi Arabia, telecom leader stc is using Alloy to deliver sovereign cloud services that meet local data residency and regulatory requirements.

  • In Japan, Fujitsu uses Oracle Alloy to provide sovereign cloud and AI capabilities tailored to Japanese compliance needs.

  • In Italy, the Polo Strategico Nazionale (PSN) leverages Alloy as part of its managed public cloud offering to deliver secure and compliant cloud services to public administrations.

Alloy strikes a strong balance: It empowers local ecosystems to run a nationally branded sovereign cloud, keeping control of data and compliance, while Oracle provides the innovation foundation. It is not full independence, but it delivers sovereignty in practice for many use cases.

4) Oracle Compute Cloud@Customer

Oracle Compute Cloud@Customer (C3) is a private cloud appliance that delivers OCI services inside your data center. It is ideal for customers who want cloud elasticity and API compatibility with OCI, but who also need workloads to run locally due to latency, compliance, or data residency requirements.

However, the control plane is still managed by Oracle (in a public OCI region or connected to the EU Sovereign Cloud). This means patching, upgrades, and critical operations are carried out by Oracle teams, even though the infrastructure is located in your facility. Connectivity back to Oracle is also required for normal lifecycle operations.

An additional strength of C3 is its seamless integration with OCI Dedicated Region. Customers can connect their local C3 instances to their Dedicated Region, effectively combining on-premises elasticity with the scale and service catalog of a full cloud region running inside their country. This creates a flexible architecture where workloads can be placed optimally on C3 for local control and performance, or on Dedicated Region for broader cloud capabilities.

Oracle Compute Cloud@Customer key capabilities

This model is a pragmatic compromise. It guarantees data sovereignty by keeping workloads in-country, but governments or regulated organizations don’t need to staff or manage the complexity of lifecycle operations. With the option to connect to a Dedicated Region, C3 also opens the door to a multi-layer sovereign cloud strategy, blending local control with the breadth of a national-scale cloud.

5) Oracle Cloud Isolated Region (OCIR)

Oracle Cloud Isolated Region (OCIR) is a specialized deployment model designed for environments that require enhanced security, autonomy, and in-country governance at national or organizational scale. Like a Dedicated Region, it is a full OCI cloud region deployed on-premises, but it is operated in a more restricted and isolated mode, with minimized dependency on Oracle’s global backbone.

Oracle Cloud Isolated Region

Example in practice: Singapore’s Defence Science and Technology Agency (DSTA) has selected OCIR to support the Ministry of Defence (MINDEF) and the Singapore Armed Forces (SAF). The deployment provides an air-gapped, sovereign cloud with high-performance compute and AI capabilities to strengthen C4 (Command, Control, Communications, and Computers) systems. It ensures secure operations, scalability, and rapid decision-making, all within a fully national framework.

OCIR is particularly suited to government ministries, defense, or intelligence organizations that want a nationally hosted cloud hub with strong autonomy, while still retaining the scalability and service richness of a hyperscale platform.

OCIR represents a strategic anchor, providing a sovereign cloud backbone for an entire country or authority that combines national-scale control with the innovation and reliability of Oracle Cloud.

6) Oracle Compute Cloud@Customer Isolated (C3I)

Oracle Compute Cloud@Customer Isolated (C3I) is the solution for organizations that need the highest degree of operational autonomy without running a full sovereign cloud program.

C3I is deployed into a customer’s data center and runs in an air-gapped configuration. The control plane is hosted locally and does not rely on Oracle’s global backbone. This means the customer or the designated authority is in charge of lifecycle operations, updates, and connectivity policies. Oracle provides the technology stack and ensures that the platform can evolve, but operations and control are fully handed to the customer/partner.

Scenario for defense organizations: Imagine a defense ministry operating an Oracle Cloud Isolated Region (OCIR) as its central sovereign cloud hub. Non-sensitive workloads such as HR, logistics, or training could run on regular C3 instances connected to OCIR’s control plane. At the same time, highly sensitive or tactical workloads, such as battlefield data analysis, mission planning, or classified operations, could be deployed on C3I instances. These isolated instances would be managed by local defense teams in the field, operating autonomously even in disconnected or hostile environments. This dual approach allows governments to combine centralized governance through OCIR with operational independence in mission-critical scenarios.

Oracle Compute Cloud@Customer Isolated

C3I represents the pinnacle of autonomy: The ability to maintain full local control for sensitive workloads while integrating into a broader sovereign cloud architecture anchored by OCIR.

Where Do You Stand on the Spectrum?

When thinking about sovereignty, it is essential to recognize that not every organization needs the same level of control. For some, a Dedicated Region is already sovereign enough, as it keeps all data within national borders while still benefiting from Oracle’s global expertise. For others, Alloy provides the right balance of local branding, compliance, and ecosystem building. For governments requiring national-scale autonomy, OCIR acts as a sovereign cloud hub. And for those with the most demanding tactical requirements, C3I ensures full local independence.

So the question remains: What is sovereign enough for you? The answer depends on your data sensitivity, regulatory environment, budget and strategic goals. Oracle has built a portfolio that allows you to choose. The challenge is to define your threshold and then pick the model that aligns with it.

Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Disclaimer: This article reflects my personal opinion and not that of my employer.

The discussion around a Swiss Government Cloud (SGC) has gained significant momentum in recent months. Digital sovereignty has become a political and technological necessity with immediate relevance. Government, politics, and industry are increasingly asking how a national cloud infrastructure could look. This debate is not just about technology, but also about governance, funding, and the ability to innovate.

Today’s starting point is relatively homogeneous. A significant portion of Switzerland’s public sector IT infrastructure still relies on VMware. This setup is stable but not designed for the future. When we talk about the Swiss Government Cloud, the real question is how this landscape evolves from pragmatic use of the public cloud to the creation of a fully sovereign cloud, operated under Swiss control.

For clarity: I use the word “component” (Stufe), in line with the Federal Council’s report, to describe the different maturity levels and deployment models.

A Note on the Federal Council’s Definition of Digital Sovereignty

According to the official report, digital sovereignty includes:

  • Data and information sovereignty: Full control over how data is collected, stored, processed, and shared.

  • Operational autonomy: The ability of the Federal Office of Information Technology (FOITT) to run systems with its own staff for extended periods, without external partners.

  • Jurisdiction and governance: Ensuring that Swiss law, not foreign regulation, defines control and access.

This definition is crucial when assessing whether a cloud model is “sovereign enough.”

Component 1 – Public Clouds Standard

The first component describes the use of the public cloud in its standard form. Data can be stored anywhere in the world, but not necessarily in Switzerland. Hyperscalers such as AWS, Microsoft Azure, or Oracle Cloud Infrastructure (OCI) offer virtually unlimited scalability, the highest pace of innovation, and a vast portfolio of services.

Amazon Web Services (AWS) is the broadest platform by far, providing access to an almost endless variety of services and already powering workloads from MeteoSwiss.

Microsoft Azure integrates deeply with Microsoft environments, making it especially attractive for administrations that are already heavily invested in Microsoft 365 and MS Teams. This ecosystem makes Azure a natural extension for many public sector IT landscapes.

Oracle Cloud Infrastructure (OCI), on the other hand, emphasizes efficiency and infrastructure, particularly for databases, and is often more transparent and predictable in terms of cost.

However, component 1 must be seen as an exception. For sovereign and compliant workloads, there is little reason to rely on a global public cloud without local residency or control. This component should not play a meaningful role, except in cases of experimental or non-critical workloads.

And if there really is a need for workloads to run outside of Switzerland, I would recommend using alternatives like the Oracle EU Sovereign Cloud instead of a regular public region, as it offers stricter compliance, governance, and isolation for European customers.

Component 2a – Public Clouds+

Here, hyperscalers offer public clouds with Swiss data residency, combined with additional technical restrictions to improve sovereignty and governance.

AWS, Azure, and Oracle already operate cloud regions in Switzerland today. They promise that data will not leave the country, often combined with features such as tenant isolation or extra encryption layers.

The advantage is clear. Administrations can leverage hyperscaler innovation while meeting legal requirements for data residency.

Component 2b – Public Cloud Stretched Into FOITT Data Centers

This component goes a step further. Here, the public cloud is stretched directly into the local data centers. In practice, this means solutions like AWS Outposts, Azure Local (formerly Azure Stack), Oracle Exadata & Compute Cloud@Customer (C3), or Google Distributed Cloud deploy their infrastructure physically inside FOITT facilities.

Diagram showing an Outpost deployed in a customer data center and connected back to its anchor AZ and parent Region

This creates a hybrid cloud. APIs and management remain identical to the public cloud, while data is hosted directly by the Swiss government. For critical systems that need cloud benefits but under strict sovereignty (which differs between solutions), this is an attractive compromise.

The vendors differ significantly:

Costs and operations are predictable since most of these models are subscription-based.

Component 3 – Federally Owned Private Cloud Standard

Not every path to the Swiss Government Cloud requires a leap into hyperscalers. In many cases, continuing with VMware (Broadcom) represents the least disruptive option, providing the fastest and lowest-risk migration route. It lets institutions build on existing infrastructure and leverage known tools and expertise.

Still, the cloud dependency challenge isn’t exclusive to hyperscalers. Relying solely on VMware also creates a dependency. Whether with VMware or a hyperscaler, dependency remains dependency and requires careful planning.

Another option is Nutanix, which offers a modern hybrid multi-cloud solution with its AHV hypervisor. However, migrating from VMware to AHV is in practice as complex as moving to another public cloud. You need to replatform, retrain staff, and become experts again.

Hybrid Cloud Management diagram

Both VMware and Nutanix offer valid hybrid strategies:

  • VMware: Minimal disruption, continuity, familiarity, low migration risk. Can run VMware Cloud Foundation (VCF) on AWS, Azure, Google Cloud and OCI.

  • Nutanix: Flexibility and hybrid multi-cloud potential, but migration is similar to changing cloud providers.

Crucially, changing platforms or introducing a new cloud is harder than it looks. Organizations are built around years of tailored tooling, integrations, automation, security frameworks, governance policies, and operational familiarity. Adding or replacing another cloud often multiplies complexity rather than reduces it.

Gartner Magic Quadrant for_Distributed_Hybrid_Infrastructure

Source: https://www.oracle.com/uk/cloud/distributed-cloud/gartner-leadership-report/ 

But sometimes it is just about costs, new requirements, or new partnerships, which result in a big platform change. Let’s see how the Leaders Magic Quadrant for “Distributed Hybrid Infrastructure” changes in the coming weeks or months.

Why Not Host A “Private Public Cloud” To Combine Components 2 and 3?

This possibility (let’s call with component 3.5) goes beyond the traditional framework of the Federal Council. In my view, a “private public cloud” represents the convergence of public cloud innovation with private cloud sovereignty.

“The hardware needed to build on-premises solutions should therefore be obtained through a ‘pay as you use’ model rather than purchased. A strong increase in data volumes is expected across all components.”

Source: https://www.fedlex.admin.ch/eli/fga/2024/1408/de#lvl_2/lvl_2.4 (translated from German)

Solutions like OCI Dedicated Region or Oracle Alloy can deliver the entire Oracle Cloud stack– IaaS, PaaS, databases, analytics – on Swiss soil. Unlike AWS Outposts, Azure Local, these solutions are not coming with a limited set of cloud services, but are identical to a full public cloud region with all cloud services, only hosted and operated locally in a customer’s data center.

OCI Dedicated Region Overview

Additionally, Oracle offers a compelling hybrid path. With OCVS (Oracle Cloud VMware Solution) on OCI Dedicated Region or Alloy, organizations can lift-and-shift VMware workloads unchanged to this local public cloud based on Oracle Cloud Infrastructure, then gradually modernize selected applications using Oracle’s PaaS services like databases, analytics, or AI.

OCI Dedicated Region and OCVS

This “lift-and-modernize” journey helps balance risk and innovation while ensuring continuous operational stability.

And this makes component 3.5 unique. It provides the same public-cloud experience (continuous updates, innovation pace; 300-500 changes per day, 10’000-15’000 per month) but under sovereign control. With Alloy, the FOITT could even act as a Cloud Service Provider for cantons, municipalities, and hospitals, creating a federated model without each canton building its own cloud.

Real-world Swiss example: Avaloq was the first customer in Switzerland to deploy an OCI Dedicated Region, enabling it to migrate clients and offer cloud services to other banks in Switzerland. This shows how a private public cloud can serve highly regulated industries while keeping data and operations in-country.

In this model:

  • Component 2b becomes redundant: Why stretch a public cloud into FOITT data centers if a full cloud can already run there?

  • Component 2 can also be partly obsolete: At least for workloads running a local OCI Dedicated Region (or Alloy) deployment, there’s no need for parallel deployments in public regions, since everything can run sovereignly on a local dedicated OCI region in Switzerland (while workloads from MeteoSwiss on AWS remain in component 2).

A private public cloud thus merges sovereignty with innovation while reducing the need for parallel cloud deployments.

Another Possibility – Combine Capabilities From A Private Public Cloud With Component 2b

Another possibility could be to combine elements of components 3.5 and 2b into a federated architecture: Using OCI Dedicated Region or Oracle Alloy as the central control plane in Switzerland, while extending the ecosystem with Oracle Compute Cloud@Customer (C3) for satellite or edge use cases.

Oracle Compute Cloud@Customer – Wichtige Funktionen

This creates a hub-and-spoke model:

  • The Dedicated Region or Alloy in Switzerland acts as the sovereign hub for governance and innovation.

  • C3 appliances extend cloud services into distributed or remote locations, tightly integrated but optimized for local autonomy.

A practical example would be Swiss embassies around the world. Each embassy could host a lightweight C3 edge environment, connected securely back to the central sovereign infrastructure in Switzerland. This ensures local applications run reliably, even with intermittent connectivity, while remaining part of the overall sovereign cloud ecosystem.

By combining these capabilities, the FOITT could:

  • Use component 2b’s distributed deployment model (cloud stretched into local facilities)

  • Leverage component 3.5’s VMware continuity path with OCVS for easy migrations

  • Rely on component 3.5’s sovereignty and innovation model (private public cloud with full cloud parity)

This blended approach would allow Switzerland to centralize sovereignty while extending it globally to wherever Swiss institutions operate.

What If A Private Public Cloud Isn’t Sovereign Enough?

It is possible that policymakers or regulators could conclude that solutions such as OCI Dedicated Region or Oracle Alloy are not “sovereign enough”, given that their operational model still involves vendor-managed updates and tier-2/3 support from Oracle.

In such a scenario, the BIT would have fallback options:

Maintain a reduced local VMware footprint: BIT could continue to run a smaller, fully local VMware infrastructure that is managed entirely by Swiss staff. This would not deliver the breadth of services or pace of innovation of a hyperscale-based sovereign model, but it would provide the maximum possible operational autonomy and align closely with Switzerland’s definition of sovereignty.

Leverage component 4 from the FDJP: Using the existing “Secure Private Cloud” (SPC) from the Federal Department of Justice and Police (FDJP). But I am not sure if the FDJP wants to become a cloud service provider for other departments.

That said, these fallback strategies don’t necessarily exclude the use of OCI. Dedicated Region or Alloy could co-exist with a smaller VMware footprint, giving the FOITT both innovation and control. Alternatively, Oracle could adapt its operating model to meet Swiss sovereignty requirements – for example, by transferring more operational responsibility (tier-2 support) to certified Swiss staff.

This highlights the core dilemma: The closer Switzerland moves to pure operational sovereignty, the more it risks losing access to the innovation and agility that modern cloud architectures bring. Conversely, models like Dedicated Region or Alloy can deliver a full public cloud experience on Swiss soil, but they require acceptance that some operational layers remain tied to the vendor.

Ultimately, the Swiss Government Cloud must strike a balance between autonomy and innovation, and the decision about what “sovereign enough” means will shape the entire strategy.

Conclusion

The Swiss Government Cloud will not be a matter of choosing one single path. A hybrid approach is realistic: Public cloud for agility and non-critical workloads, stretched models for sensitive workloads, VMware or Nutanix for hybrid continuity, sovereign or “private public cloud” infrastructures for maximum control, and federated extensions for edge cases.

But it is important to be clear: Hybrid cloud or even hybrid multi-cloud does not automatically mean sovereign. What it really means is that a sovereign cloud must co-exist with other clouds – public or private.

To make this work, Switzerland (and each organization within it) must clearly define what sovereignty means in practice. Is it about data and information sovereignty? Is it really about operational autonomy? Or about jurisdiction and governance?

Only with such a definition can a sovereign cloud strategy deliver on its promise, especially when it comes to on-premises infrastructure, where control, operations, and responsibilities need to be crystal clear.

PS: Of course, the SGC is about much more than infrastructure. The Federal Council’s plan also touches networking, cybersecurity, automation and operations, commercial models, as well as training, consulting, and governance. In this article, I deliberately zoomed in on the infrastructure side, because it’s already big, complex, and critical enough to deserve its own discussion. And just imagine sitting on the other side, having to go through all the answers of the upcoming tender. Not an easy task.

Cloud Exit Triggers – What Happens When the Exit Button Isn’t Optional?

Cloud Exit Triggers – What Happens When the Exit Button Isn’t Optional?

It is becoming clearer by the day: geopolitical realities are forcing CIOs and regulators to revisit their cloud strategy, not just for performance or innovation, but for continuity, legal control, and sovereignty. The past few years have been a story of cloud-first, then cloud-smart, and then about cloud repatriation. The next chapter is about cloud control. And with the growing influence of U.S. legislation like the CLOUD Act, many in Europe’s regulated sectors are starting to ask: what happens when we need to exit?

Now add another layer: what if your cloud provider is still technically and legally subject to a foreign jurisdiction, even when the cloud lives in your own country and your own data centers?

That’s the fundamental tension/question with models like Oracle Alloy (or OCI Dedicated Region), a promising construct that brings full public cloud capabilities into local hands, but with a control plane and infrastructure still operated by Oracle itself. So what if something changes (for example, politically) and you need to exit?

Let’s explore what that exit could look like in practice, and whether Oracle’s broader portfolio provides a path forward for such a scenario.

Local Control – How Far Does Oracle Alloy Really Go?

Oracle Alloy introduces a compelling model for delivering public cloud services with local control. For providers like cloud13 (that’s the fictitious company I am using for this article), this means the full OCI service catalogue can run under the cloud13 brand, with customer relationships, onboarding, and support all handled locally. Critically, the Alloy control plane itself is deployed on-premises in cloud13’s own data center, not remotely managed from an Oracle facility. This on-site architecture ensures that operational control, including provisioning, monitoring, and lifecycle management, remains firmly within Swiss borders.

But while the infrastructure and control plane are physically hosted and operated by cloud13, Oracle still provides and maintains the software stack. The source code, system updates, telemetry architecture, and core service frameworks are still Oracle-owned IP, and subject to Oracle’s global governance and legal obligations. 

Please note: Even in disconnected Alloy scenarios, update mechanisms or security patches may require periodic Oracle coordination. Understanding how these touchpoints are logged and audited will be crucial in high-compliance sectors.

Oracle Alloy

So, while cloud13 ensures data residency, operational proximity, and sovereign service branding, the legal perimeter around the software stack itself may still inherit external jurisdictional influence.

For some sectors, this hybrid control model strikes the right balance. But for others, particularly those anticipating geopolitical triggers (even highly unlikely!) or regulatory shifts, it raises a question: what if you need to exit Alloy entirely?

What a Cloud Exit Really Costs – From Oracle to Anywhere

Let’s be honest and realistic: moving cleanly from Oracle Cloud Infrastructure (OCI) to a hyperscaler like AWS or Azure is anything but simple. OCI’s services are deeply intertwined. If you are running Oracle-native PaaS or database services, you are looking at significant rework – sometimes a full rebuild – to get those workloads running smoothly in a different cloud ecosystem.

On top of that, data egress fees can quickly pile up, and when you add the cost and time of re-certification, adapting security policies, and retraining your teams on new tools, the exit suddenly becomes expensive and drawn out.

That brings us to the critical question: if you are already running workloads in Oracle Alloy, what are your realistic exit paths, especially on-premises?

Going the VMware, Nutanix, or Platform9 route doesn’t solve the problem much either. Sure, they offer a familiar infrastructure layer, but they don’t come close to the breadth of integrated platform services Oracle provides. Every native service dependency you have will need to be rebuilt or replaced.

Then There’s Azure Local and Google Distributed Cloud

Microsoft and Google both offer sovereign cloud variants that come in connected and disconnected flavours.

While Azure Local and Google Distributed Cloud are potential alternatives, they behave much like public cloud platforms. If your workloads already live in Azure or Google Cloud, these services might offer a regulatory bridge. But if you are not already in those ecosystems, and like in our case, are migrating from an Oracle-based platform, you are still facing a full cloud migration.

Yes, that’s rebuilding infrastructure, reconfiguring services, and potentially rearchitecting dozens or even hundreds of applications.

And it’s not just about code. Legacy apps often depend on specific runtimes, custom integrations, or licensed software that doesn’t map easily into a new stack. Even containerised workloads need careful redesign to match new orchestration, security, and networking models. Multiply that across your application estate, and you are no longer talking about a pivot.

You are talking about a multi-year transformation programme.

That’s before you even consider the physical reality. To run such workloads locally, you would need enough data center space (image repatriation or a dual-vendor strategy), power, cooling, network integration, and a team that can operate it all at scale. These alternatives aren’t just expensive to build. They also require a mature operational model and skills that most enterprises simply don’t have ready.

One cloud is already challenging enough. Now, imagine a multi-cloud setup and pressure to migrate.

From Alloy to Oracle Compute Cloud@Customer Isolated – An Exit Without Downtime

Oracle’s architecture allows customers to move their cloud workloads from Alloy into an Oracle Compute Cloud@Customer environment (known as C3I), with minimal disruption. Because these environments use the exact same software stack and APIs as the public OCI cloud, workloads don’t need to be rewritten or restructured. You maintain the same database services, the same networking constructs, and the same automation frameworks.

This makes the transition more of a relocation than a rebuild. Everything stays intact – your code, your security model, your SLAs. The only thing that changes is the control boundary. In the case of C3I, Oracle has no remote access. All infrastructure remains physically isolated, and operational authority rests entirely with the customer.

Oracle Compute Cloud@Customer Isolated

By contrast, shifting to another public or private cloud requires rebuilding and retesting. And while VMware or similar platforms might accommodate general-purpose workloads, they still lack the cloud experience.

Note: Oracle Compute Cloud@Customer offers OCI’s full IaaS and a subset of PaaS services.

While C3I doesn’t yet deliver the full OCI portfolio, it includes essential services like Oracle Linux, Autonomous Database, Vault, IAM, and Observability & Management, making it viable for most regulated use cases.

Alloy as a Strategic Starting Point

So, should cloud13 even start with Alloy?

That depends on the intended path. For some, Alloy is a fast way to enter the market, leveraging OCI’s full capabilities with local branding and customer intimacy. But it should never be a one-way road. The exit path, no matter what the destination is, must be designed, validated, and ready before geopolitical conditions force a decision.

This isn’t a question of paranoia. It’s good cloud design. You want to have an answer for the regulators. You want to be prepared and feel safe.

The customer experience must remain seamless. And when required, ideally, the workloads must move within the same cloud logic, same automation, and same/some platform services.

Could VMware Be Enough?

For some customers, VMware might remain a logical choice, particularly where traditional applications and operational familiarity dominate. It enables a high degree of portability, and for infrastructure-led workloads, it’s an acceptable solution. But VMware environments lack integrated PaaS. You don’t get Autonomous DB. You get limited monitoring, logging, or modern analytics services. You don’t get out-of-the-box identity federation or application delivery pipelines.

Ultimately, you are buying infrastructure, not a cloud.

The Sovereign Stack – C3I and Exadata Cloud@Customer

That’s why Oracle’s C3I, especially when paired with Exadata Cloud@Customer (ExaCC) or a future isolated variant of it, offers a more complete solution. It delivers the performance, manageability, and sovereignty that today’s regulated industries demand. It lets you operate a true cloud on your own terms – local, isolated, yet fully integrated with Oracle’s broader cloud ecosystem.

C3I may not yet fit every use case. Its scale and deployment model must match customer expectations. But for highly regulated workloads, and especially for organizations planning for long-term legal and geopolitical shifts, it represents the most strategic exit vector available.

Final Thought

Cloud exit should never be a last-minute decision. In an IT landscape where laws, alliances, and risks shift quickly, exit planning is not a sign of failure. It’s considered a mark of maturity!

Oracle’s unique ecosystem, from Alloy to C3I, is one of the few that lets you build with that maturity from day one.

Whether you are planning a sovereign cloud, or are already deep into a regulated workload strategy, now is the time to assess exit options before they are needed. Make exit architecture part of your initial cloud blueprint.

Why Emulating the Cloud Isn’t the Same as Being One

Why Emulating the Cloud Isn’t the Same as Being One

It’s easy to mistake progress for innovation. VMware Cloud Foundation 9.0 (VCF) introduces long-awaited features like VPC-style networking, developer-centric automation, and bundled services. But let’s be honest: this is not the future of cloud. This is infrastructure catching up to where the public cloud world already was ten years ago.

Example: Moving some concepts and features from VMware Cloud Director (vCD) to Aria Automation and then calling it VCF Automation is also not innovative. It was the right thing to do, as vCD and Aria Automation (formerly known as vRealize Automation) shared many overlapping features and concepts. In other words, we can expect VCF Automation to be the future and vCD will be retired in a few years.

Anyway, there’s a pattern here. Platform vendors continue to position themselves as “private cloud providers”, yet the experience they offer remains rooted in managing hardware, scaling clusters, and applying patches. Whether it’s VCF or Nutanix, the story is always the same: it’s better infrastructure. But that’s the problem. It’s still infrastructure.

In contrast, the real shift toward cloud doesn’t start with software-defined storage or NSX overlay networks. It starts with the service model. That’s what makes cloud work. That’s what makes it scalable, elastic, and developer-first. That’s what customers actually need.

Let’s unpack where VCF 9.0 lands and why it still misses the mark.

What’s New in VCF 9.0. And What’s Not.

Broadcom deserves credit for moving VCF closer to what customers have been asking for since at least 2020. The platform now includes a proper developer consumption layer, integrated VPC-style networking, a simplified control plane, and aligned software versions for different products. Yes, it feels more like a cloud. It automates more, hides more complexity, and makes day 2 operations less painful. All good steps!

The new virtual private cloud constructs let teams carve out self-contained network domains – complete with subnets, NAT, firewall rules, and load balancers – all provisioned from a central interface. That’s a meaningful upgrade from the old NSX workflows. Now, transit gateways can be deployed automatically, reducing the friction of multi-domain connectivity. The whole setup is better, simpler, and more cloud-like. Well done.

On the consumption side, there’s a proper push toward unified APIs. Terraform support, policy-as-code blueprints in YAML, and native Kubernetes provisioning give developers a way to consume infrastructure more like they would in a hyperscaler environment. VCF customers can onboard teams faster, and the lifecycle engine behind the scenes handles upgrades, certificates, and best-practice configurations with far less manual effort.

So yes, VCF 9.0 is a big step forward for Broadcom and for existing VMware customers. But let’s put that progress into perspective.

Cloud Features Delivered Years Too Late

The features we’re seeing now – developer APIs, VPCs, self-service provisioning, built-in security, elastic-like networking – these aren’t breakthroughs. They are basic expectations. Public cloud providers like AWS and Azure introduced the VPC concept more than 10 years ago. Public clouds have offered full-stack policy automation, service mesh observability, and integrated load balancing for most of the last decade.

What VCF 9.0 delivers in 2025 is essentially what existing on-premises customers were asking for back in 2020.

The bigger concern is that VMware has always been the benchmark for enterprise-grade virtualization and private infrastructure. When customers bought into VCF years ago, they expected these capabilities then, not now. Broadcom has simply shipped the version of VCF that many customers assumed was already on the roadmap, five years ago.

And even now, many of the services (add-ons) in VCF 9.0 like Avi load balancing, vDefend IDS/IPS, integrated databases, and AI services, are optional components, mostly manually deployed, and not fully elastic or usage-based. These are integrations, not native services. You still need to operate them.

The Core Problem: It’s Still Infrastructure-Led

That’s the real difference. VCF and Nutanix remain infrastructure-led platforms. They require hardware planning, capacity management, lifecycle orchestration, and dependency tracking. Yes, they have APIs. Yes, they support Kubernetes. But at their core, they are platforms you need to own, operate, and scale yourself.

Cloud, on the other hand, is not about owning anything. It’s about consuming outcomes. VCF 9.0 and others are just not there yet.

The Illusion of a Private Cloud

This is why it’s time to call out the difference. Just because something looks like cloud – has some APIs, supports Kubernetes, uses words like “consumption” and “developer self-service” – doesn’t mean it actually behaves like cloud.

The illusion of a “private cloud” is seductive. You get to keep control. You get to use familiar tools. But control also means responsibility. Familiar tools mean legacy thinking. And a so-called private cloud, in most cases, just means more complex infrastructure with higher expectations.

That’s not transformation. That’s rebranding.

What VCF 9.0 delivers is an important evolution of VMware’s private infrastructure platform. But let’s not confuse that with cloud. Broadcom has moved in the right direction. They have shipped what customers needed years ago. But they are still delivering (virtual) infrastructure. Just better packaged.

Final Thought

You don’t transform your IT strategy by modernizing clusters. You transform it by changing how you consume and operate technology.

So the question isn’t whether your stack looks like “the cloud”. The question is whether you can stop operating infrastructure and start consuming services.

That’s the real line between emulating the cloud and actually being one. And as of today, VCF (and Nutanix) are still on the other side of that line. It’s not good. It’s not bad. It is what it is.

Why Switzerland Needs a Different Kind of Sovereign Cloud

Why Switzerland Needs a Different Kind of Sovereign Cloud

Switzerland doesn’t follow. It observes, evaluates, and decides on its own terms. In tech, in policy, and especially in how it protects its data. That’s why the typical EU sovereign cloud model won’t work here. It solves a different problem, for a different kind of political union.

But what if we could go further? What if the right partner, one that understands vertical integration, local control, and legal separation, could build something actually sovereign?

That partner might just be Oracle.

Everyone is talking about the EU’s digital sovereignty push and Oracle responded with a serious answer: the EU Sovereign Cloud, which celebrated its second anniversary a few weeks ago. It’s a legally ring-fenced, EU-operated, independently staffed infrastructure platform. Built for sovereignty, not just compliance.

That’s the right instinct. But Switzerland is not the EU. And sovereignty here means more than “EU-only.” It means operations bound by Swiss law, infrastructure operated on Swiss soil, and decisions made by Swiss entities.

Oracle Alloy and OCI Dedicated Region – Sovereignty by Design

Oracle’s OCI Dedicated Region and the newer Alloy model were designed with decentralization in mind. Unlike traditional hyperscaler zones, these models bring the entire control plane on-premises, not just the data.

That allows for policy enforcement, tenant isolation, and lifecycle management to happen within the customer’s boundaries, without default exposure to centralized cloud control towers. In short, the foundation for digital sovereignty is already there.

But Switzerland, especially the public sector, expects more.

What Still Needs to Be Solved for Switzerland

Switzerland doesn’t just care about where data sits. It cares about who holds the keys, who manages the lifecycle, and under which jurisdiction they operate.

While OCI Dedicated Region and Alloy keep the control plane local, certain essential services, such as telemetry, patch delivery, and upgrade mechanisms, still depend on Oracle’s global backbone. In the Swiss context, even a low-level dependency can raise concerns about jurisdictional risk, including exposure to laws like the U.S. CLOUD Act.

Support must remain within Swiss borders. Sovereign regions that rely on non-Swiss teams or legal entities to resolve incidents still carry legal and operational exposure – but this data can be anonymized. Sovereignty includes not only local infrastructure, but also patch transparency, cryptographic root trust, and full legal separation from foreign jurisdictions. 

Yes, operational teams must be Swiss-based, except at the tier 2 or tier 3 level.

Avaloq Is Already Leading the Way

This isn’t just theory. Switzerland already has a working example: Avaloq, the Swiss financial technology provider, is running core workloads on OCI Dedicated Region.

These are not edge apps or sandbox environments. Avaloq supports mission-critical platforms for regulated financial institutions. If they trust Oracle’s architecture with that responsibility, the model is clearly feasable. From a sovereignty, security, and compliance perspective.

Avaloq’s deployment shows that Swiss-regulated workloads can run securely, locally, and independently. And if one of Switzerland’s most finance-sensitive firms went down this path, others across government, healthcare, and infrastructure should be paying attention.

Sovereignty doesn’t mean reinventing everything. It means learning from those already building it.

The Bottom Line

Switzerland doesn’t need more cloud. It needs a cloud built for Swiss values: neutrality, autonomy, and legal independence.

Oracle is closer to that model than most. Its architecture is already designed for local control. Its EU Sovereign Cloud shows it understands the legal and operational dimensions of sovereignty. And with Avaloq already in production on OCI Dedicated Region, the proof is there.

The technology is ready. The reference customer is live.

What comes next is a question of commitment.

Why Sovereignty Needs Both Centralization and Decentralization

Why Sovereignty Needs Both Centralization and Decentralization

Europe’s cloud strategy is at a crossroads. There’s pressure to take control, to define sovereignty in infrastructure terms, and to reduce exposure to non-European hyperscalers. But somewhere along the way, the conversation fell into a binary trap: either centralize for control or decentralize for autonomy.

That’s not how modern systems work. And it’s not how sovereignty is going to work either.

Europe’s reliance on U.S. hyperscalers remains a security and sovereignty risk. While countries like France, Germany, and Italy invest in local providers, their efforts remain siloed. Without alignment, Europe is left with patchwork sovereignty.

I said it many times already, but let me repeat it. Sovereignty in the cloud isn’t a matter of choosing one path or the other. It’s about building an architecture that combines both centralized coordination with decentralized execution. Anything else either fragments too fast or becomes too rigid to function in a sovereign context.

Centralization Is About Structure, Not Control

Centralization plays a role. A central governance framework helps define what sovereignty means: where data can move, who operates the infrastructure, how compliance is enforced, how identity is managed. Without some level of central alignment, sovereignty collapses into 27 different interpretations with no common ground.

This is where Europe still struggles. They are good at setting principles – GDPR, data residency, trusted cloud labels – but they lack shared operational infrastructure. What they do have is fragmented: agencies, member states, and industry sectors each building their own versions of sovereignty with little interoperability between them.

Centralization brings order, but order alone isn’t resilience.

Sovereign Microzones: Fragmented by Design

The current trajectory in many parts of Europe is toward what could be called sovereign microzones, individually defined, locally controlled, often incompatible cloud environments built by national or sector-specific entities.

These microzones are born out of good intentions: protect critical data, maintain legal oversight, reduce dependency. But most of them don’t scale well. Each implementation introduces its own stack, its own compliance logic, and often its own interpretation of what “sovereign” really means.

In practice, this results in technical fragmentation and governance friction. Cross-border collaboration becomes harder. Data sharing between sectors stalls. Innovation slows as cloud-native capabilities are stripped back to meet narrow compliance targets.

Sovereignty was never meant to be a bunker. If these microzones can’t interoperate, they may become silos. Silos with flags on top.

Operational Autonomy vs. Strategic Realism

One idea gaining momentum is operational autonomy, ensuring that European workloads can continue to run even in the event of a political embargo or legal dispute with a non-EU provider. It’s a serious concept, grounded in real geopolitical concerns. The fear is that U.S. cloud vendors could, under extraordinary circumstances, be forced to restrict services in Europe. I get it.

But let’s be honest: the probability of a coordinated embargo cutting off hundreds of cloud regions across Europe is extremely low. Not zero. But close. The legal, economic, and political blowback would be enormous. The U.S. has more to lose than gain by treating Europe as an adversary in this space.

Still, operational autonomy has value. It’s about having options. The ability to reassign workloads, shift operational control, and decouple governance when needed. But building that autonomy doesn’t mean rejecting foreign technology outright. It means investing in layered sovereignty: trusted deployment models, contractual separation, technical isolation when necessary, and above all – control over the control plane.

Note: Operational autonomy is not the same as autarky.

What Oracle Cloud Enables

Oracle Cloud fits this model in ways that are often overlooked. Not because it’s European, it isn’t, but because it supports the technical and operational diversity that sovereignty requires.

With OCI Dedicated Region and the Cloud@Customer portfolio, institutions can run full-featured or a subset of Oracle Cloud environments inside their own data centers, with some/complete control over operations, updates, and access.

Oracle’s EU Sovereign Cloud further separates European workloads from global infrastructure, with EU-based personnel and compliance boundaries. And unlike some providers, Oracle doesn’t require full-stack standardization to make it work. It’s open, modular, and designed for interoperability.

A good example of this approach is the new partnership between Oracle and Nextcloud. It brings together a leading European open-source collaboration platform with Oracle’s sovereign cloud infrastructure. The result is a deployment model where public sector organizations can run Nextcloud in a scalable, cloud-native environment while maintaining full data control and legal jurisdiction within the EU. It’s an antidote to sovereign fragmentation: a solution that respects both European values and operational pragmatism.

This kind of flexibility matters. It respects the complexity of European sovereignty rather than trying to erase it.

Conclusion: Not Either/Or – Both

Europe shouldn’t have to choose between centralization and decentralization. In fact, it can’t. Real sovereignty (political, technical, operational) lives in the tension between the two.

The false choice only leads to false confidence. The reality is more difficult, but also more durable: structure without rigidity, autonomy without fragmentation.

Sovereignty isn’t built in isolation. It’s coordinated. Together.