This is the third in my series on midstream geospatial engineering: So, mid. To catch up, read: The missing midstream and The break of gauge.
That word again. It’s like “dual-use”, annoyingly investor-y without any real explanation. Everyone gets to define their own sovereignty, for the convenience of their own argument or product. I guess that’s the power of language. For the purposes of this discussion, sovereignty means “keeping your own stuff where you want it.” Which is interesting because sovereignty is then aligned with ownership. Therefore, the sovereignty of a data product or system is defined in its midstream engineering: where the data is and how it is accessed.
So, the punchline up front:
Compute alongside Storage == Sovereignty.
The Cloud-Native Geospatial movement, it turns out, does a great job of addressing the questions of sovereignty and ownership. Cloud-native is not about moving data but instead asking questions of it. If the data stays where it was originally put and its custodian gets to decide who interacts with it.
I feel the geospatial community is currently undergoing a renaissance of thought about data ownership, access, and, dare I say it, licensing. For quite some time, we have been very keen on openness, especially when it comes to data. Even the most proprietary companies support and encourage open data. But open data is again being questioned. Open to whom? Or, a better question: open to what?
The previous dominant design for data use in computing was to make a copy of a piece of data and store it on an accessible machine. That expanded to storing a copy on a server; then to buying and selling ownership of pixels. Ultimately, we are now moving those pixels to different S3 buckets, often on the same cloud. So, the same pixels are stored numerous times across the internet. We laugh at people who buy and sell NFTs, yet here we are in geospatial, buying pixels with restricted licenses that only some people can look at. Yet those same pixels can be sold with a different license for a different group of people. More often than not, little provenance or lineage is provided; we just trust the pixels are representative. I should really brand geoNFTs*, and we should laugh, because it’s not at all how the cloud is supposed to work. But the joke is on us, or worse, the taxpayer, because what we are doing is really expensive.
Additionally, every copy is a loss of control.
If I allow my data to be downloaded, it is not sovereign; it is under someone else’s control. Indeed, different versions of it could be under the control of numerous people all across our planet. There might be a license attached to it indicating how desperately upset I would be with the data’s misuse. But in the end, bad people will do what they will with the data, with or without a license: the data has left my locus of control.
First, I want to dispel a fallacy. Cloud-native doesn’t require a hyperscaler. The hyperscalers have wonderful tools, and all the modern conveniences of infinite compute (within a fiscal reality). But you can take cloud-native philosophies and build your own cloud; it’s just someone else’s computer, after all.
The internet is a network of computers that talk to each other. A cloud is a network of many computers that can communicate with each other quickly or with the internet a little more slowly (speed, distance, time, you get it). We obviously have clouds of clouds these days, and more compute coming online every day. So when we talk about Cloud-native, we are suggesting using that vast storage capability to store data and our networks to send much smaller requests and responses.
That’s the key. But it’s hard because this is a newer pattern.
This pattern requires orchestration and access to compute alongside stored data. That compute must be able to interpret a request, interrogate the data, and provide an answer. Go and take a look at the UK’s Earth Observation Data Hub for an example.
This activity is not novel; at Sparkgeo, we have been following this or similar patterns for decades, others even longer. But it’s still not the dominant design. At the excellent Cloud-Native Geospatial Forum in Utah a week or two ago, there must have been 200-300 keen practitioners, but I suspect that might be a large proportion of those doing this kind of work.
So how does that give you sovereignty? If I allow users to connect to a piece of data via a request, perhaps through a Python notebook, an API, or an MCP service, then I can choose to deny or satisfy them based on agreements and purchase orders. Perhaps I provide authorization to “work with” the data; if I subsequently withdraw those rights, then those users cannot touch the data. So the data’s sovereignty is managed, and where it lives (the word soil seems important here) is my choice as the custodian.
Using a cloud-native approach, access is managed through software, so the software orchestration layer, the midstream, becomes the key to access. And access is as much about authentication and authorization as anything. While not without complication, data sovereignty can be managed.
Implicit in this discussion is a reference to MCPs and APIs using cloud-native technology. Prompts are becoming the de facto interface for computing; this may evolve to speech. But it means that access to data via MCP or similar is a major enabler for the practice of digital geography. It now means that if we build appropriate systems, non-experts can start asking robust geospatial questions.
This works for middle powers, but it’s also about data trusts, corporate networks, trusted contractors, campuses, club goods, inter-agency sharing, project-level compartmentalization, and privacy.
Think about a group of countries that want to share data. Each country may have a different data set that they would all benefit from in aggregate.
Each country can store its own data on its own soil (there, you see?) whilst an orchestration layer allows access to the group as long as the agreement is in place. Upon termination of the agreement, data sovereignty is still assured. This pattern is enabled by Cloud-native technology. In fact, the idea of a virtual yet still sovereign constellation is entirely possible.
*Turns out geoNFTs actually exist
If you are interested in cloud-native technology for your enterprise, Sparkgeo has assembled a selection of cloud-native tools and practices into a convenient package called Prescient. We’ve done the packaging and wrapped it with enterprise-ready features like auth and multitenancy, making cloud-native technology more accessible for no-fail environments. Get in touch.