Container Networking is an emerging application sandboxing mechanism used in home desktops and web-scale enterprise networking solutions similar in concept to a virtual machine. Isolated inside the container from the host and all other containers are a full-featured Linux environment with its own users, file system, processes, and network stack. All applications inside the container are permitted to access or modify files or resources available inside the container only.

It is possible to run multiple containers at the same time, each with their own installations and dependencies. This is particularly useful in instances when newer versions of an application may require a dependency upgraded that may cause conflicts with other application dependencies running on the server. Unlike virtual machines, containers share host resources rather than fully simulating all hardware on the computer, making containers smaller and faster than virtual machines and reducing overhead. Particularly in the context of web-scale applications, containers were designed as a replacement to VMs as a deployment platform for microservice architectures.

Containers also have the characteristic of portability, for example, Docker, a container engine, allows developers to package a container and all its dependencies together. That container package can then be made available to download. Once downloaded, the container can immediately be run on a host.

A container network is a form of virtualization similar to virtual machines (VM) in concept but with distinguishing differences. Primarily, the container method is a form of operating system virtualization as compared to VMs, which are a form of hardware virtualization.

Each virtual machine running on a hypervisor has their own operating system, applications, and libraries, and are able to encapsulate persistent data, install a new OS, use a different filesystem than the host, or use a different kernel version.

Conversely, containers are a “running instance” of an image, ephemeral operating system virtualization that spins up to perform some tasks then is deleted and forgotten. Because of the ephemeral nature of containers, system users run many more instances of containers than compared to virtual machines requiring a larger address space.

To create isolation, a container relies on two Linux Kernel features: namespace and cgroups. To give the container its own view of the system isolating it from other resources, a namespace is created for each of the resources and unshared from the remaining system. Control groups (Cgroups) are then used to monitor and limit system resources like CPU, memory, disk I/O, network, etc.

Containers are becoming rapidly adopted, replacing VMs as a platform for microservices.

Containers have several key benefits:

• Run Containerized Apps Alongside Existing Workloads: Machines can run containerized apps alongside traditional VMs on the same infrastructure, granting flexibility and speed.
• Combine Portability with Security, Visibility, and Management: Because of the inherent design of containers it allows for greater security through sandboxing, resource transparency with the host, task management, and execution environment portability.
• Leverage Your Existing Infrastructure and Scale Easily: Use your existing SDDC to avoid costly and time-consuming re-architecture of your infrastructure that results in silos - silos occur when distinct departments maintain their own IT infrastructure within the same organization. This “silo effect” creates problems when rolling out organization-wide IT policies and upgrades due to the differences in technical configurations in each department. Reintegrating silos is a costly and time-consuming process that can be avoided through container networking.
• Provide Developers with a Docker-Compatible Interface: Developers already familiar with Docker can develop applications in containers through a Docker-compatible interface and then provision them through the self-service management portal or UI.