The pros and cons of container platforms for portability

Defining portability

In the software world, portability means the ability of an application to run in different types of host environments. There are different degrees of portability. An application that can run on any type of Linux distribution, but not on Windows, would be considered somewhat portable. But it is not as portable as an application that supports Linux as well as Windows.

Portability is also measured in terms of the amount of tweaking required to move an application from one environment to another. A highly portable application is able to be deployed on any platform without the need to make significant modifications to configuration files.

Other, less portable applications are able to run on different systems but require extensive configuration tweaks within the different environments.

Conventional approaches to portability

Traditionally, portability has been achieved at the application level. Applications that were portable were designed by their developers in ways that allowed them to run in any type of environment and with configurations that were more or less universal across all types of host environments.

In this context, choosing the right programming language was an important factor. Some languages, such as Java, are easy to support in any type of environment without many changes to the code. Others, like .NET, are more difficult to support on multiple types of OSes.

In addition, designing configuration systems that do not depend on special OS features or tools was traditionally an important factor in making applications portable. For example, if your application stored its configuration in the Windows registry, it would be difficult to port to Linux. It would be more portable if it stored its configuration in plain text files.

Virtual machines (VMs) are another way to achieve a level of portability. For instance, an application that runs only on Linux could be hosted on a Windows server using a VM. While this type of solution gives you enough portability to make your host environment cross-platform, the portability is still relatively limited. It gives you flexibility at the level of your hosting infrastructure, since you could use either Windows- or Linux-based physical servers. But, at the same time, it requires you to use a specific type of guest OS in order to deploy your application.

Using containers to achieve portability

Thanks to the advent of container platforms like Docker, it's now possible to make applications highly portable without having to modify the application itself or rely on VMs. With containers, you can take an application written for one type of host environment and deploy it almost anywhere. In most cases, you don't have to make any changes to the application's configuration.

This is because containers allow you to "build once and run anywhere." In other words, with containers, you compile your code and place it into a container image. You can then deploy that image on any type of host environment that has a daemon installed to support your container. This works because all of your application's binaries and configuration files are stored inside the container. As a result, environment variables outside the container shouldn't impact the application.

Container portability limitations

It's important to note, however, that container platforms are not a panacea for application portability. They are still subject to certain limitations, including limitations around persistent storage and the portability of the containers themselves.

Container platforms -- especially Docker -- make applications much easier to move from one host platform to another.

Persistent storage configurations for containerized applications may need to be changed when you move containers from one environment to a different one. This is because there are different ways to implement persistent storage for containers, and the storage setup in one environment may not work for containers that were designed with a different environment in mind. Of course, this consideration doesn't apply if your containerized applications are stateless and don't require storage.

While containers are highly portable on the same type of container platform, you generally can't take a container built for one type of platform, like Docker, and run it on a different one, like Linux Containers (LXC). Also, containers designed for modern versions of Docker may not work on older versions. Like other technologies, Docker is not immune to backwards compatibility issues.

Crossing the Linux-Windows divide

Porting containers from one family of OS (e.g., Windows) to another (e.g., Linux) is also complicated. One big portability drawback of containers compared to VMs is that, traditionally, a containerized Linux application required a Linux host, and vice versa for Windows.

In this respect, containers are less portable than VMs. A Linux-based VM can typically run on a Windows host, and vice versa. In addition, containers have never supported platforms other than Linux and Windows. As a result, there was no native way to deploy a Dockerized application on macOS, for example. You could solve this problem by using a Linux-based VM to serve as the middleman between your macOS host system and your Docker containers, but that comes at the cost of higher resource utilization and management burden.

Recently, however, this has changed in the case of Docker. In spring 2017, Docker announced LinuxKit, a set of tools that allow developers to create what Docker calls a "Linux subsystem" within their containers. The Linux subsystem provides a tiny Linux-based OS that runs inside a container and makes it possible to run Docker applications, even if the containers are running on a different type of OS. This approach doesn't require VMs.

With LinuxKit, Docker has now achieved maximum portability -- at least for Linux applications. Containerized Linux applications can be packaged with LinuxKit and run on any type of host OS, without requiring any special configuration changes when they move from one environment to another.

There are just two caveats. First, LinuxKit only works with the Docker framework. Other types of container platforms, like LXC, remain Linux-only. Second, LinuxKit only applies to Linux applications. There is still no way to take a containerized Windows application and run it on a Linux host.

Conclusion

Although containers are subject to certain portability limitations, container platforms -- especially Docker -- make applications much easier to move from one host platform to another. This has become even more true since the release of LinuxKit, which brings complete portability to containerized Linux applications.