# Portability

> Hybrid by default. Multi-cloud, on-premise, and edge, because the runtime has to go where the data already is.

Source: https://brocs.fyi/run/portability/
Part of the surface: R · Run. Give the work somewhere to live.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Run surface

- Runtime: where apps and agents actually execute
- Data and state: provisioned, owned, backed up
- Secrets: injected at runtime, never in code or chat
- Provisioning: self-service, provision-build-deploy as one motion
- Portability: the runtime goes where the data goes


Portability is the ability to run the same workload somewhere else without rewriting it.
In BROCS it is not a hedge against vendor lock-in. It is a functional requirement,
because in a lot of organizations the data is not all in one place and it is not going to
be.

## The runtime goes where the data is

The sequence that plays out repeatedly: a company adopts an AI platform, it works, and
then a business unit says the data for their use case cannot leave their environment.
Sometimes that is a regulator, sometimes a customer contract, sometimes a country, and
sometimes it is simply a forty-terabyte dataset that is not moving.

At that point there are three options. Move the data, which is usually forbidden or
impractical. Exclude the business unit, which means the platform is not the platform.
Or run the same system in that environment, which requires that the system was built to
be run in more than one place.

The third only exists if you chose it in advance. It is not a feature you add later.

## What portability actually requires

It is less about avoiding every managed service and more about where the couplings are.

**Package the workload, not the environment.** Containers and declarative deployment, so
placement is a configuration decision rather than a rewrite.

**Abstract the model endpoint.** The application asks for a capability; something else
decides which provider or local model serves it. That is [routing](/control/routing/),
and it is what lets an on-premise deployment use a local model while the hosted one uses
a vendor endpoint, with the same application code.

**Abstract the data plane, within reason.** Object storage and SQL are portable in
practice. Bet on a proprietary queue or a vendor-specific vector service and you have
bought a rewrite.

**Keep identity federated.** The single most painful part of a second environment is
usually authentication. Federating to one identity provider from the start is cheaper
than reconciling two user directories later.

**Keep the control plane thin and the data plane self-sufficient.** If a workload in a
customer's datacentre stops serving when your central control plane is unreachable, it is
not deployed there in any meaningful sense.

## One system, everywhere, is a different claim

The weak version of portability is "we could migrate if we had to". The strong version,
and the one regulated enterprises actually need, is that the same platform runs in all
the places at once, managed the same way, with one set of policies.

The difference matters because the weak version still leaves you operating two systems
during the years it takes to move. A global organization with a data residency
requirement in three jurisdictions does not want a migration path. It wants one system
with three placements.

That has a design consequence: placement has to be a property of a workload rather than a
property of an installation. If choosing a different region means standing up a parallel
copy of your whole platform, you have built the weak version.

{{< aside title="How hybrid cloud thinks about this" >}}
The hybrid cloud lesson, learned expensively over a decade, is that the abstraction has
to be at the workload level rather than the infrastructure level. Attempts to abstract
whole clouds produced lowest-common-denominator platforms nobody enjoyed using.
Abstracting the deployment unit and the small set of interfaces it depends on worked.
Apply the same restraint here: abstract the model endpoint and the deployment unit, not
the entire cloud.
{{< /aside >}}

## Sovereignty is the sharp end

For some organizations this is not a preference. Public sector bodies, healthcare
providers, and financial institutions in several jurisdictions have legal constraints on
where processing occurs and who can compel access to it.

A platform that can only run in one vendor's cloud cannot serve those organizations at
all, regardless of how good it is. If they are in your market, or you are one of them,
portability is a gate rather than a nice-to-have, and the three sovereign paths
(local models, models through your own cloud account, and contractually covered
endpoints) all have to be live options rather than roadmap items.

{{< checklist >}}
- Your region is down right now. Can you build and run somewhere else, and how long does
  the switch take? The useful answer is a number somebody measured, not a capability.
- 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?
{{< /checklist >}}