Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Aug 24, 2025 | AWS, Azure, Google Cloud, OCI Dedicated Region, Oracle Alloy, Oracle Cloud Infrastructure, Oracle Compute Cloud@Customer, Sovereign Cloud, VMware Cloud Foundation

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.

From Castles to Credentials – Why Identities Are the New Perimeter

From Castles to Credentials – Why Identities Are the New Perimeter

Aug 5, 2025 | AWS, Azure, Google Cloud, Networking, Oracle Cloud Infrastructure, Security

The security world has outgrown its castle. For decades, enterprise networks operated on the principle of implicit trust: if a device or user could connect from inside the perimeter, they were granted access. Firewalls and VPNs acted as moats and drawbridges, controlling what entered the fortress. But the rise of clouds, remote work, and APIs has broken down those walls by replacing physical boundaries with something far more fluid: identity.

This shift has led to the emergence of Zero Trust Architecture (ZTA), which flips the traditional model. Instead of trusting users based on their location or device, we now assume that no actor should be trusted by default, whether inside or outside the network. Every access request must be verified, every time, using contextual signals like identity, posture, behavior, and intent.

But “Zero Trust” isn’t just about a philosophical change but about practical design as well. Many organizations start their Zero Trust journey by microsegmenting networks or rolling out identity-aware proxies. That’s a step in the right direction, but a true transformation goes deeper. It redefines identity as the central pillar of security architecture. Not just a gatekeeper, but the control plane through which access decisions are made, enforced, and monitored.

The Inherent Weakness of Place-Based Trust

The traditional security model depends on a dangerous assumption: if you are inside the network, you are trustworthy. That might have worked when workforces were centralized and systems were isolated. With hybrid work, multi-cloud adoption, and third-party integrations, physical locations mean very little nowadays.

Attackers know this. Once a single user account is compromised via phishing, credential stuffing, or social engineering, it can be used to move laterally across the environment, exploiting flat networks and overprovisioned access. The rise of ransomware, supply chain attacks, and insider threats all originate from this misplaced trust in location.

This is where identity-based security becomes essential. Instead of relying on IP addresses or subnet ranges, access policies are tied to who or what is making the request and under what conditions. For example, a user might only get access if their device is healthy, they are connecting from a trusted region, and they pass MFA.

By decoupling access decisions from the network and basing them on identity context, organizations can stop granting more access than necessary and prevent compromised actors from gaining a foothold.

Identities Take Center Stage

Identities are multiplying rapidly, not just users, but also workloads, devices, APIs, and service accounts. This explosion of non-human identities creates a massive attack surface. Yet, in many organizations, these identities are poorly managed, barely monitored, and rarely governed.

Identity-Centric Zero Trust changes that. It places identity at the center of every access flow, ensuring that each identity, human or machine, is:

  • Properly authenticated

  • Authorized for just what it needs

  • Continuously monitored for unusual behavior

Example: A CI/CD pipeline deploys an app into production. With traditional models, that pipeline might have persistent credentials with broad permissions. In an identity-centric model, the deployment service authenticates via workload identity, receives just-in-time credentials, and is granted only the permissions needed for that task.

This model reduces privilege sprawl, limits the blast radius of compromised credentials, and provides clear visibility and accountability. It’s about embedding least privilege, lifecycle management, and continuous validation into the DNA of how access is handled.

Routing With Intent

Zero Trust doesn’t mean the network no longer matters, it means the network must evolve. Today’s networks need to understand and enforce identity, just like the access layer.

A good example of this is Oracle Cloud Infrastructure’s Zero Trust Packet Routing (ZPR). With ZPR, packets are only routed if the source and destination identities are explicitly authorized to communicate. It’s not just about firewall rules or ACLs but also about intent-based networking, where identity and policy guide the flow of traffic. A backend service won’t even see packets from an unauthorized frontend. Routing decisions happen only after both parties are authenticated and authorized.

This is part of a bigger trend. Across the industry, cloud providers and SDN platforms are starting to embed identity metadata into network-level decisions, and routing and access enforcement are being infused with contextual awareness and identity-driven policies.

For architects and security teams, this opens new possibilities for building secure-by-design cloud networks, where you can enforce who talks to what, when, and under what conditions, down to the packet level.

