Docker Swarm or Kubernetes on PaaS? A DevOps Engineer's Decision for a Twelve-Service Application

The Swarm-or-Kubernetes argument is usually conducted in the abstract, where Kubernetes always wins because it can do more. Real teams do not choose in the abstract; they choose for a particular application and a particular number of people to run it. This post follows a DevOps engineer making the choice for a concrete application on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, where both orchestrators are one-click packages and the infrastructure underneath them is identical.

The application belongs to a property-management software company we will call Keystone Lettings: twelve services, one PostgreSQL, one Redis, a team of three engineers who also write the product. The candidates are the Docker Swarm Cluster and the Kubernetes Cluster packages, both deploying a working cluster onto platform-managed nodes on separate hosts.

What is the same, so it can be ignored

On the platform, the things that usually dominate this comparison are equal. Both packages give you nodes placed on separate physical hosts by anti-affinity, each scaling vertically in cloudlets (128 MiB of RAM plus 400 MHz of CPU) by the hour. Both can add worker nodes with the platform's horizontal scaling triggers, and in both the new node joins the cluster automatically. Both are billed per cloudlet-hour on actual use; neither charges a fee for the control plane. Both can be cloned for a staging cluster and exported. TLS via Let's Encrypt, container firewall, load alerts and backups work the same way. The engineer strikes all of that off the list and is left with the orchestrators themselves.

What Kubernetes gives you that Swarm does not

The Kubernetes package installs a full cluster with the pieces a team would otherwise assemble: a CNI, CoreDNS, a Traefik ingress controller, a storage provisioner backed by a platform NFS node, the dashboard, Helm, and optional Prometheus and Grafana and Jaeger. On top of that sit the concepts that make Kubernetes powerful and heavy: Deployments and StatefulSets, PersistentVolumeClaims, ConfigMaps, Ingress resources, Horizontal Pod Autoscalers, RBAC, namespaces, custom resources and operators.

For Keystone the genuinely relevant items are three. StatefulSets with persistent volume claims would let PostgreSQL move between nodes and find its data. Helm would let the team install third-party components (a message queue, an observability stack) from charts rather than writing everything. And the ecosystem: nearly every SaaS vendor and open-source project publishes for Kubernetes first.

What Swarm gives you that Kubernetes does not

Simplicity is a feature with a value, and the engineer tries to quantify it. Swarm's deployment format is the Compose file the team already maintains, with a deploy section. Its concepts fit on one page: services, replicas, overlay networks, secrets, configs, placement constraints, rolling updates. A cluster upgrade is a Docker Engine upgrade. There are no API version deprecations to chase each quarter, no ingress controller to maintain, no admission webhooks. A three-person team can hold the whole thing in their heads, and the on-call person at 03:00 is reading docker service ps output, which they understand.

Swarm's weakness is the mirror of Kubernetes' strength: stateful services are pinned to nodes with local volumes, and the ecosystem of ready-made components is thinner.

The two services that decided it

Ten of Keystone's twelve services are stateless: they can be replicated, rolled and rescheduled anywhere, and both orchestrators handle them identically. The decision came down to PostgreSQL and Redis.

In Kubernetes the engineer would run them as StatefulSets on the package's NFS-backed volumes, or install an operator to get replication. Both are real work, and running a database on NFS-backed persistent volumes is a performance compromise the team would need to measure. In Swarm they would be pinned to labelled nodes and backed up, with the platform's live migration as the safety net for the node itself.

Then the engineer noticed the third option, which changed the calculus: take the stateful services out of the orchestrator altogether. The marketplace's PostgreSQL Primary-Secondary Cluster and Redis Cluster packages run as platform-managed clusters in the same environment group, reachable from the swarm or the Kubernetes cluster over the internal network, with replication, failover, backup add-ons and TLS add-ons already built. Once the databases are the platform's problem, the orchestrator only has to run stateless services, and for stateless services Swarm's simplicity wins outright.

Cost, which turned out not to decide anything

The engineer sized both. Swarm: three managers at 4 to 6 cloudlets each (managers do little) and three workers at 12 to 20. Kubernetes: the package's control plane node plus the same three workers, with the control plane needing more than a Swarm manager. The difference is a few dozen cloudlet-hours a day, on the order of $30 a month at MassiveGRID's published $0.003372 per cloudlet-hour before discounts, in Swarm's favour. The databases cost the same either way because they moved to the platform's packages. Cost was not the deciding factor; the operational surface was.

The decision, and the escape hatch

Keystone chose Swarm, with PostgreSQL and Redis on the platform's cluster packages. The engineer wrote down the conditions under which they would revisit: needing more than one third-party component that ships only as a Helm chart; the team growing past six engineers; a customer contract requiring Kubernetes specifically. The escape hatch is real, because the images, the registry, the databases and the platform environments are all orchestrator-agnostic: moving the ten stateless services to the Kubernetes package later is a manifest-writing exercise, not a migration.

Frequently Asked Questions

Is Docker Swarm still maintained?

Yes. Swarm mode is part of Docker Engine and is maintained with it; the Docker Swarm Cluster package installs current Docker Engine CE. It receives fewer new features than Kubernetes, which for a team that values stability is not a disadvantage.

Can I run both on the same PaaS account?

Yes. Environments are independent, so a Swarm cluster for the product and a Kubernetes cluster for a component that ships only as a Helm chart can coexist in one environment group and talk over the internal network. Many teams run exactly that during a gradual move.

Does the Kubernetes package charge for the control plane?

No separate fee. The control plane runs on a node you pay for by the cloudlet-hour like any other. Compare that with hosted Kubernetes services that bill a fixed hourly control-plane charge per cluster before any worker runs.