A lesson from 1917
In January 1917, Germany sent a secret telegram.
It went to Mexico. The offer: join the war against the United States, and you can have Texas, Arizona and New Mexico back. The Germans were careful, and they put it in a cipherin cipher.
Their own transatlantic cables had been cut, so they sent it the only convenient way left, down lines that ran through British territory, part of it on an American cable.
The cable was described as private. Contractually, and because they had encoded the message.
Except Britain was quietly tapping those wires. A room of codebreakers in the Admiralty, Room 40, read the whole thing. Six weeks later, it was on the front page of every American newspaper. Not long after, the United States was at war.
It doesn’t matter whose message it is. If it runs on infrastructure you don’t control, whoever controls it can read it.
A modern sovereignty challenge
That century-old lesson is having a very modern moment. Earlier this year, a US hyperscaler was reported to have handed the US Congress documents belonging to regulators at two Dutch authorities: emails, minutes, meeting invites. The people whose job is enforcing Europe’s Digital Services Act against US tech.
The records were reportedly handed over with names left unredacted, in effect a ready-made list of the people holding US giants to account. Whatever the specifics, it shifts the data sovereignty picture in a way worth sitting with.
The mechanism is the US CLOUD Act. It can compel an American company to surrender data even when that data sits on European soil. In sworn testimony to the French Senate, a provider’s own counsel could not guarantee that French data held in European data centers was safe from quiet US access.
So “our servers are in Frankfurt” turns out to mean very little.
This is the distinction the cloud native community keeps coming back to: data residency is not data sovereignty. Residency is where the bytes physically sit. Sovereignty is who has legal reach over them. Frankfurt gives you the first. The operator’s jurisdiction decides the second, and jurisdiction travels with the operator, not the postcode.
A structural rather than vendor specific issue
It’s tempting to make this a story about a single company. It isn’t.
The provider in the headlines followed the law it’s bound by. Swap in any US hyperscaler and the answer is the same. That’s the point: the risk is structural, not reputational. Picking a “better” operator inside the same jurisdiction leaves it exactly where it was.
Every dependency you don’t control is a risk you’ve deferred.
You don’t feel it on the day you sign. You feel it the day the terms change, the price jumps, the subpoena lands, or the supplier you built your whole stack on decides your use case isn’t a priority anymore.
The bill was always there. It was just scheduled for later.
Making informed infrastructure choices
We’re not telling you to rip out your cloud and move to a shed. That’s its own kind of silly, and it throws away the genuine leverage that managed services give you.
We’re advising you to identify which bills you’ve deferred and decide whether you’re comfortable holding them.
For the things that don’t matter, convenience is the right call. Rent it. Outsource it. Don’t think about it again.
Then there are the things that do: the data that would end careers if it leaked, the systems a regulator will ask about, the layer your whole business runs through. For those, ownership and sovereignty are worth the friction.
That’s the quiet, unglamorous case for open source and for infrastructure you can run yourself. Not ideology. The boring freedom of knowing where your data lives, who can reach it, and what happens when the relationship sours.
Where cloud native fits
That freedom is buildable today, and much of it is already sitting in the CNCF landscape. Cloud native technologies make these deployment choices practical by emphasizing portability, open standards, and interoperable components. Four questions are worth asking of any critical system.
Where does it run?
Container orchestration platforms such as Kubernetes provide a consistent deployment substrate across public clouds, private infrastructure, and regional or sovereign cloud providers. A workload packaged once can run on a hyperscaler, in your own data center, or on a sovereign cloud, using the same manifests.
Who can observe it?
OpenTelemetry lets organizations collect traces, metrics, and logs using open standards and send them to a backend they choose and host, so the operational picture stays somewhere they can export it from.
Who defines policy?
Open Policy Agent (OPA) puts fine-grained authorization and governance decisions into policy you own and version, enforced consistently across the stack, so the rules travel with your code into every environment it runs in.
How are APIs governed?
API gateways that support open standards such as OpenTelemetry, OpenAPI, OAuth, and Open Policy Agent enable organizations to apply consistent governance and security policies while maintaining control over where data planes are deployed. A gateway of this kind can enforce regional data sovereignty policy across self-managed, cloud, hybrid, and containerized deployments from a single control plane.
The list itself is less important than what it demonstrates. The boring freedom of knowing where your data lives, who can access it, and what happens when a relationship sours is available now, built on mature open-source software you can run anywhere.
Convenience and control
Operational convenience is valuable for a reason, and cloud native technologies do not eliminate the engineering effort required to operate infrastructure. Running your own infrastructure is more work than renting someone else’s, right up until the morning it isn’t.
Data sovereignty turns out to be less about where infrastructure sits than about who controls it, which legal frameworks reach it, and how much flexibility you keep when your requirements change.
If your critical layer runs on infrastructure you don’t control, you’ve accepted that someone else can read your mail. If it’s open source, runs without a black box, and you can run it where you choose, the wires are yours.
Facts Only
* In January 1917, Germany sent a secret telegram to Mexico regarding joining a war against the United States, offering Texas, Arizona, and New Mexico in return.
* The message was transmitted via lines running through British territory and part of an American cable.
* A room of codebreakers in the Admiralty read the telegram.
* The US entered the war shortly after the message's interception.
* A US hyperscaler reportedly handed documents belonging to European regulators (emails, minutes, meeting invites) to a US hyperscaler.
* The US CLOUD Act allows compulsion of American companies to surrender data even when it resides in European data centers.
* Data residency is defined by where bytes physically sit; sovereignty is determined by legal reach.
* Cloud native technologies emphasize portability and open standards.
* Open source tools like Kubernetes, OpenTelemetry, and Open Policy Agent are cited as mechanisms for achieving portable control.
* API gateways supporting open standards can enforce regional data sovereignty policies across deployments.
Executive Summary
A historical lesson from 1917 regarding infrastructure control is presented as a parallel to modern data sovereignty challenges. A secret telegram was sent by Germany in January 1917 to Mexico proposing a war alliance, transmitted through lines crossing British and American territories, which was intercepted by the British Admiralty. This event established the principle that control over underlying infrastructure dictates access to information, regardless of contractual agreements or physical location.
This historical context is applied to contemporary issues involving data governance. The text points to mechanisms like the US CLOUD Act, which allows US authorities to compel companies to surrender data held in foreign jurisdictions, challenging the notion that physical data residency equates to data sovereignty. The core distinction drawn is between data residency (physical location) and data sovereignty (legal reach).
The narrative suggests that control over infrastructure creates structural risk: if critical systems run on infrastructure not controlled by an entity, external control remains possible regardless of operational agreements or reputational concerns. This necessitates a focus on owning or controlling the underlying technology layer to ensure agency over data.
Full Take
The narrative establishes a pattern where historical precedents concerning infrastructure control are leveraged to frame contemporary debates over digital governance. The central implication is that control over physical infrastructure, rather than mere contractual terms or vendor identity, determines ultimate legal and operational agency over data. This suggests a deep-seated structural skepticism toward outsourced or opaque systems.
The move from reputational risk management (vendor selection) to structural risk management (infrastructure dependency) is a critical shift in framing the problem. The analysis moves from an anecdotal focus on a single vendor to a systemic critique of dependency chains, asserting that the risk is inherent in the architecture itself rather than merely a flaw in implementation.
The proposed solution—prioritizing open source and self-managed infrastructure—is presented not as an ideological choice but as a pragmatic strategy for maintaining cognitive sovereignty against structural power imbalances embedded in contemporary technology stacks. The pattern observed is one of realizing that freedom resides in controlling the mechanisms of access, which are often invisible in terms of standard contract law or surface-level compliance. The unstated assumption is that complex systems are inherently tools for centralized control, and the resulting imperative is to seek granular control over the physical and logical layers upon which operations occur.
Bridge Questions: If data residency is not sovereignty, what specific legal frameworks must evolve to address jurisdiction where data flows across multiple sovereign boundaries? How can organizations practically operationalize the principle of "ownership" when infrastructure relies on distributed, shared resources? What structural changes are necessary within the legal and technical ecosystems to ensure that operational convenience does not default into relinquishing fundamental control?
Sentinel — Human
The text presents a coherent argument connecting historical concepts of control and data flow to modern data sovereignty challenges in the cloud, focusing on structural dependencies rather than vendor specifics.