Identity as the Control Plane of Modern Security

If Zero Trust has taught us anything, it’s that identity is the new perimeter and that it’s the control plane for the entire security architecture.

When identity becomes the central decision point, everything changes:

  • Network segmentation is enforced via identity-aware rules

  • Application access is governed by contextual IAM policies

  • Monitoring and detection pivot around behavioral baselines tied to identity

  • Automation and response are triggered by anomalies in identity behavior

This model allows for granular, adaptive, and scalable control, without relying on fixed infrastructure or fragile perimeters. It also provides a better experience for users: access becomes more seamless when trust is built dynamically based on real-time signals, rather than static rules.

Image with no description

Importantly, this approach doesn’t require a big bang overhaul. Organizations can start small by maturing IAM hygiene, implementing least privilege, or onboarding apps into SSO and MFA, and build toward more advanced use cases like workload identity, CIEM (Cloud Infrastructure Entitlement Management), and ITDR (Identity Threat Detection and Response).

Concluding Thoughts

We need a security model that reflects that reality. Perimeters no longer define trust. Location is no longer a proxy for legitimacy. And static controls are no match for dynamic threats – it’s like using static IPs when working with Kubernetes and containers.

Identity-Centric Zero Trust offers a modern foundation and a strategy. One that weaves together people, processes, and technologies to ensure that every access decision is intentional, contextual, and revocable.

Whether you are modernizing a legacy environment or building greenfield in the cloud, start by asking the right question.

Not “where is this request coming from?” but “who is making the request, and should they be allowed?”.

The Cloud Isn’t Eating Everything. And That’s a Good Thing

The Cloud Isn’t Eating Everything. And That’s a Good Thing

Aug 3, 2025 | Alibaba Cloud, AWS, Azure, Edge Computing, Google Cloud, Multi-Cloud, Oracle Cloud Infrastructure, Sovereign Cloud

A growing number of experts warn that governments and enterprises are “digitally colonized” by U.S. cloud giants. A provocative claim and a partial truth. It’s an emotionally charged view, and while it raises valid concerns around sovereignty and strategic autonomy, it misses the full picture.

Because here’s the thing. Some (if not most) workloads in enterprise and public sector IT environments are still hosted on-premises. This isn’t due to resistance or stagnation. It’s the result of deliberate decisions made by informed IT leaders. Leaders who understand their business, compliance landscape, operational risks, and technical goals.

We are no longer living in a world where the public cloud is the default. We are living in a world where “cloud” is a choice and is used strategically. This is not failure. It’s maturity.

A decade ago, “cloud-first”  was often a mandate. CIOs and IT strategists were encouraged, sometimes pressured, to move as much as possible to the public cloud. It was seen as the only way forward. The public cloud was marketed as cheaper, faster, and more innovative by default.

But that narrative didn’t survive contact with reality. As migrations progressed, enterprises quickly discovered that not every workload belongs in the cloud. The benefits were real, but so were the costs, complexities, and trade-offs.

Today, most organizations operate with a much more nuanced perspective. They take the time to evaluate each application or service based on its characteristics. Questions like: Is this workload latency-sensitive? What are the data sovereignty requirements? Can we justify the ongoing operational cost at scale? Is this application cloud-native or tightly coupled to legacy infrastructure? What are the application’s dependencies?

This is what maturity looks like. It’s not about saying “yes” or “no” to the cloud in general. It’s about using the right tool for the right job. Public cloud remains an incredibly powerful option. But it is no longer a one-size-fits-all solution. And that’s a good thing.

On-Premises Infrastructure Is Still Valid

There is this persistent myth that running your own datacenter, or even part of your infrastructure, is a sign that you are lagging behind. That if you are not in the cloud, you are missing out on agility, speed, and innovation. That view simply doesn’t hold up.

In reality, on-premises infrastructure is still a valid, modern, and strategic choice for many enterprises, especially in regulated industries like healthcare, finance, manufacturing, and public services. These sectors often have clear, non-negotiable requirements around data locality, compliance, and performance. In many of these cases, operating infrastructure locally is not just acceptable. It’s the best option available.

