What are Docker containers?
Docker containers are lightweight application hosting environments. Like VMs, they are designed to be easily portable between different computers and isolate workloads.
However, one of the main differences between Docker and VMs is that Docker containers share OS resources with the server that hosts the Docker containers. VMs use a virtualized guest OS instead.
Because sharing an OS consumes fewer resources than running standalone guest OSes on top of a host OS, Docker containers are more efficient, and admins can run more containers on a single host server than VMs. Docker containers also typically start faster than VMs because they don’t boot a complete OS.
Docker vs. other container runtimes
Docker is only one of several container engines available, but there is some ambiguity surrounding the term Docker containers.
Technically speaking, the most important aspect of Docker is its runtime, which is the software that executes containers. In addition to Docker’s runtime, which is the basis for containerd, modern containers can also be executed by runtimes like CRI-O and Linux Containers.
Most modern container runtimes can run any modern container, if the container conforms with the Open Container Initiative standards. But Docker was the first major container runtime to gain widespread adoption, and people still use Docker as a shorthand for referring to containers in general — like how Xerox can be used to refer to any type of photocopier. Thus, when people talk about Docker containers, they are sometimes referring to any type of container, not necessarily containers designed to work with Docker alone.
That said, the nuances and semantics in this regard are not important for understanding Docker use cases. Almost any use case that Docker supports can also be supported by other mainstream container runtimes. We call them Docker use cases throughout this article, but we’re not strictly speaking about Docker alone here.
Docker use case examples
Docker containers can deploy virtually any type of application. But they lend themselves particularly well to certain use cases and application formats.
Microservices-based apps
Applications designed using a microservices architecture are a natural fit for Docker containers. This is because developers can deploy each microservice in a separate container and then integrate the containers to build out a complete application using orchestration tools, like Docker Swarm and Kubernetes, and a service mesh, like Istio or VMware Tanzu.
Technically speaking, you could deploy microservices inside VMs or bare-metal servers as well. But containers’ low resource consumption and fast start times make them better suited to microservices apps, where each microservice can be deployed — and updated — separately.
Pre-deployment application testing
The ability to test applications inside Docker containers and then deploy them into production using the same containers is another major Docker use case.
When developers test applications in the same environment where the applications will run into production, they don’t need to worry as much that configuration differences between the test environment and the production environment will lead to unanticipated problems.
Early application development
Docker comes in handy for developers who are in the early stages of creating an app and want a simple way to build and run it for testing purposes. By creating Docker container images for the app and executing them with Docker or another runtime, developers can test the app from a local development PC without execution on the host OS. They can also apply configuration settings for applications that are different from those on the host OS.
This is advantageous because application testing would otherwise require setting up a dedicated testing environment. Developers might do that when applications mature and they need to start testing them systematically. But, if you’re just starting out with a new code base, spinning up a Docker container is a convenient way to test things without the work of creating a special dev/test environment.
Multi-cloud or hybrid cloud applications
Docker containers are portable, which means they can move easily from one server or cloud environment to another with minimal configuration changes required.
Teams working with multi-cloud or hybrid cloud architectures can package their application once using containers and then deploy it to the cloud or hybrid cloud environment of their choice. They can also rapidly move applications between clouds or from on premises and back into the cloud.
Deploying OS-agnostic applications
The same Docker container can typically run on any version of Linux without the need to apply special configurations based on the Linux distribution or version. Because of this, Docker containers have been used by projects like Subuser as the basis for creating an OS-agnostic application deployment solution for Linux.
That’s important because there is not generally a lot of consistency between Linux distributions when it comes to installing applications. Each distribution or family of distributions has its own package management system, and an application packaged — for example, Ubuntu or Debian — cannot typically be installed on a Linux distribution, like RHEL, without special effort. Docker solves this problem because the same Docker image can run on all of these systems.
That said, there are limitations to this Docker use case. Docker containers created for Linux can’t run on Windows and vice versa, so Docker is not completely OS-agnostic.
Cost control
The efficiency of Docker containers relative to VMs makes Docker a handy option for teams that want to reduce how much they spend on infrastructure. By taking applications running in VMs and redeploying them with Docker, organizations will likely reduce their total resource consumption.
In the cloud, that translates to lower IaaS costs and a lower cloud computing bill. On premises, teams can host the same workloads with fewer servers, which also translates to lower costs.
When not to use Docker
While Docker comes in handy for many use cases, it’s not the best choice for every application deployment scenario.
Common reasons not to use Docker include the following:
- Security considerations. Applications that require strict isolation are better deployed in VMs than in containers, which don’t isolate applications fully from each other or the host OS.
- GUI applications. Although it’s technically possible to run GUI apps in Docker containers, this is harder than running command-line interface apps. This is why video games are not deployed using Docker, for instance.
- Small-scale deployments. Teams that deploy a small number of apps or don’t update their apps frequently might be better off sticking with VMs, which are simpler to manage. The complexity of orchestrating Docker containers and managing storage for containers outweigh the benefits of Docker for small-scale deployments.