Kubernetes vs. Docker Swarm vs. Nomad: A 2024 Infrastructure Survival Guide

I haven't slept properly since 2018. That was the year my team decided to migrate a perfectly functional monolith to microservices because a conference speaker told them to. We traded reliable function calls for network latency and JSON parsing errors. Six years later, the container orchestration landscape in 2024 has matured, but the fundamental mistake remains: engineers picking tools based on hype rather than requirements.

If you are deploying infrastructure in Norway, the stakes are different. You aren't just battling complexity; you are battling latency to NIX (Norwegian Internet Exchange), strict GDPR interpretations by Datatilsynet, and the physics of disk I/O. I’ve seen production clusters implode not because the YAML was wrong, but because the underlying storage couldn't handle the fsync rates required by etcd.

Let’s cut through the marketing noise. Here is the technical reality of running containers in 2024.

The Elephant in the Room: Kubernetes (v1.30)

Kubernetes won the war. We know this. With version 1.30 (released April 2024), we saw the stabilization of the Gateway API and improvements in dynamic resource allocation. It is the industry standard. But it is also an operational beast.

When to use it:

You need K8s if you have a team of at least three DevOps engineers, or if you require complex CRDs (Custom Resource Definitions) for operators. It is overkill for a static site.

The Hidden Cost: Etcd Latency

The control plane relies entirely on etcd. Etcd is notoriously sensitive to disk latency. If your WAL (Write Ahead Log) writes take longer than 10ms, your cluster becomes unstable. Leader elections fail. Pods get evicted.

In a recent audit for a client in Oslo, we found their "Cloud Kubernetes" was suffering from noisy neighbors. We moved the control plane to CoolVDS instances backed by dedicated NVMe. The stability difference was immediate because KVM isolation prevented CPU steal from starving the etcd process.

Here is how you verify if your storage is fast enough for K8s before you even install `kubeadm`:

# Run this FIO test to simulate etcd write patterns
fio --rw=write --ioengine=sync --fdatasync=1 \
    --directory=test-data --size=22m --bs=2300 \
    --name=mytest

If the 99th percentile fsync latency is above 10ms, do not deploy Kubernetes there. You will regret it.

The Undead: Docker Swarm

Every year experts say Swarm is dead, and every year I see pragmatic CTOs deploying it. Why? Because `docker-compose.yml` is the lingua franca of developers. Swarm is essentially multi-node Compose. It is built into the Docker engine.

The Reality Check

Swarm is perfect for small to medium setups where you don't need a service mesh or complex ingress controllers. However, its networking model (overlay network) can be a black box when things break. I once spent 14 hours debugging a VXLAN issue that turned out to be a firewall rule dropping UDP port 4789.

Pro Tip: If you run Swarm on public VPS nodes (like in a CoolVDS environment), ALWAYS encrypt the overlay network. It adds overhead, but unencrypted cross-node traffic is a GDPR violation waiting to happen.

To initialize a secure cluster:

docker swarm init --advertise-addr <PRIVATE_IP>
# On worker nodes
docker swarm join --token <TOKEN> <MANAGER_IP>:2377

The Hipster Choice: HashiCorp Nomad

Nomad is my personal favorite for 2024. It follows the Unix philosophy: it does one thing (scheduling) and does it well. It doesn't try to manage your networking (Consul does that) or your secrets (Vault does that).

Nomad 1.8 has brought significant improvements in workload identity. The beauty of Nomad is that it can schedule anything—Docker containers, Java JARs, or even raw `qemu` binaries.

A Sample Job Specification

Unlike the verbose YAML hell of Kubernetes, HCL (HashiCorp Configuration Language) is readable:

job "web-api" {
  datacenters = ["oslo-dc1"]
  type = "service"

  group "server" {
    count = 3

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

    task "api" {
      driver = "docker"
      config {
        image = "coolvds/api:2.4.1"
        ports = ["http"]
      }

      resources {
        cpu    = 500 # MHz
        memory = 256 # MB
      }
    }
  }
}

Notice the resource constraints. Nomad is strict. If you deploy this on a shared host with oversold CPUs, your tasks will flap. This is why we rely on KVM-based virtualization at CoolVDS. We guarantee the CPU cycles you reserve are actually available.

Infrastructure: The Layer Zero

No matter which orchestrator you choose, you are bound by the CAP theorem and the speed of light. In Norway, data sovereignty is critical. Using US-based cloud giants often introduces legal headaches regarding Schrems II. Hosting locally in Oslo or nearby European hubs solves the legal issue and drastically reduces latency.

However, "local" means nothing if the hardware is archaic. Container orchestration generates a massive amount of small, random I/O operations (logs, metrics, health checks, state updates). Spinning rust (HDD) or low-grade SATA SSDs cannot keep up with a 50-node cluster.

Comparison: Orchestrator Overhead

Final Verdict

If you are building the next banking platform, use Kubernetes. But invest heavily in your storage layer. Use NVMe. Ensure your provider offers true KVM isolation so your neighbors don't steal your IOPS.

If you are a small team deploying a web app, use Docker Swarm or Nomad. The operational savings are massive.

Regardless of your choice, latency kills conversion. A user in Trondheim shouldn't wait for a packet to travel to Frankfurt and back. Hosting on high-performance infrastructure within the region is the single best performance optimization you can make, far cheaper than rewriting your codebase.

Don't let slow I/O kill your orchestration. Deploy a high-performance KVM instance on CoolVDS today and see what sub-millisecond latency feels like.