The Docker philosophy is often explained in terms of a shipping container metaphor, which presumably explains the Docker name. The story normally goes something like this:
When goods are transported they have to pass through a variety of different means, possibly including trucks, forklifts, cranes, trains and ships. These means have to be able to handle a wide variety of goods of different sizes and with different requirements (e.g., sacks of coffee, drums of hazardous chemicals, boxes of electronic goods, fleets of luxury cars and racks of refrigerated lamb). Historically, this was a cumbersome and costly process requiring manual labor, such as dock workers to load and unload items by hand at each transit point.
The transport industry was revolutionized by the introduction of the intermodal container. These containers come in standard sizes and are designed to be moved between modes of transport with a minimum of manual labor. All transport machinery is designed to handle these containers, from the forklifts and cranes to the trucks, trains and ships. Refrigerated and insulated containers are available for transporting temperature sensitive goods, such as food and pharmaceuticals. The benefits of standardization also extend to other supporting systems, such as the labeling and sealing of containers. This means the transport industry can let the producers of goods worry about the contents of the containers so that it can focus on the movement and storage of the containers themselves.
The goal of Docker is to bring the benefits of container standardization to IT. In recent years, software systems have exploded in terms of diversity. Gone are the days of a LAMP stack running on a single machine. A typical modern system may include Javascript frameworks, NoSQL databases, message queues, REST APIs and backends all written in a variety of programming languages. This stack has to run partly or completely on top of a variety of hardware —from the developer’s laptop and the in-house testing cluster to the production cloud provider. Each of these environments is different, running different operating systems with different versions of libraries on different hardware. In short, we have a similar issue to the one seen by the transport industry —we have to continually invest substantial manual effort to move code between environments.
Much as the intermodal containers simplified the transportation of goods, Docker containers simplify the transportation of software applications. Developers can concentrate on building the application and shipping it through testing and production without worrying about differences in environment and dependencies. Operations can focus on the core issues of running containers, such as allocating resources, starting and stopping containers and migrating them between servers.