Portability
Running the same workload across hosted and customer-controlled environments when data placement requires it.
Portability is the ability to run the same workload in another environment without a rewrite. It supports legal and practical data-placement requirements.
Placement near governed data
A business unit may have data that must remain in its environment because of a regulation, customer contract, residency rule, or transfer cost. The runtime then needs an approved placement close to that data.
Design for that placement before the use case arrives. Retrofitting portability after an application has adopted environment-specific services can require a substantial rewrite.
Portability requirements
Focus portability work on the dependencies that differ by environment:
Package the workload in containers with declarative deployment so placement remains a configuration decision.
Put model selection behind routing. An on-premise placement can use a local model while a hosted placement uses a vendor endpoint with the same application code.
Prefer portable data interfaces where requirements allow. Proprietary queues and vendor-specific vector services increase the work needed for another placement.
Federate each placement to the same identity provider. Separate user directories add reconciliation and deprovisioning work.
Keep local data-plane operations available during a central control-plane outage when the workload's availability requirements call for it.
Concurrent placements
A migration plan does not cover organizations that need several placements at the same time. Those deployments need the same management and policy model across each location.
A global organization may run one platform in several jurisdictions to meet residency requirements. Treat placement as a workload property so a region change does not require a separate platform installation.
Data sovereignty
Public sector bodies, healthcare providers, and financial institutions can face legal constraints on processing location and compelled access.
Teams subject to those constraints may need local models, models served through their cloud account, or contractually covered endpoints. Keep the required route operational and included in deployment tests.
Questions to ask your vendor, or your own team
- Your region is down right now. Can you build and run somewhere else, and how long does the switch take? Report a measured duration and the dependencies on the critical path.
- Of that switch time, how much is compute and how much is state: replica lag, and the hours and the embedding bill to rebuild the vector index?
- Could you run your primary AI workload in a different cloud next quarter? What exactly would break?
- Is the model endpoint an abstraction, or does application code name a provider?
- If your central control plane were unreachable for a day, would deployed workloads keep serving?
- Do you have a data residency requirement today? Will you within a year?
- Is placement a property of a workload, or does a new region mean a new installation?
- Which proprietary services are you coupled to that have no portable equivalent?