OpenShift vs. Docker

Docker is a clear leader when it comes to container-based virtualisation providing a basic technology for creating and running application containers. Docker is used predominantly by developers to standardise development workflows. OpenShift sits at the other end of the virtualisation spectrum, covering the operational needs of an entire organisation. Public and private cloud environments are a basis for its use.

The two technologies are by no means direct competitors. In fact, OpenShift used to be indirectly based on Docker and still uses the Docker container format today. Our overview dives deep into their strengths and weaknesses as well as respective deployment scenarios.

‘OpenShift vs. Docker – which is better for container virtualisation?’ That’s a common question on forums and in blog posts. But the two technologies aren’t all that similar to begin with. OpenShift and Docker tend to be used complementarily.

Comparing the two is kind of like asking: ‘What’s better – a car or public transport?’ In principle, both have a similar mission: move people and goods from one place to another. And wheels form the basis of the two modes of transport, but they’re very different in scale.

Unlike physical containers, the virtual counterpart is not primarily a transport technology. Let’s use a biological analogy for a better understanding. Application containers and biological cells have a lot in common. Both are encapsulated, externally sealed, fundamental units of information.

In the living world, evolution transformed single-celled organisms to multicellular organisms. Similarly, in the virtual world, an evolution from single containers to orchestrated alliances of interacting containers occurred. The challenges associated with multicellularity are similar to those arising from the interaction of multiple containers.

Biological cells and application containers must communicate with each other. They grow or die as required. The total available resources must be distributed among the individual units. This process must be well-coordinated so that the overall system can respond to changing demands while remaining stable over time. Let’s illustrate the range of container virtualisation from Docker to OpenShift with the following overview:

The question as to which is better can only be answered by adding a specific perspective. Which of the two approaches is ‘better’ ultimately depends heavily on the point of view. The same is true for OpenShift vs Docker comparison.

Docker popularised container virtualisation and largely displaced previously dominant virtual machines (VM). Application containers have revolutionised how applications are built, packaged, and run because containers are a standardised software entity. They are easy to deploy wherever a corresponding container runtime exists.

In contrast to previously ubiquitous but rather heavy virtual machines, containers are lightweight. Dozens to thousands of containers can be run on a single host. This inherent advantage of container virtualisation led to the proliferation of distributed microservice architectures. Instead of building a monolithic application, feature sets are split into individual components. Each component is packaged as a service in its own container. Services then communicate with each other via the network.

The micro-service approach is particularly practical for software development because it allows the most appropriate technologies to be used for each service. Instead of being tied to individual programming languages and paradigms, these can be varied. As new technologies are added, individual services can also be more easily re-implemented.

The ability to clone several similar containers from a container image improves the scalability of the overall system. In the event of higher demand, additional containers are added and the service scales horizontally. However, this requires a system that monitors the running containers and terminates them or launches new ones where needed. Incoming requests must also be distributed to the individual containers.

With scalability, the complexity of the system grows considerably. That’s why the following must be considered:

• Receiving requests via a load balancer
• Distributing tasks to the individual containers
• Monitoring state of container instances
• Terminating and launching new instances
• Establishing a network between containers
• Maintaining the containers or images with updates, etc.

All this adds up to a massive administrative overhead. Add to that the maintenance of the administrative system which will need to be monitored and updated. There should never be any noticeable loss of performance. Furthermore, the security of the entire system must be guaranteed at all times.

Last but not least, we want to take advantage of the possibility to orchestrate our container clusters across infrastructure boundaries. At this point, the complexity of the system is no longer manageable for individuals. Special tools are needed which help organisations cope with this complexity. That’s one reason why comparable OpenShift alternatives have emerged.

As already mentioned, OpenShift and Docker aren’t all that similar. A comparison makes more sense when considering ‘Kubernetes’, also known as K8s. This is because the step from Docker to K8s is comparable to the transition from a single-celled organism to a multicellular organism. And in a similar way, the move from K8s to OpenShift is comparable to the transition from a single organism to a group of living things. Let’s take another look at the technologies in use:

In fact, OpenShift is based on K8s, which in turn was originally based on Docker. Docker and K8s are now separate entities. Let’s take a closer look at OpenShift vs. Docker.

