Containers are supposed to solve "works on my machine."
They often do, right up until you move the application to a different environment.
A workload can have a Dockerfile, production container images, mature Helm charts, and years of Kubernetes experience behind it, and still require real engineering work before it will run somewhere new. The problem is not usually the container itself. It is the assumptions hidden around it.
Applications make assumptions about networking, identity, certificates, storage, CPU architecture, filesystem behavior, outbound connectivity, cloud services, and the platform they were originally built to run on. Helm charts can encode even more of those assumptions. Most of them stay invisible until the application leaves the environment where they were originally satisfied.
This talk explores the difference between a containerized application and a portable one, using patterns drawn from real application onboarding and platform integration work.
A major focus will be the distinction between configuration effort and engineering effort. Changing an endpoint, providing a secret, or supplying a certificate is configuration. Changing an application because it assumes internet access at startup, depends on a specific identity model, requires privileged execution, or cannot support a different trust model is engineering.
Attendees will learn how to recognize these portability smells earlier, ask better questions before migration work begins, and evaluate whether a target environment can be expressed through configuration the application already supports, or whether the application itself needs to change.
Containers make environments more reproducible.
Portability is something the application still has to earn.
