Keep things simpler, make your life easier, and launch faster with Docker.

Outline

• Docker vs Kubernetes
• Clarifying the Docker homonym
• Docker Engine: The single-server container platform
• Kubernetes: The container orchestration platform
• Choosing the right platform: Docker Engine or Kubernetes
• 3 Use cases for Docker Engine
• Choose with no second thought

Docker vs Kubernetes

Docker and Kubernetes are platforms for running containerized applications. Both platforms are production-ready, but Kubernetes is broadly acclaimed.

Though the precise numbers are difficult to estimate, thousands of companies are relying on Kubernetes to run their software applications at scale. Only a fraction of that number would be using Docker in production.

Does it mean that Kubernetes is better than Docker?

To answer that question we must clarify what Docker is.

Clarifying the Docker homonym

Docker means multiple things.

Depending on what you are talking about, Docker may refer to the Docker company, Docker Hub, Docker container runtime(now containerd), a Docker image, Docker Desktop, Docker Engine, etc. This homonymy is not without reason.

Docker company (named dotCloud at the time) started the container revolution in 2013 by releasing the open-source Docker Platform.

Though containerization was not a new thing then, the Docker Platform was the first bundled solution for developers to build and run containers easily. Containerization really started gaining traction only after the introduction of the Docker platform.

As containerization began to gain traction, Docker company introduced more tools like Docker Hub, Docker CLI, Docker Swarm, etc.

Docker company also made a key movement to propel container adaptation forward. In 2017, Docker company pulled off its core container runtime into a separate open-source project named containerd and donated the project to CNCF. Now, containerd is the default container runtime in many Kubernetes distributions.

Docker company, being a key player in the container ecosystem, the term Docker is associated with multiple technologies and products that the Docker company created over the past 10 years.

But in the context of this post, we are comparing Docker Engine with Kubernetes.

Docker Engine: The single-server container platform

Docker Engine is a platform to run containerized applications on virtual or bare-metal servers. It’s the evolution of the original Docker Platform released in 2013.

Docker Engine, like its predecessor Docker Platform, runs containers on a single server; virtual or bear-metal. So, Docker Engine is essentially a single-server container platform.

If you want to run your application across multiple servers with Docker Engine, you have to manually deploy the application on each server.

Docker company introduced Docker Swarm in 2015 to address this limitation in Docker Engine. Docker Swarm can distribute an application across multiple Docker Engine hosts.

As of today, you can use Docker Engine in production with or without Docker Swarm.

Kubernetes: The container orchestration platform

In 2014, Kubernetes debuted as an open-source container orchestration platform.

Kubernetes used the Docker container runtime (which was a part of the open-source Docker Platform released in 2013) to run containers on servers or worker nodes as Kubernetes named them. The primary responsibility of Kubernetes was to schedule containers on a pool of worker nodes. And Kubernetes could efficiently do this across hundreds of worker nodes.

Thus Kubernetes addressed a major limitation in the Docker Platform at the time - being limited to a single server.

Besides, the creators of Kubernetes at Google already had first-hand experience running large-scale software applications. Borg, the predecessor to Kubernetes was already running Google’s software across hundreds of servers. The Kubernetes creators wanted to build a platform that could scale even better than Borg so it’s no coincidence that Kubernetes had a strong focus on scale from day 1.

How Kubernetes overtook Docker

Back in 2014, the DevOps movement had just started getting traction. Automation was a key topic in software engineering forums. Containers (with the introduction of the Docker Platform) were like hot cake.

There could have been no better time for Kubernetes to hit the market. And it did.

Backed by the tech giant Google, Kubernetes quickly gained momentum creating a community of companies and individuals eager to deploy Kubernetes, contribute code, improve the docs, etc.

Google started offering Kubernetes as a service in their cloud portfolio, and so as not to be left behind AWS and Microsoft quickly followed.

The compound effect of all these led to a massive adaptation of Kubernetes.

In 2015, Docker company released Docker Swarm adding orchestration capabilities to the Docker Platform to compete with Kubernetes. But the opportunity window had already elapsed. The Docker company, which started the container revolution by creating the Docker Platform lost the container orchestration war to Kubernetes.

Choosing the right platform: Docker Engine or Kubernetes

Alright.

So Kubernetes is more popular.

Everyone is using it.

Does it mean that I should always run my containers on Kubernetes?

Not really. Docker Engine, though not as popular as Kubernetes, has its place today.

Why choose Docker Engine over Kubernetes

The main challenge in Kubernetes is its complexity.

While you can easily deploy a Kubernetes cluster on your laptop in a development environment, deploying and operating a production Kubernetes cluster is no easy feat.

First, you must decide whether you want to DIY or use a managed Kubernetes.

If you go down the DIY path, you would be responsible for the entire life cycle management - planning, design, deployment, patch updates, version upgrades, backup, etc., - of your Kubernetes deployment. You need a dedicated team of Kubernetes experts for that.

You can ease some of the operational workload by using a managed Kubernetes service from a cloud provider. Still, you will be responsible for certain design decisions and operational work but, deploying Kubernetes, updates, upgrades, etc., will be taken care of by the cloud provider.

However, there are certain drawbacks in managed Kubernetes services.

The managed Kubernetes offerings have paved paths to set up a cluster in a specific way. It’s not possible to walk off the paved path into the wilderness - to customize things the way you want. So, if you need extensive customization in your Kubernetes deployment, managed Kubernetes may not be an option.

Even in managed Kubernetes, you may experience phantom issues where the whole system goes down and cannot be recovered. Though such situations are rare they are also not unlikely.

The bottom line is operating Kubernetes in production is complicated - be it DIY or managed.

On the other hand, using the Docker Engine is easy and straightforward. Install Docker Engine on a virtual server and you are good to go.

But, then why not use Docker Engine always?

Why choose Kubernetes over Docker Engine

  Scale.

The scale is the only justifiable reason to choose Kubernetes over Docker Engine.

The scale justifies the added complexity in Kubernetes and also enables you to finance the skills to operate Kubernetes in production.

The scale does not mean the number of users or the number of transactions in your application. The scale here refers to the computing capacity (number of virtual or bare-metal servers) and the number of microservices.

Docker Engine, being designed to run on a single server, is not able to efficiently support application deployment across hundreds of servers. While Docker Swarm can overcome the single-server limitation in Dockeer Engine, Docker Swarm is not even comparable with the scale you can achieve with Kubernetes.

3 Use cases for Docker Engine

So, Kubernetes is only relevant at scale. But scale is a relative measure.

There’s no fine line to demarcate at what scale Kubernetes becomes relevant.

So, here are three use cases where Docker is more suitable than Kubernetes.

1. Running a monolithic app, containerized

   Yes, you read it right. Containers are not only for microservices.
   You can build a container image of your monolith and deploy it on Docker Engine or even on Kubernetes. But Docker Engine is the better choice because, unlike a microservices-architected app, you do not have a large number of microservices to manage.

2. Hobby project or bootstrapping business

   Trying to validate your startup idea at ultra small scale, your first priority is to get the customers to start paying. You don’t have the time or money to invest in operating Kubernetes. Just deploy your software on Docker Engine and try to get your first customer to sign up.

3. Small team: No dedicated DevOps

   A production Kubernetes cluster demands a dedicated team of DevOps engineers. If you are a small team, with no dedicated DevOps yet, it’s better to stay with Docker Engine, until you recruit the required talent.

Your use case could be different. But these three use cases will give you the context to evaluate whether you should go for Docker or Kubernetes to run your application in production.

Choose with no second thought

There’s no scale number to say that you should be running Kubernetes and not Docker.

But, If you have a fully-fledged microservices app with a team of hundreds of devs, you cannot go wrong by choosing Kubernetes.

Otherwise, go for Docker Engine with no second thought. If you find that Docker is hampering your scale down the line, migrating to Kubernetes is not that hard.