Modern on-prem environments are nothing like the datacenters of the past. Thanks to advancements in software-defined infrastructure, automation, and platform engineering, on-prem can offer many of the same cloud-like capabilities: self-service provisioning, infrastructure-as-code, and full-stack observability. When properly built and maintained, on-prem can be just as agile as the public cloud.

That said, it’s important to acknowledge a key difference. While private infrastructure gives you full control, it can take longer to introduce new services and capabilities. You are not tapping into a global marketplace of pre-integrated services and APIs like you would with Oracle Cloud or Microsoft Azure. You are depending on your internal teams to evaluate, integrate, and manage each new component.

And that’s totally fine, if your CIO’s focus is stability, compliance, and predictable innovation cycles. For many organizations, that’s (still) exactly what’s needed. But if your business thrives on emerging technologies, needs instant access to the latest AI or analytics platforms, or depends on rapid go-to-market execution, then public cloud innovation cycles might offer an advantage that’s hard to replicate internally.

Every Enterprise Can Still Build Their Own Data Center Stack

It’s easy to assume that the era of enterprises building and running their own cloud-like platforms is over. After all, hyperscalers move faster, operate at massive scale (think about the thousands of engineers and product managers), and offer integrated services that are hard to match. For many organizations, especially those lacking deep infrastructure expertise or working with limited budgets, the public cloud is the most practical and cost-effective option.

But that doesn’t mean enterprises can’t or shouldn’t build their own platforms, especially when they have strong reasons to do so. Many still do, and do it effectively. With the right people, architecture, and operational discipline, it’s entirely possible to build private or hybrid environments that are tailored, secure, and strategically aligned.

The point isn’t to compete with hyperscalers on scale, it’s to focus on fit. Enterprises that understand their workloads, compliance requirements, and business goals can create infrastructure that’s more focused and more integrated with their internal systems.

Yes, private platforms may evolve more slowly. They may require more upfront investment and long-term commitment. But in return, they offer control, transparency, and alignment. Advantages that can outweigh speed in the right contexts!

And critically, the tooling has matured. Today’s internal platforms aren’t legacy silos but are built with the same modern engineering principles: Kubernetes, GitOps, telemetry, CI/CD, and self-service automation.

Note: If a customer wants the best of both worlds, there are options like OCI Dedicated Region.

The Right to Choose the Right Cloud

One of the most important shifts we are seeing in enterprise IT is the move away from single-platform thinking. No one-size-fits-all platform exists. And that’s precisely why the right to choose the right cloud matters.

Public cloud makes sense in many scenarios. Organizations might choose Azure because of its tight integration with Microsoft tools. They might select Oracle Cloud for better pricing or AI capabilities. At the same time, they continue to operate significant workloads on-premises, either by design or necessity.

This is the real world of enterprise IT: mixed environments, tailored solutions, and pragmatic trade-offs. These aren’t poor decisions or “technical debt”. Often, they are deliberate architectural choices made with a full understanding of the business and operational landscape. 

What matters most is flexibility. Organizations need the freedom to match workloads to the environments that best support them, without being boxed in by ideology, procurement bias, or compliance roadblocks. And that flexibility is what enables long-term resilience.

What the Cloud Landscape Actually Looks Like

Step into any enterprise IT environment today, and you will find a blend of technologies, platforms, and operational models. And the mix varies based on geography, industry, compliance rules, and historical investments.

The actual landscape is not black or white. It’s a continuum of choices. Some services live in hyperscale clouds. Others are hosted in sovereign, regional datacenters. Many still run in private infrastructure owned and operated by the organization itself.

This hybrid approach isn’t messy. It’s intentional and reflects the complexity of enterprise IT and the need to balance agility with governance, innovation with stability, and cost with performance.

What defines modern IT today is the operating model. The cloud is not a place. It’s a way of working. Whether your infrastructure is on-prem, in the public cloud, or somewhere in between, the key is how it’s automated, how it’s managed, how it integrates with developers and operations, and how it evolves with the business.

Conclusion: Strategy Over Hype – And Over Emotion

There’s no universal right or wrong when it comes to cloud strategy. Only what works for your organization based on risk, requirements, talent, and timelines. But we also can’t ignore the reality of the current market landscape.

