Why I'm leaving Kubernetes for Swarm
In this technical retrospective (2017), @jonathan-kosgei shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 30 points
TOTAL DISCUSSIONS 7 comments
There's a lot of misleading information here. Pretty much all of his examples use a more difficult solution than needed, making Kubernetes seem like it's a lot more fiddly to use.
The author seems to think that a Kubernetes manifest can only contain a single declaration. You can actually stuff as many declarations as you want into a single YAML file, like so (and you should!):
``` apiVersion: extensions/v1beta1 kind: Deployment [...] --- apiVersion: v1 kind: ConfigMap [...] --- apiVersion: v1 kind: Service [...]
``` Put it in myapp.yaml and do "kubectl apply -f myapp.yaml". Exactly the same as Docker Compose.
Also, don't use "kubectl create" — use "kubectl apply". It will create or update as needed. It even supports recursing through directories.
It's only sad if you use persistent volume claims, which is the "advanced" option which I don't think Swarm even has. I'm not sure why the author felt they needed to use them.
Kubernetes supports ordinary volumes that don't require that you predeclare anything else. For example, on Google Cloud Platform:
``` containers: [...] volumeMounts: - name: pgdata mountPath: /var/lib/postgresql/data subPath: pgdata name: pgdata volumes: - name: pgdata gcePersistentDisk: pdName: some-disk-i-created fsType: ext4
``` This will mount the persistent disk "some-disk-i-created", and automatically format it as ext4 if necessary.
Persistent volume claims are for managing pools of storage: You create one volume, then let pods carve out pieces of it. So you create big, generic volumes and let Kubernetes handle allocation, as opposed to setting up dedicated, named volumes for each container.
There are pros and cons to both approaches, of course. PV/PVCs obviously require that they're defined first. That said, once you've created a PV, it's actually less work to use it across multiple pods, because Kubernetes will handle the gritty details of allocation.
In my opinion the ingress system is the weakest part of Kubernetes right now. That said, once you create a controller (nginx-ingress-controller is great, and covers most needs), setting up new ingresses is dead easy, and certainly easier than managing your own load balancer using something like HAProxy or Nginx.
(For simplicity's sake I recommend keeping a single ingress file for your entire system, as opposed to spreading them out among different YAML files. Easier to manage.)
But you don't have to use an ingress or a managed load balancer. It's just a convenience. The way to do it is to use a NodePort, then run your own load balancer that points to it. I don't think this is any different from Docker Swarm. To spread the load across a cluster of containers, you need, per definition, a load balancer. You can also run a Kubernetes-aware load balancer such as Traefik.
The Nginx controller doesn't use physical paths for the ingress endpoints that it proxies. I don't know what he means by this. I have not had this issue.
I agree that Swarm is easier. But will it work in production? And will they break the API again? Just from 1.12 to 1.13 there are pretty big changes..
Kubernetes 'on prem' is hard and stuff