OpenShift vs. Docker

Docker is a clear leader when it comes to container-based vir­tu­al­isa­tion providing a basic tech­no­logy for creating and running ap­plic­a­tion con­tain­ers. Docker is used pre­dom­in­antly by de­velopers to stand­ard­ise de­vel­op­ment workflows. OpenShift sits at the other end of the vir­tu­al­isa­tion spectrum, covering the op­er­a­tion­al needs of an entire or­gan­isa­tion. Public and private cloud en­vir­on­ments are a basis for its use.

The two tech­no­lo­gies are by no means direct com­pet­it­ors. In fact, OpenShift used to be in­dir­ectly based on Docker and still uses the Docker container format today. Our overview dives deep into their strengths and weak­nesses as well as re­spect­ive de­ploy­ment scenarios.

‘OpenShift vs. Docker – which is better for container vir­tu­al­isa­tion?’ That’s a common question on forums and in blog posts. But the two tech­no­lo­gies aren’t all that similar to begin with. OpenShift and Docker tend to be used com­ple­ment­ar­ily.

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­no­logy. Let’s use a bio­lo­gic­al analogy for a better un­der­stand­ing. Ap­plic­a­tion con­tain­ers and bio­lo­gic­al cells have a lot in common. Both are en­cap­su­lated, ex­tern­ally sealed, fun­da­ment­al units of in­form­a­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­trated alliances of in­ter­act­ing con­tain­ers occurred. The chal­lenges as­so­ci­ated with mul­ti­cel­lu­lar­ity are similar to those arising from the in­ter­ac­tion of multiple con­tain­ers.

Bio­lo­gic­al cells and ap­plic­a­tion con­tain­ers must com­mu­nic­ate with each other. They grow or die as required. The total available resources must be dis­trib­uted among the in­di­vidu­al units. This process must be well-co­ordin­ated 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­isa­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­spect­ive. Which of the two ap­proaches is ‘better’ ul­ti­mately depends heavily on the point of view. The same is true for OpenShift vs Docker com­par­is­on.

Docker pop­ular­ised container vir­tu­al­isa­tion and largely displaced pre­vi­ously dominant virtual machines (VM). Ap­plic­a­tion con­tain­ers have re­volu­tion­ised how ap­plic­a­tions are built, packaged, and run because con­tain­ers are a stand­ard­ised software entity. They are easy to deploy wherever a cor­res­pond­ing container runtime exists.

In contrast to pre­vi­ously ubi­quit­ous 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­isa­tion led to the pro­lif­er­a­tion of dis­trib­uted mi­croservice ar­chi­tec­tures. Instead of building a mono­lith­ic ap­plic­a­tion, feature sets are split into in­di­vidu­al com­pon­ents. Each component is packaged as a service in its own container. Services then com­mu­nic­ate with each other via the network.

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

The ability to clone several similar con­tain­ers from a container image improves the scalab­il­ity of the overall system. In the event of higher demand, ad­di­tion­al con­tain­ers are added and the service scales ho­ri­zont­ally. However, this requires a system that monitors the running con­tain­ers and ter­min­ates them or launches new ones where needed. Incoming requests must also be dis­trib­uted to the in­di­vidu­al con­tain­ers.

With scalab­il­ity, the com­plex­ity of the system grows con­sid­er­ably. That’s why the following must be con­sidered:

• Receiving requests via a load balancer
• Dis­trib­ut­ing tasks to the in­di­vidu­al con­tain­ers
• Mon­it­or­ing state of container instances
• Ter­min­at­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­trat­ive overhead. Add to that the main­ten­ance of the ad­min­is­trat­ive system which will need to be monitored and updated. There should never be any no­tice­able loss of per­form­ance. 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­sib­il­ity to or­ches­trate our container clusters across in­fra­struc­ture bound­ar­ies. At this point, the com­plex­ity of the system is no longer man­age­able for in­di­vidu­als. Special tools are needed which help or­gan­isa­tions cope with this com­plex­ity. That’s one reason why com­par­able OpenShift al­tern­at­ives have emerged.

As already mentioned, OpenShift and Docker aren’t all that similar. A com­par­is­on makes more sense when con­sid­er­ing ‘Kuber­netes’, also known as K8s. This is because the step from Docker to K8s is com­par­able to the trans­ition 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­par­able to the trans­ition from a single organism to a group of living things. Let’s take another look at the tech­no­lo­gies in use:

