Docker containers have many advantages. Arguably, portability is not one of them. Here’s why containers are less portable than virtual machines.
Portability means the ability to move an application—in other words, port it—from one host environment to another.
The new host environment could be:
- A different kind of operating system. Think porting from Linux to Windows.
- A different version of the same operating system, as in when you port a Windows 7 application to run on Windows 10.
- A different type of hardware platform. Maybe you’re going from an 32-bit to 64-bit machine, for example, or from a SPARC to an x86 architecture.
The work required to complete a port varies depending on the exact circumstances. Sometimes, you can move a binary from one environment to another with ease. Other times, you have to compile a new binary or modify source code. In some cases, you can’t port an application at all because low-level functionality that it requires is just not available in the target environment.
Docker Containers Portability
In one sense, Docker containers offer a lot of portability. With containers, you can build an application once, place it inside a container image (or series of images, if the app is composed of multiple services, each running in a separate container) and run it on any host environment that supports Docker and runs on the same family of operating system.
Practically speaking, this means that using Docker, you can host an application inside containers on Ubuntu Linux 16.04, then move that same application to a Red Hat Enterprise Linux 7.4 server without having to recompile anything. You simply move the container images over.
Porting an application from one Linux distribution to another using Docker is much simpler than doing it in another way. Before Docker, your best bet for moving an application from Ubuntu to RHEL was to build a new package for it, because you couldn’t install a Debian package (the kind of installation package Ubuntu uses) on an RHEL server (which uses RPM packages). (Well, you technically could do this using a tool like Alien, but this is messy and not practical for production.)
So far, so great. However, there’s an important caveat about Docker application portability.
Docker’s Portability Limitations
Docker doesn’t support porting across different families of operating systems. You can’t take a Dockerized app designed for Linux and run it on Windows, or vice versa.
And you certainly can’t port a Docker app to macOS, since Docker doesn’t support macOS at all. Nor can you port Docker containers to Android. Even though Android is derived in part from the Linux kernel, Docker doesn’t support Android.
You also can’t take a Docker container that was created for an x86 system and run it on an ARM machine, even though Docker does support ARM.
In contrast, traditional virtual machines would support most of these porting scenarios.
If you want to port an application within the same family of operating system and on the same type of hardware platform, Docker is great. Within this context, it’s easier and faster to move an application from one environment to another using containers than it is using other methods.
However, if the port you want to make involves a bigger jump—from Linux to Windows, or from x86 to something else—Docker just can’t get you there. For that type of portability, you need to turn to older technology.