Nomad at a glance, and choosing between the three

The first two orchestrators in this part both assume everything you run is a container. Most real estates are not: there is a JVM service that has never been containerised, a batch job that needs a specific host, a legacy binary nobody will touch, and a virtual machine that has to stay a virtual machine.

Nomad is the option that takes that seriously, and it is worth knowing about even if you do not choose it, because it clarifies what you are actually buying from the other two.

What Nomad is

job "web" {
  datacenters = ["dc1"]
  type        = "service"

  group "app" {
    count = 4

    network {
      port "http" { to = 8080 }
    }

    update {
      max_parallel     = 1
      min_healthy_time = "30s"
      healthy_deadline = "5m"
      auto_revert      = true
      canary           = 1
    }

    task "server" {
      driver = "docker"

      config {
        image = "registry.example.com/myorg/myapp:1.4.2"
        ports = ["http"]
      }

      resources {
        cpu    = 500
        memory = 512
      }
    }
  }
}

auto_revert = true and canary = 1 are the defaults worth noticing: Nomad makes canary deploys and automatic rollback first-class in the job file rather than something you assemble.

Where Nomad sits

Its genuine strengths:

• Operational simplicity that is close to Swarm’s. One binary, one config file, no CNI plugin required to get started, a usable built-in web UI.
• Heterogeneous workloads. This is the reason to choose it. If a third of your estate cannot be containerised this decade, Nomad schedules it anyway.
• Good multi-region and multi-datacenter modelling, built in rather than bolted on.
• Low overhead. A Nomad client is one process, which matters at the edge and on small nodes.

Its costs, stated plainly:

• The smallest ecosystem of the three. Fewer integrations, fewer people with experience, and much less material to search when something is odd. This is the same risk as Swarm’s, and it is larger in absolute terms because Nomad is also less familiar than Swarm to people who already run Docker.
• The full picture needs its siblings. Service discovery, secrets and service mesh are strongest with Consul and Vault alongside. Nomad has had native service discovery since 1.3, but a serious deployment usually ends up running two or three HashiCorp products rather than one — which is a second and third consensus cluster to operate.
• Licensing changed. In August 2023 HashiCorp relicensed its products, including Nomad, from the Mozilla Public License to the Business Source License 1.1. Unlike Terraform and Vault, Nomad has no widely adopted community fork. Whether the BUSL terms are acceptable is a question for your organisation, not a technical one — but it is a question to answer before adoption rather than after, and the current terms should be checked directly rather than taken from a course.
• Fewer managed offerings. In practice you run the servers yourself.

Comparing on the axes that decide it

Feature tables make all three look similar because all three schedule containers across hosts. These are the axes that actually determine whether the adoption succeeds:

That last row is the one to argue about in the meeting. Every orchestrator is operable by the person who set it up. The question is what happens eighteen months later.

Evaluate by operating, not by deploying

1. Kill a node with no warning. Power it off, do not drain it. Time how long until the workload is running again, and read what the cluster said while it happened.
2. Lose the control plane. Stop a majority of managers or servers. Confirm what still works, then recover from backup — not from the surviving nodes, from an actual restore of the state store.
3. Do an upgrade. Take the cluster across one minor version, control plane and nodes, with the workload running. This is the recurring cost; measure it once before committing to it forever.
4. Ask for something unschedulable. Request more memory than any node has. Find out how the platform tells you, and how long it takes you to find that message without help.
5. Hand it to someone else. Have a colleague who did not build it perform a routine task from your runbook: deploy a new version, roll it back, drain a node. Their difficulty is the real operational cost.

The case for not migrating

The strongest option is frequently the one nobody proposes.

A single well-run Docker host, with a tested restore, external state, and an hour of downtime budget for a rebuild, is more reliable in practice than a three-node cluster nobody understands. Two hosts behind a load balancer, with the database somewhere else, covers the “a host can die” requirement without any orchestrator at all — and that is the requirement most teams actually have.

Knowledge check