Think of a container as just another process running in the machine; it's just that they offer a lot more isolation than a normal process does. So, we define a container as an isolated process. A container can have its own filesystem, own network IP address, own hostname, own registry, own unique resources and so on. A question that would come to mind is: Why Containers? In the modern world, where new software comes in and changes overnight, there are numerous challenges in:

1. Discovering the software: There is no single point at which to find all software. A few are available as executables on the developer sites, a few in platform-specific application stores, a few as package managers, and so on and so forth.
2. Installing the software: Software can be installed on specific OS, CPU architectures, OS versions, and build versions with the relevant prerequisites. Over a period of time, this becomes messy and confusing.
3. Running the software: We have all faced the issue where I am unable to find that software that I  downloaded. Applications that are installed and updated in the registry are easy to find but the ones that run as stand alone executables are more likely to missed. On top of that, we have licensing, upgrades, documentation, paths, and so on to take care of if we wish to run the software. On top of it, are we 100% sure that the executable that we are running is secure and would not cause a security breach if it's run on the machine?

These slightly over exaggerated points highlight that there are challenges a plenty in discovering, installing, and running software. Containers are about software and relieve much of this pain. Just as shipping containers allow goods to be transported by ship, train, or truck regardless of the cargo inside, software containers act as a standard unit of software that can contain different code and dependencies. Containerizing software this way enables developers and IT professionals to deploy them across environments, with little or no modification. Containers also isolate applications from each other on a shared OS. Containerized applications run on top of a container host that in turn runs on the OS (Linux or Windows). Containers therefore have a significantly smaller footprint than virtual machine (VM) images. There is a myth that containers are replacements for VMs, which is incorrect. Containers require fewer resources than VMs, and hence a server can host more containers than VMs, making choice easier when there is a confusion. There are a number of containers available in the market today such as LXC, Docker, and so on. We will use Docker as our container, and will discuss it next.