In fact, OpenShift is based on K8s, which in turn was ori­gin­ally 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­no­logy that can be used to package ap­plic­a­tions in con­tain­ers or run ap­plic­a­tion con­tain­ers. Docker is used to create portable, self-contained ap­plic­a­tion con­tain­ers that can be executed in a cloud en­vir­on­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­it­ies of container vir­tu­al­isa­tion.
2. Docker Compose, a func­tion­al­ity 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­trated across multiple hosts.

The Docker Engine in turn consists of three main com­pon­ents:

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­nic­ate 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­no­lo­gies, such as Docker Compose, are also included.

Docker is the es­tab­lished standard for container vir­tu­al­isa­tion. So it’s not sur­pris­ing that the software runs on a wide variety of operating systems. Docker is re­l­at­ively easy to install, and getting started is just as simple. The broad range of pre­fab­ric­ated container images is very practical. They contain software en­vir­on­ments for de­vel­op­ment and pro­duc­tion and can be obtained from public container re­gis­tries. Compared to OpenShift, Docker is a less complex tech­no­logy.

Docker’s biggest drawbacks stem from its organic growth over the years. What started as container vir­tu­al­isa­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­proaches, Docker is re­l­at­ively weak in terms of security and per­form­ance.

Docker is primarily used for software de­vel­op­ment. Local de­vel­op­ment en­vir­on­ments are en­cap­su­lated as con­tain­ers together with the tools and workflows in use. Images created this way can be shared between de­velopers and form the basis of stand­ard­ised, re­pro­du­cible de­vel­op­ments.

Fur­ther­more, Docker serves as the basis for the tech­no­lo­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­plic­a­tion and de­vel­op­ment en­vir­on­ments using the Platform-as-a-Service (PaaS) model. The software provides a complete execution en­vir­on­ment in which con­tain­ers are deployed, executed, managed, and or­ches­trated. The in­teg­rated tools simplify modern de­vel­op­ment and de­ploy­ment workflows.

OpenShift is based on a special Kuber­netes (K8s) dis­tri­bu­tion. To achieve a con­sist­ent user ex­per­i­ence, this can be deployed across cloud and in­fra­struc­ture bound­ar­ies. The core K8s func­tion­al­ity is com­ple­men­ted by security and mon­it­or­ing features and is based on cent­ral­ised policy man­age­ment. This ensures a high quality across the software landscape of an entire or­gan­isa­tion.

First, OpenShift reduces the op­er­a­tion­al com­plex­ity as­so­ci­ated 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­velopers can request resources for their projects via a web interface. In­teg­rated tools and workflows for con­tinu­ous in­teg­ra­tion and con­tinu­ous delivery (CI/CD) drastic­ally reduce delivery times.

OpenShift relies on a special K8s dis­tri­bu­tion to or­ches­trate the con­tain­ers and clusters. Ori­gin­ally, K8s was based on Docker as the container runtime. Now, this de­pend­ency has been dissolved; instead, the ‘Container Runtime Interface’ of the Open Container Ini­ti­at­ive (CRI-O) is used, offering several ad­vant­ages in terms of security and per­form­ance.

In general, OpenShift impresses with its in­teg­rated security measures. With ‘Quay’, a specially secured container registry is available. End-to-end au­thor­isa­tion and au­then­tic­a­tion limits user access to the in­di­vidu­al areas of the system. The ability to host in­di­vidu­al clusters in different geo­graph­ic regions allows better com­pli­ance in terms of data pro­tec­tion and data sov­er­eignty.

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­stall­a­tion is con­sidered extremely complex. For example, setting up large projects can take several weeks. Due to stricter security protocols, not all container images of public re­gis­tries 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­men­ted. The focus of OpenShift is clearly on large or­gan­isa­tions. OpenShift is def­in­itely too big and too difficult to handle for in­di­vidu­al de­velopers.

Even if a direct com­par­is­on of OpenShift vs. Docker is difficult, in­di­vidu­al prop­er­ties of the two tech­no­lo­gies can be compared. For the sake of com­plete­ness, we include Kuber­netes (K8s) in the com­par­is­on: