I made a tradeoff; keep in mind, it's not always the case that the best technology wins. Running <Technology X> is all well and good, but if you cannot keep it running perfectly, or it results in unacceptable downtime due to operator error, then that reflects poorly on the architect/lead in charge of picking the tools.

I am more of a mind to make sure that I can solve the task(s) that I am given, such as it is, with the resources available (people, knowledge, time, etc.). That inevitably means tradeoffs. In a parallel universe I would have used K8s instead, as I think it's exceptional and far superior to Swarm. However, with the limited resources available, I chose Swarm, and for all its faults it's running fine.

I agree with your pragmatism (and admire it). I would only urge you to add a couple of tools to your toolbelt for analysis:

1. Open source politics aka is the project viable? 2. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3. Look for growth, not survival. If a company is not growing, it is dying.

These extra three test "gates" help me select what technology I will use, learn, and bet my career on....

Keep in mind, when this solution was adopted Docker were still wedded to Swarm. Even if they stop caring about it -- as they pretty much have now -- we have a system that works at rest. Two years on, the team(s) that handle the production support and operations are more comfortable with Docker & co, because of this. Not to forget, this is a very large (and risk-averse) enterprise. You don't always get to pick whatever you like!

FWIW it appears K3s is starting to become the kubelite you are referring to.

For the curious:

https://github.com/rancher/k3s

> k3s - 5 less than k8s

> Lightweight Kubernetes. Easy to install, half the memory, all in a binary less than 40mb.

Rancher K3s is really targeting embedded, IoT and edge computing use cases.

Not really as a simpler Kubernetes installation model.