The Container Orchestration War Has Officially Begun

Let’s cut through the noise. If you are still managing Docker containers by SSH-ing into individual servers and running shell scripts, you are doing it wrong. I've spent the last week debugging a sprawling microservices architecture for a client in Oslo, and the "it works on my laptop" excuse doesn't hold up when you're pushing traffic across three different datacenters.

November 2015 has been a chaotic month. Docker 1.9 dropped with the new networking stack and Swarm 1.0. Almost simultaneously, Google pushed Kubernetes 1.1. The ecosystem is moving faster than most sysadmins can type apt-get update.

The question isn't if you should orchestrate, but how. Do you go with the native simplicity of Swarm, the Google-backed complexity of Kubernetes, or the battle-tested rigidity of Mesos? And more importantly, how does this software sit on top of your metal?

The Contenders

1. Docker Swarm 1.0: The Native Challenger

With the release of Docker 1.9 earlier this month, Swarm is finally production-ready. Its biggest selling point? It speaks Docker. If you know the Docker CLI, you know Swarm. There is no steep learning curve involving "pods" or "kubelets."

However, setting it up requires an external key-value store. I prefer Consul for this.

Pro Tip: Don't run your discovery service on the same node as your masters without resource limits. I've seen a Consul memory leak take down an entire Swarm manager.

Here is how we bootstrap a Swarm cluster using the new overlay networking drivers. Note the requirement for a kernel version > 3.16 (standard on CoolVDS KVM templates).

# Create the Key-Value store machine
docker-machine create -d virtualbox kv-store

# Run Consul
docker $(docker-machine config kv-store) run -d -p 8500:8500 -h consul progrium/consul -server -bootstrap

# Create the Swarm Master
docker-machine create -d virtualbox \
    --swarm --swarm-master \
    --swarm-discovery="consul://$(docker-machine ip kv-store):8500" \
    --engine-opt="cluster-store=consul://$(docker-machine ip kv-store):8500" \
    --engine-opt="cluster-advertise=eth1:2376" \
    swarm-master

2. Kubernetes 1.1: The Google Giant

Kubernetes (K8s) is not just a tool; it's a philosophy. It demands you structure your application the "Google way." It introduces concepts like Pods, Replication Controllers, and Services. It is powerful, but it is heavy.

For a team of two developers in Trondheim, K8s might be overkill. But for high-availability systems where you need self-healing, it is unmatched. If a node dies, Kubernetes moves the work elsewhere. If a container crashes, it restarts it.

A typical Pod definition looks like this. Notice the verbosity compared to a simple docker run command:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-frontend
  labels:
    app: web
spec:
  containers:
    - name: nginx
      image: nginx:1.9
      ports:
        - containerPort: 80
      resources:
        limits:
          cpu: "500m"
          memory: "128Mi"

3. Apache Mesos + Marathon: The Enterprise Incumbent

Mesos abstracts CPU, memory, storage, and other compute resources away from machines, enabling fault-tolerant and elastic distributed systems. It's what Twitter runs on. It's robust, but configuring Zookeeper clusters and maintaining Marathon JSON files is a full-time job.

The Infrastructure Reality Check

Here is the hard truth that software purists ignore: Orchestration adds overhead.

When you run an overlay network (like Flannel or Weave) or Docker's new libnetwork, you are encapsulating packets. This consumes CPU cycles. When you run a scheduler, you are consuming I/O for health checks and state management.

I recently benchmarked a MySQL cluster running inside containers on a budget VPS provider. The steal time (%st in top) was atrocious because the noisy neighbors were eating up the CPU cycles required for the overlay network processing.

This is where CoolVDS becomes the logical choice for serious Norwegian deployments. Unlike standard container services where you share a kernel, CoolVDS offers KVM (Kernel-based Virtual Machine) virtualization. You get your own kernel. You get dedicated resources.

Why I/O Latency Kills Orchestration

Container images are composed of layers. Pulling images, extracting layers, and mounting volumes is I/O intensive. If you are on spinning rust (HDD), your deployment pipeline will crawl.

At CoolVDS, we are rolling out NVMe storage. The difference in docker pull times is laughable. We are talking about seconds versus minutes.

The "Safe Harbor" Crisis

We cannot ignore the legal landscape. The European Court of Justice just invalidated the Safe Harbor agreement last month (October 2015). If you are storing customer data on US-controlled servers (AWS, Google Cloud), you are now operating in a legal grey area regarding the Norwegian Personal Data Act (Personopplysningsloven).

Hosting on CoolVDS ensures your data stays in Oslo. You satisfy Datatilsynet requirements, and you get lower latency to your Nordic user base. 15ms ping to Oslo is better than 40ms to Frankfurt.

Comparison Matrix

Configuration for Performance

Regardless of which orchestrator you choose, you need to tune the host Linux kernel. Most default sysctl settings are built for general-purpose computing, not high-density container hosting.

Add these to your /etc/sysctl.conf on your CoolVDS nodes to handle high connection churn:

# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65535

# Allow reuse of sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Increase max open files (critical for overlay networks)
fs.file-max = 2097152

# Max backlog of incoming connections
net.core.somaxconn = 65535

Apply them with sysctl -p.

Final Verdict

If you are a small team wanting to move fast in 2015, use Docker Swarm. It's integrated, it's native, and it's finally ready for prime time with version 1.0.

If you are building the next Spotify, invest the time in Kubernetes.

But remember: software cannot fix hardware. A container orchestrator running on an over-sold, high-latency VPS is just a very complex way to serve 503 errors. For critical workloads in Norway, you need the raw power of KVM isolation and local NVMe storage.

Don't let storage latency be the bottleneck in your shiny new microservices architecture. Spin up a high-performance instance on CoolVDS today and see what Docker is actually capable of.