In the debate over IT modernization, a comfortable yet dangerous narrative has taken hold: the idea that cloud sovereignty is a spectrum, a scale of greys where "a little compliance" is still a step in the right direction.
Either you have effective control over your data and processes, or you depend on someone else. Either you can unilaterally decide where and how to run a critical workload, or you are bound by technical, contractual, and jurisdictional choices you do not control.“There are no half measures. Sovereignty is binary: you either have it, or you don't.”For IT leaders today, the issue is not chasing the latest tech trend or the next provider certification. The real stake is guaranteeing Absolute Autonomy: the ability to operate independently of the roadmaps, policies, and jurisdictions of cloud providers.Sovereignty is not a feature you wait for a vendor to release; it is a business imperative you must enforce. The answer is not relying on provider promises, but securing autonomy through the right architecture.
For years, the Exit Strategy has been treated as a contractual footnote. Today, with regulations like DORA and the Data Act, it has become a structural requirement.The question every CTO should ask is brutal but necessary: "If I were forced to abandon our current cloud provider tomorrow morning, how much time and budget would I need?"If the answer is "months" and "millions," sovereignty is already lost.True sovereignty is measured by the reversibility of choices. A solid architecture must separate what generates value data, applications, processes from the underlying infrastructure. It is not enough to containerize. It is not enough to abstract APIs.The goal is not to build complex infrastructure from scratch, but to leverage an independent control plane. This layer must deliver the efficiency of PaaS and the freedom of portability, without the operational burden of managing raw VMs.The goal is clear: transform the Exit Plan from a theoretical document into a technical capability that can be activated on demand.
Sovereignty is about jurisdiction. Data sovereignty requires that service providers guarantee compliance with the laws of the nation where the data is generated at all times.Why is sovereignty so difficult to achieve? It is not just a matter of regulations; it is a structural failure in how we approach the cloud market. We are currently facing a paradox that requires immediate action from all players.The Gap in Capabilities: let’s be honest about the trade-offs. Global vendors provide cutting-edge capabilities (PaaS, SaaS, FaaS) but struggle to guarantee total independence. Local vendors guarantee the territory but often fail to provide the advanced services businesses need to compete, offering mostly raw infrastructure (IaaS).The Engineering Responsibility: However, the biggest bottleneck is often internal. Too many businesses have adopted a passive approach, building rigid architectures with poor Infrastructure as Code (IaC) practices that create deep dependencies on specific providers.The Path Forward: The industry needs to wake up. We cannot build our future on the hope that global vendors will change their nature or that local vendors will suddenly become tech giants overnight.· Local Providers must accelerate their innovation and move beyond basic hosting.· Businesses must stop blaming the market and start improving their architectures.The goal is to design systems where the "intelligence" resides in your control plane, not in the provider’s proprietary features. Only by decoupling your business logic from the underlying infrastructure can you achieve true sovereignty without sacrificing performance.
Major hyperscalers offer top tier services. But their model is based on economies of scale, not on optimizing for the specific constraints of every organization, country, or regulated sector. Waiting for the provider to introduce "the right feature" is a passive strategy. And risky.The correct approach is more radical. Consider the cloud provider for what it really is: a commodity.You need a truly independent control plane that, regardless of the underlying infrastructure, is capable of:· Governing identities and access.· Applying localization and segregation constraints.· Orchestrating workloads and lifecycles.· Enforcing consistent policiesIf the cloud does not offer a critical isolation or control feature, the provider does not need to change. Your architecture must supply that capability independently.
An infrastructure designed for Absolute Autonomy produces an immediate effect beyond compliance: it restores control to the company.When you know you can move critical assets between different clouds, or from cloud to on-premise, within certain and predictable timeframes, vendor lock-in loses its meaning. Compliance stops being a cost to absorb and becomes a concrete guarantee for customers, partners, and stakeholders.There are no middle grounds. There are those who control their digital destiny and those who hope everything continues to work. The difference is not in the cloud vendor you choose, it is in the architecture you decide to adopt.
Fractal Cloud was designed to bridge this exact gap. We empower Local Cloud Providers to upgrade their offerings instantly by deploying a ready-to-use PaaS layer on top of their IaaS. At the same time, we enable Enterprises to decouple their architecture from specific vendors, making their Infrastructure as Code truly agnostic and portable.It does not act as "another cloud," but as a platform engineering layer that allows companies to maintain control over their workloads, regardless of where they run.Fractal Cloud deliberately separates the control plane from the infrastructure, allowing governance, security, and operations to be coded once and applied consistently across public, private, or hybrid environments. In this model, the cloud returns to being a commodity. Sovereignty remains yours.It is not a promise. It is an architectural style.
January 22, 2026
4 min read
Michel Murabito
In the debate over IT modernization, a comfortable yet dangerous narrative has taken hold: the idea that cloud sovereignty is a spectrum, a scale of greys where "a little compliance" is still a step in the right direction.
Provisioning is just the beginningIn the lifecycle of cloud infrastructure, provisioning is often seen as the finish line. Once the environment is defined and deployed, the job feels done. The code has been reviewed, the resources are running, services are responding. From that point on, it seems like it’s just a matter of keeping things going.But in reality, that’s when the most critical part begins. That’s where the real cost of infrastructure starts to surface (the part you don’t see immediately), but that gradually becomes heavier with time. Environments that were supposed to be identical begin to behave differently. Security patches are applied in some places, missed in others. Configuration drifts start to appear. Coherence slowly fades, and with it, confidence in the system.If you've worked in production, you know this too well. Many incidents don’t happen during provisioning, but weeks or months later when something that was working just fine suddenly fails. The root cause isn’t always in the code. Often, it lies in what changed over time, unnoticed and unmanaged.
"Cloud-Agnostic" is one of the most seductive and misunderstood buzzwords in our industry. For years, we've been sold a utopia: the promise of building an application once and then freely moving it between AWS, Azure, and GCP with a single click, as if they were interchangeable utilities.In 2025, it's time to say it clearly: this idea no longer reflects the complexity of real-world cloud architectures.Chasing the "run anywhere" myth leads companies to build bland, lowest-common-denominator systems that fail to leverage the true power of any cloud. You end up paying the price of the cloud without enjoying its main benefits.But this doesn't mean the idea is worthless. It just means the real value isn't where we've been told to look. True "cloud-agnostic" isn't about implementation portability; it's about architecture standardization.