Today, U.S. hyperscalers control over 70% of the European cloud market. Across infrastructure layers like compute, storage, networking, and software stacks, Europe’s digital economy relies on U.S. technologies for 85 to 90% of its foundational capabilities. 

But these numbers didn’t appear out of nowhere.

Let’s be honest: it’s not the fault of hyperscalers that enterprises and public sector organizations chose to adopt their platforms. Those were decisions made by people – CIOs, procurement teams, IT strategists – driven by valid business goals: faster time-to-market, access to innovation, cost modeling, availability of talent, or vendor consolidation.

These choices might deserve reevaluation, yes. But they don’t deserve emotional blame.

We need to stop framing the conversation as if U.S. cloud providers “stole” the European market. That kind of narrative doesn’t help anyone. The reality is more complex and far more human. Companies chose platforms that delivered, and hyperscalers were ready with the talent, services, and vision to meet that demand.

If we want alternatives, if we want European options to succeed, we need to stop shouting at the players and start changing the rules of the game. That means building competitive offerings, investing in skills, aligning regulation with innovation, and making sovereignty a business advantage, not just a political talking point.

Can a Unified Multi-Cloud Inventory Transform Cloud Management?

Can a Unified Multi-Cloud Inventory Transform Cloud Management?

Aug 2, 2025 | Alibaba Cloud, AWS, Azure, Cloud Native Apps, Edge Computing, Google Cloud, Kubernetes, Multi-Cloud, Networking, Observability, Oracle Cloud Infrastructure, VMware Cloud

When we spread our workloads across clouds like Oracle Cloud, AWS, Azure, Google Cloud, maybe even IBM, or smaller niche players, we knowingly accept complexity. Each cloud speaks its own language, offers its own services, and maintains its own console. What if there were a central place where we could see everything: every resource, every relationship, across every cloud? A place that lets us truly understand how our distributed architecture lives and breathes?

I find myself wondering if we could one day explore a tool or approach that functions as a multi-cloud inventory, keeping track of every VM, container, database, and permission – regardless of the platform. Not because it’s a must-have today, but because the idea sparks curiosity: what would it mean for cloud governance, cost transparency, and risk reduction if we had this true single pane of glass?

Who feels triggered now because I said “single pane of glass”? 😀 Let’s move on!

Could a Multi-Cloud Command Center Change How We Visualize Our Environment?

Let’s imagine it: a clean interface, showing not just lists of resources, but the relationships between them. Network flows across cloud boundaries. Shared secrets between apps on “cloud A” and databases on “cloud B”. Authentication tokens moving between clouds.

What excites me here isn’t the dashboard itself, but the possibility of visualizing the hidden links across clouds. Instead of troubleshooting blindly, or juggling a dozen consoles, we could zoom out for a bird’s-eye view. Seeing in one place how data and services crisscross providers.

Multi-Cloud Insights

I don’t know if we’ll get there anytime soon (or if such a solution already exists) but exploring the idea of a unified multi-cloud visualization tool feels like an adventure worth considering.

Multi-Cloud Search and Insights

When something breaks, when we are chasing a misconfiguration, or when we want to understand where we might be exposed, it often starts with a question: Where is this resource? Where is that permission open?

What if we could type that question once and get instant answers across clouds? A global search bar that could return every unencrypted public bucket or every server with a certain tag, no matter which provider it’s on.

Multi-Cloud Graph Query

Wouldn’t it be interesting if that search also showed contextual information: connected resources, compliance violations, or cost impact? It’s a thought I keep returning to because the journey toward proactive multi-cloud operations might start with simple, unified answers.

Could a True Multi-Cloud App Require This Kind of Unified Lens?

Some teams are already building apps that stretch across clouds: an API front-end in one provider, authentication in another, ML workloads on specialized platforms, and data lakes somewhere else entirely. These aren’t cloud-agnostic apps, they are “cloud-diverse” apps. Purpose-built to exploit best-of-breed services from different providers.

That makes me wonder: if an app inherently depends on multiple clouds, doesn’t it deserve a control plane that’s just as distributed? Something that understands the unique role each cloud plays, and how they interact, in one coherent operational picture?

