CONCEPT Cited by 1 source
Environmental parity¶
Environmental parity is the principle, applied during a platform migration, that the new runtime environment must be indistinguishable from the old one from user code's point of view. The execution engine underneath can change (Kubernetes → SageMaker, EC2 → Lambda, VMs → Firecracker), but credentials, environment variables, metrics endpoints, hyperparameter input paths, file-system layout, network addressing, and any other primitive user code observes must behave identically on both sides.
Why it's the right target (not "runs on the new platform")¶
Naïve migration frames success as "workloads run on the new substrate". That goal is too weak: workloads can run on the new substrate while subtly differing in dozens of behaviours (credential fetch timing, metric flushing frequency, hyperparam size limits, sidecar presence), and each subtle difference becomes a latent bug or a support ticket.
Environmental parity is a stronger, more testable goal:
- It makes compatibility issues surface as parity bugs (concrete, reproducible), not as "works differently".
- It lets the migration proceed repository-by-repository without user teams rewriting anything — the parity contract is what makes user code portable.
- It pairs naturally with the concepts/zero-code-change-migration constraint: if parity holds, no code needs to change, by construction.
Implementation techniques¶
- Container-entrypoint compatibility layers re-synthesise missing primitives at container startup on the target platform.
- Cross-platform base images let one image work in multiple execution contexts by detecting its runtime environment and adapting env vars, users, networking, and framework config.
- patterns/runtime-fetched-credentials-and-config covers the specific parity case where the target platform's API can't match the source platform's primitive (size limits, no sidecars, no webhooks).
Lyft / LyftLearn 2.0 instance¶
Lyft's LyftLearn 2.0 migration reframed its Kubernetes → SageMaker compute move as an environmental-parity problem: the SageMaker-side base image had to fetch Confidant credentials at startup (replacing K8s webhook injection), reconfigure StatsD to a gateway (replacing absent sidecars), pull hyperparameters from S3 (replacing ConfigMap mounts), and emit the same environment shape to user code. The "real task wasn't just running a container on a different platform — it was ensuring environmental parity" (Source: sources/2025-11-18-lyft-lyftlearn-evolution-rethinking-ml-platform-architecture).
Seen in¶
- sources/2025-11-18-lyft-lyftlearn-evolution-rethinking-ml-platform-architecture — Lyft explicitly names environmental parity as the migration target; entire compatibility layer is organised around it.