Containers have a lot of value. My rule of thumb is basically use containers (docker) and as little as possible of anything else in the container ecosystem. So basically put your app in a container try to not change too much from however you currently do things. There is no shame in running --net=host or just doing "-v /mnt/someebsvolume:/data." I personally like Hashicorp because their tools are simple and grow with you. Besides Hashicorp, I don't have great recommendations for tools. In my opinion the current container ecosystem is a disaster for users. Big business ideas took over and killed innovation. Simple lightweight modular systems all got annihilated by Kubernetes and now it's pretty much a monoculture.

> Big business ideas took over and killed innovation. Simple lightweight modular systems all got annihilated by Kubernetes and now it's pretty much a monoculture.

I don't work with K8S or even docker on a day-to-day basis, but to me the ecosystem looks rather good. There are several solutions of orchestration and containerization competing from different vendors, and things tend to be standardised to make them work together :

- https://github.com/kubernetes/community/blob/master/contribu...

- https://www.opencontainers.org/

No later than yesterday there was that post on HN : https://news.ycombinator.com/item?id=18050781

People experiment, dissect, keep some old things, hack new things. K8S is still in active development, new initiatives like Istio and Knative are built on top of it. It looks like an healthy innovative ecosystem to me. I guess it depends of point of view and interests.

Where can i read more about best practice regarding this while not getting to distracted or off in the wrong direction?

I would also really love to learn the same.

I still don't quite understand why Docker Swarm is so overlooked. It essentially offers easy-to-manage orchestration while providing most of the core features that many people are looking for. It even makes use of compose files, which many developers are already writing. Given that most of the complaints about Kubernetes relate to its complexity and the need for a Kubernetes "expert" to look after said complexity, I'm somewhat baffled by how many people just totally overlook Swarm as if it wasn't an option.

> I still don't quite understand why Docker Swarm is so overlooked.

No IPv6 support in it at all, and the company seems to have moved resources internally away from Swarm development.

Doesn't bode well for it's future. Expecting it'll be taken out to the back shed (-bang-) in a while.

Check this GitHub issue on SwarmKit for more info: https://github.com/docker/swarmkit/issues/2665

Docker staff have been saying words to the effect of "we'll make an announcement with info soon!" for at least the last three+ months, across several projects. Swarm, Docker-Machine, & Infrakit come to mind.

With no actual announcement(s) then occurring.

The commit activity graph on InfraKit - which people are supposed to use now that Docker-Machine has been deprecated - seems pretty clear:

https://github.com/docker/infrakit/graphs/contributors

SwarmKit is the same:

https://github.com/docker/swarmkit/graphs/contributors

Clearly these aren't where resources have been placed.

Actions are not lining up with the words given. :(

I guess you are right. It's unfortunate because judging from the comments here you would think that there's a market for a simpler orchestration software while it will be hard to compete as just another Kubernetes distributor (even more so now that there are several alternatives for the container runtime). But hey, what do I know about product management?! :)

Nomad is that. We run Nomad quite successfully at SeatGeek, and I know of several Very Large Companies™ doing so at scale as well. One of them even has a fruit logo.

You are using the enterprise version, I assume?

We are running the OSS version of Consul, Nomad, and Vault. While the enterprise versions provide some items that could be interesting, they are not necessary given our workflow, and I'd bet that the majority of development shops out there wouldn't need them either (though I am certainly more than happy to play with them!).

I think you are right but the fact that Docker Inc included Kubernetes surely didn't help Swarm adoption.

I have had a good experience using the Hashicorp stack of Nomad and Consul, integrated with nginx for load balancing.

This stack doesn't offer all of the same functionality as the Kubernetes ecosystem, but it has the benefit of being vastly simpler and composed of relatively small, independent parts.

We did examine Kubernetes, but for various reasons we need to manage our own cluster and the engineering overhead was too high for our team to take on.

Why is Nomad & Consul simpler that Kubernetes?

If you just need to "orchestrate" on a single box, Docker Compose (https://docs.docker.com/compose/) is the bees knees.