OpenShift vs. Docker

Docker is a clear leader when it comes to container-based vir­tu­al­iza­tion providing a basic tech­nol­o­gy for creating and running ap­pli­ca­tion con­tain­ers. Docker is used pre­dom­i­nant­ly by de­vel­op­ers to stan­dard­ize de­vel­op­ment workflows. OpenShift sits at the other end of the vir­tu­al­iza­tion spectrum, covering the op­er­a­tional needs of an entire or­ga­ni­za­tion. Public and private cloud en­vi­ron­ments are a basis for its use.

The two tech­nolo­gies are by no means direct com­peti­tors. In fact, OpenShift used to be in­di­rect­ly based on Docker and still uses the Docker container format today. Our overview dives deep into their strengths and weak­ness­es as well as re­spec­tive de­ploy­ment scenarios.

“OpenShift vs. Docker – which is better for container vir­tu­al­iza­tion?” That’s a common question on forums and in blog posts. But the two tech­nolo­gies aren’t all that similar to begin with. OpenShift and Docker tend to be used com­ple­men­tar­i­ly.

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 con­tain­ers, the virtual coun­ter­part is not primarily a transport tech­nol­o­gy. Let’s use a bi­o­log­i­cal analogy for a better un­der­stand­ing. Ap­pli­ca­tion con­tain­ers and bi­o­log­i­cal cells have a lot in common. Both are en­cap­su­lat­ed, ex­ter­nal­ly sealed, fun­da­men­tal units of in­for­ma­tion.

In the living world, evolution trans­formed single-celled organisms to mul­ti­cel­lu­lar organisms. Similarly, in the virtual world, an evolution from single con­tain­ers to or­ches­trat­ed alliances of in­ter­act­ing con­tain­ers occurred. The chal­lenges as­so­ci­at­ed with mul­ti­cel­lu­lar­i­ty are similar to those arising from the in­ter­ac­tion of multiple con­tain­ers.

Bi­o­log­i­cal cells and ap­pli­ca­tion con­tain­ers must com­mu­ni­cate with each other. They grow or die as required. The total available resources must be dis­trib­uted among the in­di­vid­ual units. This process must be well-co­or­di­nat­ed so that the overall system can respond to changing demands while remaining stable over time. Let’s il­lus­trate the range of container vir­tu­al­iza­tion from Docker to OpenShift with the following overview:

The question as to which is better can only be answered by adding a specific per­spec­tive. Which of the two ap­proach­es is “better” ul­ti­mate­ly depends heavily on the point of view. The same is true for OpenShift vs Docker com­par­i­son.

Docker pop­u­lar­ized container vir­tu­al­iza­tion and largely displaced pre­vi­ous­ly dominant virtual machines (VM). Ap­pli­ca­tion con­tain­ers have rev­o­lu­tion­ized how ap­pli­ca­tions are built, packaged, and run because con­tain­ers are a stan­dard­ized software entity. They are easy to deploy wherever a cor­re­spond­ing container runtime exists.

In contrast to pre­vi­ous­ly ubiq­ui­tous but rather heavy virtual machines, con­tain­ers are light­weight. Dozens to thousands of con­tain­ers can be run on a single host. This inherent advantage of container vir­tu­al­iza­tion led to the pro­lif­er­a­tion of dis­trib­uted mi­croser­vice ar­chi­tec­tures. Instead of building a mono­lith­ic ap­pli­ca­tion, feature sets are split into in­di­vid­ual com­po­nents. Each component is packaged as a service in its own container. Services then com­mu­ni­cate with each other via the network.

The micro-service approach is par­tic­u­lar­ly practical for software de­vel­op­ment because it allows the most ap­pro­pri­ate tech­nolo­gies to be used for each service. Instead of being tied to in­di­vid­ual pro­gram­ming languages and paradigms, these can be varied. As new tech­nolo­gies are added, in­di­vid­ual services can also be more easily re-im­ple­ment­ed.

