Sure, I could definitely get a swarm set up quickly and run something trivial on it, but then I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.
My point about 'framework hopping' was that I try to get some value out of the time spent digging into a new tool/library/framework, rather than trying to use something new for each new project. Knowing the pitfalls, useful configs, edge cases, best plugins and so forth goes a long way towards being able to focus on what you're actually building. I'm not against early adoption and I am always learning new tools, but I do try to leverage the ones I have deep knowledge of.
> I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.
Almost all of your points are on one page in the doc (just google 'docker-compose file') which is read and used in 5 minutes. Btw, load balancing is the default, no real config required (still you can but the defaults are sensible). Anyway, you are usually 5x to 10x faster than with setting up an k8s cluster. This should be a good enough reason to give it a try and to make your own picture of Swarm.
It is up to you but I think you have a wrong picture of Swarm. Something huge, conplicated and intimidating like k8s. Something you should spend your weekend and the week after to learn. This is wrong.
Just see is as another CLI tool which you can grasp in the next hour (instead of surfing the web).
My point about 'framework hopping' was that I try to get some value out of the time spent digging into a new tool/library/framework, rather than trying to use something new for each new project. Knowing the pitfalls, useful configs, edge cases, best plugins and so forth goes a long way towards being able to focus on what you're actually building. I'm not against early adoption and I am always learning new tools, but I do try to leverage the ones I have deep knowledge of.