I don’t have a clear answer, but I can’t help thinking about how multi-cloud-native apps might need true multi-cloud-native management.

VMware Aria Hub and Graph – Was It a Glimpse of the Future?

Not so long ago, VMware introduced Aria Hub and Aria Graph with an ambitious promise: a single place to collect and normalize resource data from all major clouds, connect it into a unified graph, and give operators a true multi-cloud inventory and control plane. It was one of the first serious attempts to address the challenge of understanding relationships between cloud resources spread across different providers.

VMware Aria Hub Dashboard

The idea resonated with anyone who has struggled to map sprawling cloud estates or enforce consistent governance policies in a multi-cloud world. A central graph of every resource, dependency, and configuration sounded like a game-changer. Not only for visualization, but also for powerful queries, security insights, and cost management.

But when Broadcom acquired VMware, they shifted focus away from VMware’s SaaS portfolio. Many SaaS-based offerings were sunset or sidelined, including Aria Hub and Aria Graph, effectively burying the vision of a unified multi-cloud inventory platform along with them.

I still wonder: did VMware Aria Hub and Graph show us a glimpse of what multi-cloud operations could look like if we dared to standardize resource relationships across clouds? Or did it simply arrive before its time, in an industry not yet ready to embrace such a radical approach?

Either way, it makes me even more curious about whether we might one day revisit this idea and how much value a unified resource graph could unlock in a world where multi-cloud complexity continues to grow.

Final Thoughts

I don’t think there’s a definitive answer yet to whether we need a unified multi-cloud inventory or command center today. Some organizations already have mature processes and tooling that work well enough, even if they are built on scripts, spreadsheets, or point solutions glued together. But as multi-cloud strategies evolve, and as more teams start building apps that intentionally spread across multiple providers, I find myself increasingly curious about whether we will see renewed demand for a shared data model of our entire cloud footprint.

Because with each new cloud we adopt, complexity grows exponentially. Our assets scatter, our identities and permissions multiply, and our ability to keep track of everything by memory or siloed dashboards fades. Even something simple, like understanding “what resources talk to this database?” becomes a detective story across clouds.

A solution that offers unified visibility, context, and even policy controls feels almost inevitable if multi-cloud architectures continue to accelerate. And yet, I’m also aware of how hard this problem is to solve. Each cloud provider evolves quickly, their APIs change, and mapping their semantics into a single, consistent model is an enormous challenge.

That’s why, for now, I see this more as a hypothesis. An idea to keep exploring rather than a clear requirement. I’m fascinated by the thought of what a central multi-cloud “graph” could unlock: faster investigations, smarter automation, tighter security, and perhaps a simpler way to make sense of our expanding environments.

Whether we build it ourselves, wait for a vendor to try again, or discover a new way to approach the problem, I’m eager to see how the industry experiments with this space in the years ahead. Because in the end, the more curious we stay, the better prepared we’ll be when the time comes to simplify the complexity we’ve created.

Sovereign Clouds and the VMware Earthquake: Dependency Isn’t Just a Hyperscaler Problem

Sovereign Clouds and the VMware Earthquake: Dependency Isn’t Just a Hyperscaler Problem

Jul 29, 2025 | Alibaba Cloud, AWS, Azure, Google Cloud, Oracle Cloud Infrastructure, Sovereign Cloud, VMware Cloud Foundation

The concept of “sovereign cloud” has been making waves across Europe and beyond. Politicians talk about it. Regulators push for it. Enterprises (re-)evaluate it. On the surface, it sounds like a logical evolution: regain control, keep data within national borders, reduce exposure to foreign jurisdictions, and while you are at it, maybe finally break free from the gravitational pull of the U.S. hyperscalers.

After all, hyperscaler dependency is seen as the big bad wolf. If your workloads live in AWS, Azure, Google Cloud or Oracle Cloud Infrastructure, you are automatically exposed to price increases, data sovereignty concerns, U.S. legal reach (hello, CLOUD Act), and a sense of vendor lock-in that seems harder to escape with every commit to infrastructure-as-code.

So, the solution appears simple: go local, go sovereign, go safe.

But if only it were that easy.

The truth is: sovereignty isn’t something you can just buy off the shelf. It’s not a matter of switching cloud logos or picking the provider that wraps their marketing in your national flag. Because even within your own datacenter, even with platforms that have long been considered “sovereign” and independent, the same risks apply.

The best example? VMware.

What happened in the VMware ecosystem over the past year should be a wake-up call for anyone who thinks sovereignty equals control. Because, as we have now seen, control can vanish. Fast. Very fast.

VMware’s Rapid Fall from Grace

Take VMware. For years, it was the go-to platform for building secure, sovereign private clouds. Whether in your own datacenter or hosted by a trusted service provider in your region, VMware felt like the safe, stable choice. No vendor lock-in (allegedly), no forced cloud-native rearchitecture, and full control over your workloads. Rainbows, unicorns, and that warm fuzzy feeling of sovereignty.

Then came the Broadcom acquisition, and with it, a cold splash of reality.

As Hock Tan , our President and CEO, shared in today's General Session at VMware Explore Barcelona, European customers want control over their data and processes. | Broadcom

Practically overnight, prices shot up. In some cases, more than doubled. Features were suddenly stripped out or repackaged into higher-priced bundles. Longstanding partner agreements were shaken, if not broken. Products disappeared or were drastically repositioned. Customers and partners were caught off guard. Not just by the changes, but by how quickly they hit.

And just like that, a platform once seen as a cornerstone of sovereign IT became a textbook example of how fragile that sovereignty really is.

Sovereignty Alone Doesn’t Save You

The VMware story exposes a hard truth: so-called “sovereign” infrastructure isn’t immune to disruption. Many assume risk only lives in the public cloud under the branding of AWS, Azure, or Oracle Cloud. But in reality, the triggers for a “cloud exit” or forced platform shift can be found anywhere. Also on-premises!

A sudden licensing change. An unexpected acquisition. A new product strategy that leaves your current setup stranded. None of these things care whether your workloads are in a public cloud region or a private rack in your basement. Dependency is dependency, and it doesn’t always come with a hyperscaler logo.

It’s Not About Picking the Right Vendor. It’s About Being Ready for the Wrong One.

That’s why sovereignty, in the real world, isn’t something you just buy. It’s something you design for.

Note: Some hyperscalers now offer “sovereign by design” solutions but even these require deeper architectural thinking.

Sure, a Greenfield build on a sovereign cloud stack sounds great. Fresh start, full control, compliance checkboxes all ticked. But the reality for most organizations is very different. They have already invested years into specific platforms, tools, and partnerships. There are skill gaps, legacy systems, ongoing projects, and plenty of inertia. Ripping it all out for the sake of “clean” sovereignty just isn’t feasible.

That’s what makes architecture, flexibility, and diversification so critical. A truly resilient IT strategy isn’t just about where your data lives or which vendor’s sticker is on the server. It’s about being ready (structurally, operationally, and contractually) for things to change.

Because they will change.

Open Source ≠ Sovereign by Default

Spoiler: Open source won’t save you either

Let’s address another popular idea in the sovereignty debate. The belief that open source is the magic solution. The holy grail. The thinking goes: “If it’s open, it’s sovereign”. You have the source code, you can run it anywhere, tweak it however you like, and you are free from vendor lock-in. Yeah, right.

Sounds great. But in practice? It’s not that simple.

Yes, open source can enable sovereignty, but it doesn’t guarantee it. Just because something is open doesn’t mean it’s free of risk. Most open-source projects rely on a global contributor base, and many are still controlled, governed, or heavily influenced by large commercial vendors – often headquartered in the same jurisdictions we are supposedly trying to avoid. Yes, that’s good and bad at the same time, isn’t it?

And let’s be honest: having the source code doesn’t mean you suddenly have a DevOps army to maintain it, secure it, patch it, integrate it, scale it, monitor it, and support it 24/7. In most cases, you will need commercial support, managed services, or skilled specialists. And with that, new dependencies emerge.

So what have you really achieved? Did you eliminate risk or just shift it?

Open source is a fantastic ingredient in a sovereign architecture – in any cloud architecture. But it’s not a silver bullet.

Behind the Curtain – Complexity, Not Simplicity

From the outside, especially for non-IT people, the sovereign cloud debate can look like a clear binary: US hyperscaler = risky, local provider = safe. But behind the curtain, it’s much more nuanced. You are dealing with a web of relationships, existing contracts, integrated platforms, and real-world limitations.

The Broadcom-VMware shake-up was a loud and very public reminder that disruption can come from any direction. Even the platforms we thought were untouchable can suddenly become liabilities.

So the question isn’t: “How do we go sovereign?”

It’s: “How do we stay in control, no matter what happens?”

That’s the real sovereignty.

Open Source in the Cloud Era – Still Free, but Never Cheap?

Open Source in the Cloud Era – Still Free, but Never Cheap?

Jul 25, 2025 | Alibaba Cloud, AWS, Azure, Google Cloud, Kubernetes, Open Source Software, Oracle Cloud Infrastructure

This article continues the conversation started in “Open source can help with portability and lock-in – but it is not a silver bullet”, where we explored how open source technologies can reduce cloud lock-in, but aren’t a universal fix. Now we go one step further.

Open source software (OSS) is the unsung hero behind much of the innovation we see in the cloud today. From container runtimes powering serverless workloads to the databases running mission-critical apps, OSS is everywhere. But now the question arises: how do we make open source sustainable and what role do the cloud providers play?

Some say the hyperscalers are the villains in this story. I see it differently.

I believe the major cloud platforms including AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure (OCI) are not undermining open source. On the contrary, they are expanding its reach, accelerating its maturity, and making it more accessible than ever before.

Open Source Is The Backbone of the Cloud

The most exciting thing about cloud platforms today is how accessible open source technology has become. Technologies like Kubernetes, Prometheus, MySQL, Redis, and Postgres are no longer just community-maintained stacks. They are global services delivered with enterprise reliability. What hyperscalers such as AWS, Azure, and Oracle Cloud have done is operationalize these tools at scale, offering managed services that developers trust, without caring for patching, HA or backups. The result is remarkable: global systems running OSS as a service.

In other words, turning OSS into mainstream infrastructure. That is not to be understated.

Running Open Source at Scale Is Hard (And Expensive)

Yes, open source is free to use. But it’s not free to run.

Anyone can deploy an open source application. Running it at scale, though? That’s a different story. It takes discipline, expertise, and relentless operational focus:

  • high availability setups,
  • automatic failover,
  • performance tuning,
  • deep telemetry,
  • continuous patching,
  • secure configurations,
  • IAM integration,
  • versioning strategy,
  • backup orchestration,
  • and regular upgrades.

They are day-to-day realities for teams operating at scale.

That’s why managed services from hyperscalers exist and why they are so widely adopted. Platforms like Amazon RDS, Azure Database for PostgreSQL, Google Cloud Memorystore, or Oracle MySQL HeatWave take the core of a powerful open source engine and remove the heavy lifting. You are not just getting hosted software, you are getting resilience, automation, and accountability.

When you consume Google’s GKE or Oracle Kubernetes Engine (OKE), you are effectively outsourcing operations. You gain predictability and uptime without building a 24/7 SRE team. That’s not lock-in. It’s operational leverage!

Hyperscalers aren’t restricting choice. They are offering a second path. One designed for teams that need focus, speed, and as little downtime as possible.

A Fair Critique – OSS Creators Left Behind?

Of course, there’s another side to this story. One that deserves attention.

Some open source creators and maintainers feel left behind in this cloud-powered success story. Their argument is simple: hyperscalers are monetizing open source projects at massive scale, often without contributing back in proportion – either in engineering resources, funding, or visibility.

And they have a point. Popular tools like MongoDB, Redis, and Elasticsearch were widely adopted, then productized by cloud platforms without formal partnerships. As a response, these projects changed their licenses to restrict commercial use by cloud providers. That, in turn, led to forks like OpenSearch (from Elasticsearch), Valkey (from Redis), or OpenTofu (from Terraform).

Keine alternative Textbeschreibung für dieses Bild vorhanden

But this isn’t really a cloud problem, it’s an economic problem.

Open source used to be a side project or a contribution model. Today, it powers mission-critical infrastructure. That shift from volunteer-based innovation to always-on enterprise backbone created a funding gap. It’s no longer enough to push code to GitHub and wait for donations. Projects need full-time maintainers, security audits, documentation, roadmap planning, and long-term governance. That requires sustainable business models.

