[WnZ39p0Dgydaz1]

Docker, the company, is such a sad story. They have such an impactful technology but completely failed to monetize it and lost multiple revenue streams to competitors. Shows how hard "open source companies" are. Others OSS companies have similar problems. It would be nice to find economic models where impact is correlated with revenue.

[vergessenmir]

They are hard for sure. Docker did make some fundamental mistakes early on, especially on community engagement and open stable APIs.

It is a shame since I rooted hard for them in the early days.

[nickjj]

I've been using Docker since 2014 and IMO they did a great job in terms of API stability from an end user's perspective.

Lots of CLI commands from 5+ years ago still work today and the upgrade story with Docker Compose has been gradual, painless and most importantly pressure-less for having to upgrade.

[vergessenmir]

They got the developer facing API just right making containers accessible but their promised plugin architecture never did come.

There was an arms race between them and the community to lead the story on new functionality. For example flannel came out first before docker acquihired SocketPlane for networking, while Calico was also in the works.

There was pressure from the community for a stable plugin API to allow for external contribution, but I imagine that it was ultimately against their best interest

[pm90]

Agreed. Docker (actually, containers in general but docker tooling) made it so damn easy to get local, reproducible builds. It’s fantastic and made life so much easier for me professionally as a Software Engineer.

I remember the early days when Docker had just released, all devs were super excited but nobody had run containers “in production”. AFAIK I believe it was mesos that was used widely for orchestrating containers in production. Docker swarm/compose just took too long to get there and k8s just rapidly took over and became the standard.

[mikepurvis]

Admittedly I didn't follow it super closely, but I did do fig when that was a thing, then tried initial docker compose, and then later did docker compose again.

All along it has always just felt way too imperative. It was too much of a sense that you were issuing commands at a system rather than declaring a desired end state. Kubernetes got this right from the get-go.

[ridv]

The history of the relationship between Mesos and Docker is definitely an interesting one. If memory serves right, Mesos was not keen of supporting Docker as a containerizer. The devs wanted to stick to improving the Mesos containerizer.

In the end, the community was so vocal about Docker being supported in Mesos that it happened, but the end result was not stellar by all accounts (and a bit of a nightmare to deal with on the framework side to boot).

I'm not privy to what was going at the time since I was just part of the larger Mesos community, but looking back, can't help but wonder what would have happened if they collaborated instead.

[imiric]

I'm still rooting for them, specifically for Swarm which is a breath of fresh air for small and personal deployments. Though tooling around Kubernetes has improved in the last couple of years and it's much easier to get started now, the system still has a steep learning curve compared to Swarm.

[KurtMueller]

I'm currently learning both Docker Swarm and Kubernetes (at the same time) and I'm a bit overwhelmed by Kubernetes (VS Code's extension and Kube's documentation helps with that). I just want use the Azure Kube Service to deploy my Rails app...

I'm also trying to learn Docker Swarm mode and both the community and documentation are not as nearly comprehensive as Kubernetes'. And Docker's official documentation and tutorial has me provisioning 3 nodes on a cloud provider instead of just booting up a swarm on my local machine.

And then I see any # of combinations of Docker Swarm with tools like Terraform or Pulumi. It's just all so overwhelming.

I think I'm going to keep banging my head with Kube and its super verbose manifests until I finally get it.

[imiric]

It's been a while since I've read the Swarm documentation, but it was fairly comprehensive from what I remember. If you're referring to this tutorial[1], note that you don't need to use a cloud provider, and you can also do it with local VMs.

Actually you don't even need a cluster of machines. While Swarm can easily scale out, you can get started with a single machine and figure out the clustering later. Even on a single machine there are benefits of using Swarm over plain Docker (Compose): stacks, secrets, advanced networking. So you can test it out there and add more machines as you need it.

One thing I'd suggest is to first get familiar with Docker itself, since Swarm simply builds on these concepts and adds orchestration. Use `docker run`, understand volumes, images, permissions, user namespaces, cgroups, etc. Then move on to Docker Compose and get familiar with the configuration, services, etc. And then finally pick up Swarm, which even uses the same Docker Compose configuration file (with slight variations), so it should be fairly straightforward at that point.

Though honestly, learning Swarm in 2021 might not be a good investment, since Kubernetes is clearly the market leader, and I wouldn't be surprised to read a sunset notice about it, even though Docker Inc. is still supporting it. So you're probably making a good decision to stick with k8s.

Good luck!

[1]: https://docs.docker.com/engine/swarm/swarm-tutorial/