4 ms·

Swarm is deprecated. I bet Nomad has no future and will surrender in the coming years. Using anything but k8s in 2022 is not wise.

KronisLV 4y ago
> Swarm is deprecated. I am yet to see this warning when running any workload on Swarm. Feature complete is not necessarily deprecated, Swarm simply won't get any fancy cloud platform integrations due to hype lying elsewhere instead, yet there has been no official word of an EOL, like: https://www.centos.org/centos-linux-eol/ https://www.centos.org/centos-linux-eol/ Of course, one can also argue that with the Mirantis acquisition the writing is on the wall and if you care about maximum hireability, then you should grok Kubernetes as well. None of that prevents me from also running Swarm in setups where it makes sense (e.g. a step up from Docker Compose, limited resources, not lots of time for DevOps related stuff etc.). > I bet Nomad has no future and will surrender in the coming years. I'm not so sure about this, Nomad integrates nicely in the rest of the HashiStack and it seems that there are plenty of large orgs investing in it, even when they don't need something like Consul or other offerings, due to its simplicity and more active development. Currently this claim could use more of a factual basis, otherwise it ends up sounding like ".NET will kill Java" or "Linux on the desktop will kill Windows" or something of that variety. > Using anything but k8s in 2022 is not wise. If you live exclusively in the cloud and use only managed offerings, that may as well be true. Otherwise it seems like a clear clash between the arguments of "pick the right tool for the job" and "pick whatever is popular and widely supported". In the deployments I've worked with, Docker Swarm is better for the first claim (limited complexity, low resource usage, easy to use) which matters more than the latter (on-prem). Someone else who runs stuff primarily in the cloud might have the opposite takeaway, due to how widely Kubernetes is supported, even despite the technical complexity or resource usage. That said, personally I think that the K3s Kubernetes distribution is one of the better options for many of the deployments out there: https://k3s.io/ https://k3s.io/ In addition, tools like Kompose can make moving from Swarm to Kubernetes something that would take less than a day: https://kompose.io/ https://kompose.io/ (or you can just use Helm), but until the day where Swarm will get a clear deprecation notice or I'll have a good reason to put a particular project on Kubernetes (as some already are), I'll just stick with Swarm/Nomad. Of course, if a team/employer tells you to just use technology X, do that. Or better yet, make running your OCI compatible containers someone else's problem.
- vbezhenar 4y ago
  I think that the most important thing Kubernetes does is vocabulary. You can replace docker build with podman or kaniko, but Dockerfile is a standard. You’ll not rewrite them. You can use k3s, gke. May be there’ll be independent implementations. But your infra code will be the same. It liberates you from dependency on particular cloud or even technology. And it enables easier distribution of software. Layer one is source code. You need to build it. Layer two is OCI image. Smart people, often original developers did the build and Linux dependency management, and you just need some runtime to run it. But you still need to manage external service dependencies, which ports to expose, which HTTP paths to expose. K8s yamls with some generator like Helm or Kustomize complete that picture, so you can deploy some service along its dependencies with one command. Docker-compose could be a better alternative. I like it more. But it’s not feature-complete (e.g. no ingresses, security is a complete afterthought) and at this point will not be a viable competitor.

KronisLV 4y ago

> Swarm is deprecated. I am yet to see this warning when running any workload on Swarm. Feature complete is not necessarily deprecated, Swarm simply won't get any fancy cloud platform integrations due to hype lying elsewhere instead, yet there has been no official word of an EOL, like: https://www.centos.org/centos-linux-eol/ https://www.centos.org/centos-linux-eol/ Of course, one can also argue that with the Mirantis acquisition the writing is on the wall and if you care about maximum hireability, then you should grok Kubernetes as well. None of that prevents me from also running Swarm in setups where it makes sense (e.g. a step up from Docker Compose, limited resources, not lots of time for DevOps related stuff etc.). > I bet Nomad has no future and will surrender in the coming years. I'm not so sure about this, Nomad integrates nicely in the rest of the HashiStack and it seems that there are plenty of large orgs investing in it, even when they don't need something like Consul or other offerings, due to its simplicity and more active development. Currently this claim could use more of a factual basis, otherwise it ends up sounding like ".NET will kill Java" or "Linux on the desktop will kill Windows" or something of that variety. > Using anything but k8s in 2022 is not wise. If you live exclusively in the cloud and use only managed offerings, that may as well be true. Otherwise it seems like a clear clash between the arguments of "pick the right tool for the job" and "pick whatever is popular and widely supported". In the deployments I've worked with, Docker Swarm is better for the first claim (limited complexity, low resource usage, easy to use) which matters more than the latter (on-prem). Someone else who runs stuff primarily in the cloud might have the opposite takeaway, due to how widely Kubernetes is supported, even despite the technical complexity or resource usage. That said, personally I think that the K3s Kubernetes distribution is one of the better options for many of the deployments out there: https://k3s.io/ https://k3s.io/ In addition, tools like Kompose can make moving from Swarm to Kubernetes something that would take less than a day: https://kompose.io/ https://kompose.io/ (or you can just use Helm), but until the day where Swarm will get a clear deprecation notice or I'll have a good reason to put a particular project on Kubernetes (as some already are), I'll just stick with Swarm/Nomad. Of course, if a team/employer tells you to just use technology X, do that. Or better yet, make running your OCI compatible containers someone else's problem.

vbezhenar 4y ago
I think that the most important thing Kubernetes does is vocabulary. You can replace docker build with podman or kaniko, but Dockerfile is a standard. You’ll not rewrite them. You can use k3s, gke. May be there’ll be independent implementations. But your infra code will be the same. It liberates you from dependency on particular cloud or even technology. And it enables easier distribution of software. Layer one is source code. You need to build it. Layer two is OCI image. Smart people, often original developers did the build and Linux dependency management, and you just need some runtime to run it. But you still need to manage external service dependencies, which ports to expose, which HTTP paths to expose. K8s yamls with some generator like Helm or Kustomize complete that picture, so you can deploy some service along its dependencies with one command. Docker-compose could be a better alternative. I like it more. But it’s not feature-complete (e.g. no ingresses, security is a complete afterthought) and at this point will not be a viable competitor.