Cloud providers, on the other hand, rely on open source for customer value and velocity. Innovation doesn’t just come from inside hyperscaler walls, it flows in from the OSS community as well. The relationship is symbiotic. And it must evolve.

Yes, cloud vendors benefit from open ecosystems. But many are starting to give back – through engineering contributions, visibility programs, upstream engagement, and community funding. Oracle, for example, contributes to OpenJDK, GraalVM, and Helidon, and backs Linux Foundation efforts. Microsoft sponsors maintainers through GitHub Sponsors and supports dozens of OSS projects. Even AWS, who was long seen as an outsider, is now actively involved in maintaining forks like OpenSearch.

The path forward isn’t about choosing sides. It’s about redefining the balance: between freedom and funding, between platform and project. OSS maintainers need economic models that work. Hyperscalers need the trust and innovation open source brings. Everyone benefits when the relationship is healthy. Right?

Cloud and Open Source – Not a Rivalry, But a Partnership

The old “cloud versus open source” debate is no longer useful, because it no longer reflects reality.

We are not watching a rivalry unfold. We are witnessing mutual acceleration. Open source is the engine that drives much of today’s cloud innovation. And cloud platforms are the distribution channels that scale it to the world. One without the other? Still powerful, but far less impactful.

Today’s enterprise IT landscape is built on this pairing. We have Kubernetes running on managed clusters. It’s open telemetry pipelines feeding cloud-native observability. Then there is Linux, Postgres, Redis, and Java. All delivered as secure, scalable, managed services.

As you can see, behind the scenes, hyperscalers are contributing more than compute. They are actively investing in the open source ecosystem. And these aren’t isolated contributions, they signal a larger trend: cloud and OSS are no longer separate spheres. They are interdependent, each shaping the roadmap of the other.

And the real winners? Customers.

Enterprises benefit when innovation from open communities meets the scale, automation, and security of cloud platforms. You get the openness you want, and the reliability you need. You gain velocity without sacrificing visibility. You build on open standards while delivering business outcomes.

When cloud providers and OSS communities collaborate (and not compete), modern IT gets better for everyone.

Sustainable Collaboration

So, where does this go from here?

We are entering a phase where co-evolution between open source and cloud platforms becomes the norm. Sustainability is no longer just a community conversation. It’s becoming a core pillar of enterprise architecture and vendor strategy.

We will likely see a continued rise in permissive-but-protective licenses with models like Polyform, BSL, or even custom usage clauses that allow free adoption but limit monetization without contribution. These licenses won’t solve every conflict, but they are a step toward fairness by keeping projects open while preserving the creator’s ability to fund long-term development.

On the cloud provider side, we will see more intentional programs designed to give back. That could mean upstream engineering contributions, visibility via marketplace integration, or funding through sponsorships,

Meanwhile, OSS vendors and maintainers are moving beyond “just licenses” toward hybrid monetization. Some go SaaS-first. Some offer premium support or managed versions of their tools. We will also likely see more partnerships between OSS projects and cloud platforms, where integration, co-marketing, and joint roadmaps replace conflict with alignment.

And the payoff?

Enterprises will benefit the most. They will be able to build with the freedom and transparency of open source, while still consuming services with the resilience, automation, and support that modern business demands. No one wants to reinvent patching pipelines, build observability stacks from scratch, or manage HA for distributed databases. Managed services let teams focus on value, not plumbing.

The future isn’t about choosing between “cloud” or “open”, it’s about building systems that are both open and operable, both innovative and sustainable.

Because that’s the direction modern IT is already moving. Whether we plan for it or not.

Final Thoughts

Cloud platforms took tools from hobby projects and universities and turned them into the foundation of global infrastructure. That’s something worth acknowledging, even celebrating!

Of course, the discussion isn’t over. Sustainability matters. Transparency matters. But painting cloud providers as the problem risks missing the bigger opportunity.

Let us focus on building systems that are both open and operable. Let’s support OSS maintainers, not just in code, but in business. And let’s keep the conversation moving – not from a place of blame, but from a vision of shared success.