The ability to clone several similar con­tain­ers from a container image improves the scal­a­bil­i­ty of the overall system. In the event of higher demand, ad­di­tion­al con­tain­ers are added and the service scales hor­i­zon­tal­ly. However, this requires a system that monitors the running con­tain­ers and ter­mi­nates them or launches new ones where needed. Incoming requests must also be dis­trib­uted to the in­di­vid­ual con­tain­ers.

With scal­a­bil­i­ty, the com­plex­i­ty of the system grows con­sid­er­ably. That’s why the following must be con­sid­ered:

• Receiving requests via a load balancer
• Dis­trib­ut­ing tasks to the in­di­vid­ual con­tain­ers
• Mon­i­tor­ing state of container instances
• Ter­mi­nat­ing and launching new instances
• Es­tab­lish­ing a network between con­tain­ers
• Main­tain­ing the con­tain­ers or images with updates, etc.

All this adds up to a massive ad­min­is­tra­tive overhead. Add to that the main­te­nance of the ad­min­is­tra­tive system which will need to be monitored and updated. There should never be any no­tice­able loss of per­for­mance. Fur­ther­more, the security of the entire system must be guar­an­teed at all times.

Last but not least, we want to take advantage of the pos­si­bil­i­ty to or­ches­trate our container clusters across in­fra­struc­ture bound­aries. At this point, the com­plex­i­ty of the system is no longer man­age­able for in­di­vid­u­als. Special tools are needed which help or­ga­ni­za­tions cope with this com­plex­i­ty. That’s one reason why com­pa­ra­ble OpenShift al­ter­na­tives have emerged.

As already mentioned, OpenShift and Docker aren’t all that similar. A com­par­i­son makes more sense when con­sid­er­ing “Ku­ber­netes”, also known as K8s. This is because the step from Docker to K8s is com­pa­ra­ble to the tran­si­tion from a single-celled organism to a mul­ti­cel­lu­lar organism. And in a similar way, the move from K8s to OpenShift is com­pa­ra­ble to the tran­si­tion from a single organism to a group of living things. Let’s take another look at the tech­nolo­gies in use:

In fact, OpenShift is based on K8s, which in turn was orig­i­nal­ly 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 tech­nol­o­gy that can be used to package ap­pli­ca­tions in con­tain­ers or run ap­pli­ca­tion con­tain­ers. Docker is used to create portable, self-contained ap­pli­ca­tion con­tain­ers that can be executed in a cloud en­vi­ron­ment 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 func­tion­al­i­ties of container vir­tu­al­iza­tion.
2. Docker Compose, a func­tion­al­i­ty to or­ches­trate multiple con­tain­ers as a fed­er­a­tion.
3. Docker Swarm, a mode that allows container clusters to be or­ches­trat­ed across multiple hosts.

The Docker Engine in turn consists of three main com­po­nents:

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 con­trolled via the API.
3. The command line interface (CLI), which is used as a docker command to com­mu­ni­cate 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 sim­pli­fies the setup via a graphical user interface. Other Docker-derived tech­nolo­gies, such as Docker Compose, are also included.

Docker is the es­tab­lished standard for container vir­tu­al­iza­tion. So it’s not sur­pris­ing that the software runs on a wide variety of operating systems. Docker is rel­a­tive­ly easy to install, and getting started is just as simple. The broad range of pre­fab­ri­cat­ed container images is very practical. They contain software en­vi­ron­ments for de­vel­op­ment and pro­duc­tion and can be obtained from public container reg­istries. Compared to OpenShift, Docker is a less complex tech­nol­o­gy.

Docker’s biggest drawbacks stem from its organic growth over the years. What started as container vir­tu­al­iza­tion has evolved into a mono­lith­ic 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 ap­proach­es, Docker is rel­a­tive­ly weak in terms of security and per­for­mance.