Docker is an open-source technology that can be used to package applications in containers or run application containers. Docker is used to create portable, self-contained application containers that can be executed in a cloud environment or on local computing hardware. The software comes from Docker Inc. In addition to the free open-source version, the company offers various paid products.

Docker is now three tools in one:

1. The Docker Engine, which provides the core functionalities of container virtualisation.
2. Docker Compose, a functionality to orchestrate multiple containers as a federation.
3. Docker Swarm, a mode that allows container clusters to be orchestrated across multiple hosts.

The Docker Engine in turn consists of three main components:

1. The Docker Daemon, which runs as dockerd on the host.
2. The Docker API, which is provided by Docker Daemon. The Docker Daemon is accessed and controlled via the API.
3. The command line interface (CLI), which is used as a docker command to communicate with the Docker API.

The Docker Engine is native to Linux. There is also an easy-to-install package, Docker Desktop, for Mac and Windows. Docker Desktop simplifies the setup via a graphical user interface. Other Docker-derived technologies, such as Docker Compose, are also included.

Docker is the established standard for container virtualisation. So it’s not surprising that the software runs on a wide variety of operating systems. Docker is relatively easy to install, and getting started is just as simple. The broad range of prefabricated container images is very practical. They contain software environments for development and production and can be obtained from public container registries. Compared to OpenShift, Docker is a less complex technology.

Docker’s biggest drawbacks stem from its organic growth over the years. What started as container virtualisation has evolved into a monolithic platform that performs too many functions at once. With Docker Swarm and Docker Compose, its use extends far beyond the original purpose. Compared to modern approaches, Docker is relatively weak in terms of security and performance.

Docker is primarily used for software development. Local development environments are encapsulated as containers together with the tools and workflows in use. Images created this way can be shared between developers and form the basis of standardised, reproducible developments.

Furthermore, Docker serves as the basis for the technologies built on it. Development tools such as DDEV and Lando use Docker to simplify local developments. Platforms like Portainer and Mirantis (formerly Docker Enterprise) provide powerful container orchestration tools.

OpenShift sits at the top end of the container spectrum. OpenShift is used to build distributed, scaling application and development environments using the Platform-as-a-Service (PaaS) model. The software provides a complete execution environment in which containers are deployed, executed, managed, and orchestrated. The integrated tools simplify modern development and deployment workflows.

OpenShift is based on a special Kubernetes (K8s) distribution. To achieve a consistent user experience, this can be deployed across cloud and infrastructure boundaries. The core K8s functionality is complemented by security and monitoring features and is based on centralised policy management. This ensures a high quality across the software landscape of an entire organisation.

First, OpenShift reduces the operational complexity associated with administering self-managed K8s clusters. Multiple K8s clusters can be centrally managed across public and private cloud infrastructures. Following the PaaS approach, in-house developers can request resources for their projects via a web interface. Integrated tools and workflows for continuous integration and continuous delivery (CI/CD) drastically reduce delivery times.

OpenShift relies on a special K8s distribution to orchestrate the containers and clusters. Originally, K8s was based on Docker as the container runtime. Now, this dependency has been dissolved; instead, the ‘Container Runtime Interface’ of the Open Container Initiative (CRI-O) is used, offering several advantages in terms of security and performance.

In general, OpenShift impresses with its integrated security measures. With ‘Quay’, a specially secured container registry is available. End-to-end authorisation and authentication limits user access to the individual areas of the system. The ability to host individual clusters in different geographic regions allows better compliance in terms of data protection and data sovereignty.

OpenShift only runs on special operating systems from Red Hat, such as ‘Red Hat Enterprise Linux CoreOS’ (RHCOS) and ‘Red Hat Enterprise Linux’ (RHEL). The installation is considered extremely complex. For example, setting up large projects can take several weeks. Due to stricter security protocols, not all container images of public registries can be used.

On the basis of OpenShift, company-owned Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), and Containers-as-a-Service (CaaS) can be implemented. The focus of OpenShift is clearly on large organisations. OpenShift is definitely too big and too difficult to handle for individual developers.

Even if a direct comparison of OpenShift vs. Docker is difficult, individual properties of the two technologies can be compared. For the sake of completeness, we include Kubernetes (K8s) in the comparison: