Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The fact that they had a $95 million round in 2015 and then a $23 million round in 2021 leads me to believe their valuation is a lot lower now.


Mirantis acquired Docker Enterprise, last year, so at the very least they lost whatever portion of their valuation was tied to that... though I can't imagine it was that much.


I’d imagine that some of their valuation was based on the future success of docker swarm and what they would monetise around it


Was there ever a technical reason why swarm never won out in the market? I've still got a couple of multi-node swarms that work great and are WAY easier to configure than k8s. I never really understood why it didn't take off.


This is kind of reductive. You could ask the same for nomad, mesos, and lots of other things. It wasn't just swarm vs k8s


> It wasn't just swarm vs k8s

I'm not seeing anything in their comment that would imply this.


How is it reductive?

I do ask the same question for all those other systems, or the meta-question: "How is it that the bloated monstrosity of Kubernetes somehow became the de-facto container orchestration tool?"

Is this just sysadmins buying themselves job security?


On the contrary, nobody was thinking of the sysadmins (until we injected the notion of Operators rather late).

Devs chose K8s, I think the evangelism phrase was “developer dopamine”. It felt like the Rails of DIY infra, where devs could inherit an opinioned pattern for doing n>1.

There’s still decades of resentment of devs being gated by IT.


Is that so? My experience is the opposite: devs don't want to learn Kubernetes YAML, they just want to git push and have someone else take care of deployment.


Devs chose K8s, really?


As someone who doesn't want to be a sysadmin, but wants to deploy applications to the cloud, the options are fairly limited. Kubernetes handles updates and scaling, networking between services, has managed offerings from all the major cloud providers, has an enormous ecosystem surrounding it, with many tools providing out of the box support for it.

I could use docker swarm, or nomad, but I have to manage infrastructure, write my own integrations, manage the underlying hardware.

Or I can run az aks create and be off to the races


Sure, at this point it's a self-fulfilling prophecy: K8s is almost the only game in town because...it's almost the only game in town.

But how did it get to that point? How did something so big and unwieldy that even billion-dollar cloud providers can't do upgrades on it properly (*cough* looking at you, EKS) become the go-to standard for running apps in containers?


Kubernetes had necessary features first, was more stable, and had many more options that enabled other teams to hang more features off the runtime. Flexibility on networking runtime and rbac both made a huge difference.

That and, unfortunately, the cloud vendors could fully deploy k8s for free because swarm was a hybrid enterprise product.


I'd also like to know more about this, since for smaller to medium sized deployments (think 1-100 nodes, maybe running between 1-1000 containers) Docker Swarm does seem like a pretty reasonable solution, especially with tools like Portainer ( https://www.portainer.io/ ) for a web based UI to manage it.

I guess some of the reasons for the popularity of Kubernetes could be:

  - Kubernetes had Google as a big name behind it, so there was a lot of development resources put into it and eventually, lots of learning resources available, in addition to overall publicity; for example, i don't think anything like this exists for Docker Swarm https://www.katacoda.com/courses/kubernetes
  - in addition to the marketing and PR, it got picked up as a solution for many managed offerings by cloud hosts (managed Docker Swarm has almost none), a bit like what happened with serverless and AWS Lambda
  - Kubernetes allows for CRDs, has a pretty good API and has a large ecosystem built around it, to help manage its complexity (even distros like K3s and MicroK8s could be mentioned), as well as many to implement additional functionality (Istio + Kiali come to mind)
  - this further snowballed into turn-key offerings like Rancher and OpenShift that had financial incentives behind them, the idea of building a new distro that vendor locks clients into a particular company's offering, resources, support etc.
  - almost everyone (oftentimes incorrectly) believes that they need to be able to scale a lot and therefore chased the hype
  - FOMO further motivated a whole bunch of developers to use Kubernetes for their projects, instead of looking at the alternatives like Docker Swarm or Nomad
  - however, knowing Kubernetes can help to be more easily onboarded and to work with deployments in many different companies (except for when it isn't), the skills carry over nicely
Of course, some of these may be my subjective views and not at all accurate.

Personally, i think something between Docker Swarm, Nomad and K3s would be the sweet spot for containerized app deployments and orchestration, but personally i just like the Docker Compose manifests more than i do Kubernetes' and it feels like the popularity of Helm (or Kustomize) supports this line of reasoning.

Ideally we wouldn't even need containers and something like FreeBSD jails with a user friendly API around it would be sufficient. But the popularity that Docker gained seems to highlight that perhaps something was missing from those older technologies.


> the popularity that Docker gained seems to highlight that perhaps something was missing from those older technologies.

I would put money on it being the Dockerfile and the developer UX around that.

I don't honestly find it any more slick to use than e.g. FreeBSD jails, but I've lived in unix for long enough that that's because I was re-using lots of knowledge I already had.

There's a comparison here to the fact that I'm perfectly comfortable writing SysV rc scripts (though BSD rc scripts are vastly more pleasant to put together) but I've watched enough people struggle their way to something that only mostly worked that I can see why for many people writing a systemd unit file instead is a vast improvement.


I think people really undervalue the base design of k8s that is responsible for the existence of CRDs and other related pluggability (even before TPR became CRDs).

Pretty much every other option was more closed and with no extensibility, plus docker swarm was plagued (at least from my PoV) with stories of instability... and I dunno about others, but I and various people I talked with were burned with running docker in production, something that k8s nicely repackaged removing a lot of the things that were problematic.

All this went into giving some serious base beyond marketing and PR - the closest I've seen from other players is classic Rancher and Nomad, and especially the latter seems much less capable.


I'm really sad that Swarm didn't take off.

I used it extensively at a job for deploying production replicas for developers and full-integration testing (the plan was to eventually deploy prod the same way). It was SO nice to use. If you could use docker-compose, then docker-swarm was a natural next step.

I can't remember the details (it's been a few years), but the biggest hangup I had was the default network "mesh" wasn't stable. But I was able to work around that by using a different implementation (i think it was the network mesh that came out of k8s at the time. Used etcd).


It all depends on what they got for the money. I have no idea what it's valuation is based on these numbers, but if $95M bought 15% and $23M bought about 3.5% then the valuation is about the same.

I'd expect the valuation to be lower also, but that's based on their revenue prospects, not their the $ amount of investments.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: