Rule 2: We believe in "Region: Earth” and “Region: Regulatory Zone"
Where do you want your application to live? Everywhere. I want it to live everywhere my users care about. Businesses can achieve global scale while respecting local data-sovereignty and regulatory requirements. It is just that the current methodology of <NameYourCSP> East vs <NameYourCSP> West is a broken, outdated approach that modern AI developers should not be forced into. Don’t even get us started on multi-cloud, multi-region as we don’t want to hear it and we know you don’t either. (FWIW: Seaplane will never expose you to that pain train, we’d rather you and your AI-infused applications fly First Class. If you agree, please read on.)
How should applications think about location and data-sovereignty?
After doing over 350 research interviews with AI Developers, they were clear with us that the default deployment for their application should be “Region: Earth.” That doesn’t mean running everywhere, all the time, even when you have no traffic. It means starting globally and then dynamically delivering resources - CDN-style - where and when they are needed, without having to think about how to do that: just as you don’t allocate explicit locations with a CDN, it ‘magically’ scales and shifts with traffic. When you start by thinking of where the application’s users are and then moving resources to serve them - rather than where your infra is and hoping the users are nearby - the deployment solution looks very different.
Now that you can easily run anywhere on the planet, you can layer your business requirements and regulatory constraints in meaningful ways. When considering location and data-sovereignty, applications should view "geofencing" not as an abstract, complex concept, but as a simple, practical and structured approach to managing data in various regions. Think of it as dividing the world into clusters, each associated with a regulatory zone for developer-friendly identification.
Applications should then take into account the following key principles while being able to assume the existence of deployment locations in different regions, each linked to a regulatory zone. This simplifies the geographical segmentation for both the application and the AI Developer.
- Instance and Data Store Geofencing: Implement geofencing rules in the code at two levels - for an entire app instance and for explicit data stores. Developers should have the flexibility to simply tag and deploy multiple instances of the same app, each geofenced to different zones. Implicit data stores within an app instance should be geofenced automatically.
- User Responsibility: AI Developers deploying geofenced apps must be aware of the chosen regulatory zone for their application. If a developer, for instance, geofences an app to the US but uses an explicit data store in the EU, any resulting complications become their responsibility. However, you do know your application best.
- Automatic Geofencing: Ensure that by default, all data stores are geofenced automatically, unless explicitly overridden by the application. This prevents accidental sharing of a store between different geofences and helps maintain data-sovereignty.
- Scaling Concerns: Consider such production implementation concerns, such as replica count, to automatically respect geofences. This ensures that any configuration-related decisions align with the regulatory zones defined for the application.
- Regulatory Zones vs. Datacenter Regions: Emphasize the use of regulatory zones rather than "datacenter regions." This distinction is crucial for aligning geofencing with legal and business requirements, simplifying application compliance with local data-sovereignty regulations.
What does a system need to do when it comes to data-sovereignty?
To address data-sovereignty effectively, a system needs to incorporate measures such as automated geofencing for both app instances and data stores. This automation ensures consistency and reduces the likelihood of errors in defining and enforcing geofencing rules. The system should facilitate user-friendly deployment, guiding AI Developer on how to make informed decisions about geographical segmentation.
Strict isolation of data stores between geofenced areas is crucial to maintaining data-sovereignty and compliance. The system should allow developers the flexibility to override default geofencing settings when necessary, tailoring geofencing rules to meet specific application requirements.
Regulatory compliance is paramount, and the system should align with legal frameworks, data protection laws, and compliance standards relevant to each defined regulatory zone. Continuous monitoring mechanisms should be implemented to track and verify geofencing compliance, conducting real-time checks to prevent unauthorized data movement across regulatory boundaries.
By incorporating these principles into the system's design and functionality, applications can navigate the complexities of data-sovereignty with confidence, providing developers with a robust and compliant geofencing framework.
So what is the right solution for the AI Developer?
For the AI Developer, the right solution lies in utilizing a higher level of abstraction (We’ve chosen a Python SDK and a Global AI Platform or Runtime to start) with the simplicity and power it offers. The key directive is to leverage config.set_region() and trust the SDK and Runtime to seamlessly handle the rest of the intricacies. It's important to emphasize that the role of the SDK goes beyond merely passing through what the backend exposes – it actively contributes to enhancing user experience and simplifying complex processes.
When contemplating regions, two primary considerations come to the forefront for the AI Developer. Firstly, proximity to their audience is a crucial factor. The Runtime is designed to automatically handle proximity to application users, eliminating the need for developers to manually set a region for this purpose. Secondly, regulatory zones play a pivotal role. The SDK aligns region specifiers with regulatory zones to provide developers with clarity, ensuring that the app's compliance with specific regulations is provably evident from a single line.
Setting the region once in the SDK, especially with a focus on regulatory compliance, proves immensely beneficial. This setting then ripples downhill via the Runtime into other resources, automatically binding implicit state stores to the same region. Implicit state stores, created as part of a single app, are geofenced automatically, adhering to the constraints set for the app. In contrast, explicit state stores, managed by the developer in terms of lifecycle and geo tradeoffs, remain their responsibility.
The exact datacenter locations might not be a primary concern for the AI Developer, as the SDK and Runtime effectively address issues related to latency and regulatory compliance. The SDK assumes the responsibility of translating the developer’s application intent into various constraints when communicating with the Runtime to control all backend resources. This exemplifies a scenario where the SDK takes on product responsibility, ensuring a seamless translation process rather than a straightforward pass-through from the backend. In essence, the right solution for the AI Developer involves trusting the SDK to streamline creation, definition, simplify decision-making, and uphold compliance standards effortlessly, while the Runtime takes care of all operations.
Get Access Now!
Seaplane is where AI-infused applications take flight in 2024 so join us for this ride by signing up below. We are currently in Beta so make sure to sign up to secure your place in line and we’ll get to you as fast as we can.
Bring Your Apps to the World