Docker is primarily used for software de­vel­op­ment. Local de­vel­op­ment en­vi­ron­ments are en­cap­su­lat­ed as con­tain­ers together with the tools and workflows in use. Images created this way can be shared between de­vel­op­ers and form the basis of stan­dard­ized, re­pro­ducible de­vel­op­ments.

Fur­ther­more, Docker serves as the basis for the tech­nolo­gies built on it. De­vel­op­ment tools such as DDEV and Lando use Docker to simplify local de­vel­op­ments. Platforms like Portainer and Mirantis (formerly Docker En­ter­prise) provide powerful container or­ches­tra­tion tools.

OpenShift sits at the top end of the container spectrum. OpenShift is used to build dis­trib­uted, scaling ap­pli­ca­tion and de­vel­op­ment en­vi­ron­ments using the Platform-as-a-Service (PaaS) model. The software provides a complete execution en­vi­ron­ment in which con­tain­ers are deployed, executed, managed, and or­ches­trat­ed. The in­te­grat­ed tools simplify modern de­vel­op­ment and de­ploy­ment workflows.

OpenShift is based on a special Ku­ber­netes (K8s) dis­tri­b­u­tion. To achieve a con­sis­tent user ex­pe­ri­ence, this can be deployed across cloud and in­fra­struc­ture bound­aries. The core K8s func­tion­al­i­ty is com­ple­ment­ed by security and mon­i­tor­ing features and is based on cen­tral­ized policy man­age­ment. This ensures a high quality across the software landscape of an entire or­ga­ni­za­tion.

First, OpenShift reduces the op­er­a­tional com­plex­i­ty as­so­ci­at­ed with ad­min­is­ter­ing self-managed K8s clusters. Multiple K8s clusters can be centrally managed across public and private cloud in­fra­struc­tures. Following the PaaS approach, in-house de­vel­op­ers can request resources for their projects via a web interface. In­te­grat­ed tools and workflows for con­tin­u­ous in­te­gra­tion and con­tin­u­ous delivery (CI/CD) dras­ti­cal­ly reduce delivery times.

OpenShift relies on a special K8s dis­tri­b­u­tion to or­ches­trate the con­tain­ers and clusters. Orig­i­nal­ly, K8s was based on Docker as the container runtime. Now, this de­pen­den­cy has been dissolved; instead, the “Container Runtime Interface” of the Open Container Ini­tia­tive (CRI-O) is used, offering several ad­van­tages in terms of security and per­for­mance.

In general, OpenShift impresses with its in­te­grat­ed security measures. With “Quay”, a specially secured container registry is available. End-to-end au­tho­riza­tion and au­then­ti­ca­tion limits user access to the in­di­vid­ual areas of the system. The ability to host in­di­vid­ual clusters in different ge­o­graph­ic regions allows better com­pli­ance in terms of data pro­tec­tion and data sov­er­eign­ty.

OpenShift only runs on special operating systems from Red Hat, such as “Red Hat En­ter­prise Linux CoreOS” (RHCOS) and “Red Hat En­ter­prise Linux” (RHEL). The in­stal­la­tion is con­sid­ered extremely complex. For example, setting up large projects can take several weeks. Due to stricter security protocols, not all container images of public reg­istries can be used.

On the basis of OpenShift, company-owned Platform-as-a-Service (PaaS), Software-as-a-Service (SaaS), and Con­tain­ers-as-a-Service (CaaS) can be im­ple­ment­ed. The focus of OpenShift is clearly on large or­ga­ni­za­tions. OpenShift is def­i­nite­ly too big and too difficult to handle for in­di­vid­ual de­vel­op­ers.

Even if a direct com­par­i­son of OpenShift vs. Docker is difficult, in­di­vid­ual prop­er­ties of the two tech­nolo­gies can be compared. For the sake of com­plete­ness, we include Ku­ber­netes (K8s) in the com­par­i­son: