Skip to content

Why is Docker hard?

Le but inavoué de ces changements vise à faciliter la modernisation. L'introduction de nouveaux équipements pour conteneurs nécessite, selon Devlin, une réevaluation complète du niveau des effectifs, l'abolition du salaire à la tâche et l'abandon du travail protégé.

-- Le syndicalisme docker depuis 1945 (Michel Pigenet)

Abstract

This document compiles every argument against Docker adoption in 2020.

Multiple sides and categories of concerns are taken into accounts

Containers require a new way of thinking

category: container technology

Containers are very complex and create unique challenges

  • Containers abstract a whole system, it's not a "small abstraction" (like a software library)
  • Immutability: you cannot update a container like a regular application
  • Ephemeral: everything can be overwritten and nothing is persisted
  • New security paradigms: no strict isolation between containers or between container and host!

But that's a necessary tradeoff for scalability and agility.

sources:

Containers require a new way of debugging

category: container technology

  • No SSH on docker containers
  • Use docker volumes and docker logs
  • Use sidecar pattern to ship logs
  • Nsenter can be used a last resort to debug Linux Namespaces

Containers are not VMs! We cannot use the same debugging methods as VMs

sources:

Benefits vs Virtual Machines are unclear

category: container technology

Arguments against Docker:

  • People are used to the standard way: VM images (AMI, vApp, Packer, KVM etc) + a provisioning tool (Ansible, Chef). And it works.
  • Docker needs many new specific tools to be used properly in production: Registry, Orchestrator (K8s), applcation package management (Helm), Operators (Flux, database rollback etc).
  • People advocating Docker are often fanatic and offer only "docker == magic" arguments
  • Docker is by definition less secure because all containers share the same kernel: VM are better!!!

Arguments against VMs:

  • testability: a container is testable
  • vm are slow: a VM is too coarse-grained and restarting a VM is a big deal (boot time, provisioning time...)
  • containers are lightweight and you can run more containers per rack
  • VMs cannot scale as fast and wide as containers
  • a "best of two worlds approach": use VMs which run Docker. (better isolation, and lets the user use Docker for fast development)

sources:

Creating good images is hard

category: docker specifics

Copy-pasting simplistic Dockerfiles from the web creates broken images:

  • no python version pining
  • no dependencies pining
  • bad layer caching usage
  • running as root

Building production-ready / best practices Docker images is hard. You must learn Docker best practices and think instead of copy-pasting.

source: Pythonspeed - Dockerizing Python is Hard (2020)

You must be root to use Docker

category: docker specifics

many solutions do exist:

Docker is dying

category: docker specifics

Is Moby a fork/replacement for Docker?

Shykes on Hackernews (2017)

Before 2017:

  • Docker was a monolithic app with many responsibilities: build, runtime...
  • Docker is a company selling enterprise editions but the open source community maintains the open source project

Now:

It's a common concern in the free software community that having an open-source project too tightly coupled to a single company's product is a bad thing. Moving the upstream open-source project into Moby, and keeping the downstream open-source product into Docker, solves that problem.

-- Solomon Hykes

  • The monolith has been broken into multiple open source projects (build = buildkit, runtime = containerd)
  • Moby = all the open source projects
  • Docker = the product, using moby components

Docker Swarm lost to Kubernetes

  • Docker supports Kubernetes orchestration since 2017 (Docker 1.12)
  • Cloud providers: KaaS and proprietary

Docker vs other container types

rkt, lxd, ... Docker now faces many challengers

CRI : Container Runtime Interface. Created by the OCI (Open Container Initiative)

The Open Container Initiative (OCI) is a lightweight, open governance structure (project), formed under the auspices of the Linux Foundation

-- OCI website

  • Kubernetes supports any OCI container
  • Docker containers (== moby containerd) implements CRI

Docker Containers are now just one type of OCI containers The community is looking to improve container security by creating new paradigms like MicroVMs or Unikernels. The container technology is now under the OCI/Linux Foundation governance, which is BETTER than a standalone company.

RHEL doesn't ship Docker anymore

Instead of Docker: Podman, Buildah, Skopeo.

These tools are OCI-compatible, not only Docker-Compatible. They offer many improvements (ex: Podman has no daemon running on the host!) over Docker

Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Simply put: alias docker=podman.

-- Podman Website

sources:

Command-line only is hard

category: misc technical

Docker/K8S GUIs

for Windows / MacOS / Linux:

Rancher, Portainer, Kitematic, DockStation

I have trouble memorizing commands

Google it, tab completion, cheatsheets

I know the theory but cannot put it in practice

Tutorials can harm the way you learn:

  • you never have to setup the real environment and only address the "passing" case.
  • You aren't trained to troubleshoot in a tutorial.
  • You aren't trained to ask good questions.
  • Tutorials are really easy and give the illusion of mastery.

In general, excessive guidance carn harm the way you learn:

  • tutorial hints,
  • copy/paste full code snippets,
  • learning programming syntax but not programming concepts

Solutions:

  • Setup your work environment (don't work in artifical environments like play-with-docker)
  • Program from scratch: without any tutorial/instruction! You can look at other people's code, but not allowed to copy/paste from them.
  • Learn to ask for help
  • Code more

sources:

Docker is not the developers job

category: company & culture

When the company culture doesn't evolve but they still want to adopt Devops, the following reactions can occur:

Loss of productivity

category: company & culture

  • Developers don't want to be part of infrastructure/ops team. Too much responsibilities and not enough time.
  • Manager view: If the developers begin to do infra/ops work, the developer productivity/velocity will go down.
  • Every developer need to be availabe for ops: interruptions, participating in post-mortems, performance monitoring...

The switch to devops must change expectations and metrics!

  • Individual productivity is less important than flow of work in/out of operations
  • Commits / LoC metrics are replaced by MTTR, Change lead time, deploys per hour
  • Managers and developers must see the big picture ie working to deliver a product

source: Dzone - Devops kills developer productivity too (2014)

Developer burnout

category: company & culture

It is no surprise that developers are now more likely to crumble under stress -- especially because they know that they are directly affecting the end-user experience. With the ability to create rapid changes and innovate quickly comes the acceptance of great responsibility that can increase stress levels and cause severe damages when not carefully managed.

-- Logz.io - Why devops is burning out developers (2015)

Docker steals Ops jobs

category: company & culture

Traditional sysadmins can fear that devops tools like Docker will automate them out of their job.

  • Everything as code is a developer skillset, not a ops/sysadmin skillset.
  • Docker trivialized what was a real job into sharing random precompiled binaries: security issues. Nobody can build Haddop from scratch.

sources: