4 ms·
That's true. However, consider this environment: - The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Auto
by mickeyp 8y ago
That's true. However, consider this environment:
- The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!")
- You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there.
- Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.
- usgroup 8y agoSure and then google release “kubelite” or some guy writes a convenience script and there goes your competitive advantage for the use case :) Docker didn’t have enough of an advantage even though Swarm game shipped with it, so de facto if you had Kube you would have had Swarm first...
- mickeyp 8y agoI 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.
- fatherlinnux 8y agoI 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....
- mickeyp 8y agoKeep 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!
- Multicomp 8y agoFWIW it appears K3s is starting to become the kubelite you are referring to.
- tedmiston 8y agoFor the curious: https://github.com/rancher/k3s 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.
- alexandre_m 8y agoRancher K3s is really targeting embedded, IoT and edge computing use cases. Not really as a simpler Kubernetes installation model.