Why did shipping software in containers change how it runs?

Containers changed how software runs because a program can now travel together with everything it needs, and run in the same way anywhere. A container is not a whole imitation computer. It is an isolated slice of one operating system: the kernel allows multiple isolated user space instances, and a program inside one can only see the container's contents and the devices assigned to it, while a program on an ordinary system sees every resource of the machine.

Before this, organizations ran applications on physical servers with no way to define resource boundaries between them, which caused resource allocation problems. Virtual machines solved that by giving each application a full machine with its own operating system. Containers are similar, but with relaxed isolation, because they share the host's operating system. That makes them lightweight, and it usually means less overhead than full virtualization, since no emulation or intermediate virtual machine is needed.

The idea has deep roots. On Unix-like systems it is an advanced version of chroot, a mechanism introduced in Version 7 Unix in 1979 that changes the apparent root folder of a process. Docker, the tool that made containers easy to package and ship, came from Solomon Hykes, who started it as an internal project at dotCloud, a platform-as-a-service company in France. Docker debuted at PyCon in Santa Clara and was released as open source in March 2013.

Its promise was environmental consistency: a container runs the same on a laptop as it does in the cloud. There is a trade-off, however. Because containers share one kernel, they cannot host a different operating system kernel, and security threats can affect the whole containerized system.