4 ms·

Like the time when Kubernetes, prior to it being announced, could have been a joint collaboration between Docker and Google.

honkycat 7y ago
I am amazed at how Docker bricked on Docker Swarm so hard. I assert to this day that the only conclusion to choosing Docker Swarm is to rewrite a worse version of Kubernetes.
- voidmain0001 7y ago
  This developer, Gerhard Lazu, states otherwise regarding Kubernetes as he describes the infrastructure that he built for changelog.com based on Docker Swarm rather than K8s: https://changelog.com/podcast/254 https://changelog.com/podcast/254
- nickstinemates 7y ago
  Especially given we used to have Meetups at the office every Thursday night, where at least 1 new Orchestration project was launched/demoed every week. The initial project the team worked on was called Beam. After about 6 months and no progress to show, the conversations referenced above happened and this is the result.. Kubernetes launched at the first DockerCon[1], early 2014. Swarm was launched[2] in beta in Dec 2014. So, roughly 1 year late to market, 6 months after initial K8 launch. 1: https://www.youtube.com/watch?v=YrxnVKZeqK8 https://www.youtube.com/watch?v=YrxnVKZeqK8 2: https://blog.docker.com/2014/12/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/ https://blog.docker.com/2014/12/announcing-docker-machine-sw...
  - cpuguy83 7y ago
    I still rather like some of the output beam (libchan), just that GRPC came along and it's all history now. But yes agreed this was all completely frustrating at the time, and completely depressing now.
donmcronald 7y ago
That might have been great for Docker the company, but I wonder how it would have been for Docker the technology. Maybe Kubernetes would have ended up being less open. I don't know much about it beyond my own perception, but I think of the cloud vendors are doing as much as possible to seem neutral / safe while usurping business logic at every turn. Things like an API gateway that's specific to a cloud provider seem like nothing more than super risky vendor lock-in to me. Another example is all the serverless rage with tech like Lambda@Edge and the equivalents. Who's realistically going to move that type of stuff between providers once they hit a certain scale? However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible.
- nickstinemates 7y ago
  > However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible. That's great to hear as it means it has served its initial intended purpose. We take it for granted now, but the mere concept of doing this so easily in 2014 was really exciting stuff, especially when the workflow of build->publish to N cloud services is measured in minutes/seconds not hours/days.
zapita 7y ago
Wasn’t Kubernetes introduced at Dockercon, and entirely built around Docker from day one? Seems like a pretty close collaboration to me. What kind of collaboration could have taken place beyond that?
- TheDong 7y ago
  The two-ish years of Docker Swarm trying to fight with k8s and the weird tensions around Docker as the runtime in k8s probably wouldn't have happened if Docker had decided to join forces rather than actively compete. Anyone familiar with how the swarm and k8s politics played out would know it was not a collaboration at all.
  - zapita 7y ago
    I agree that Docker took too long to embrace Kubernetes once it was obvious it had more momentum than all other orchestration projects combined. But nickstinemates suggests that Docker could have and should have “collaborated” much sooner than that, even before Kubernetes had launched. I wonder what that means in practice. What exactly should Docker have done, that they didn’t? And how would it have changed the outcome?
    - wmf 7y ago
      Docker could have never created Swarm and Compose at all. In hindsight if they went all-in on k8s from the beginning then they might now be the leader in enterprise k8s instead of Red Hat and IBM would be buying them. But this wasn't clear at all in 2014-2015.
      - cpuguy83 7y ago
        Compose existed before k8s, and was created by a small company that Docker acquihired.
      - GordonS 7y ago
        Personally, I like Docker Compose and Swarm, at the very least for non-production workloads - they're just so much lighter and simpler than k8s. I actually would have liked to see Docker not give up on Swarm so readily. There's absolutely room for a something simpler than k8s.
cpuguy83 7y ago
This is definitely true, but as you say orchestration frameworks were a dime a dozen at the time, and Kubernetes, when launched at Dockercon, was barely that. Of course we actively chose to not collaborate on it, even after it matured a bit and had a good community.

honkycat 7y ago

I am amazed at how Docker bricked on Docker Swarm so hard. I assert to this day that the only conclusion to choosing Docker Swarm is to rewrite a worse version of Kubernetes.

voidmain0001 7y ago
This developer, Gerhard Lazu, states otherwise regarding Kubernetes as he describes the infrastructure that he built for changelog.com based on Docker Swarm rather than K8s: https://changelog.com/podcast/254 https://changelog.com/podcast/254
nickstinemates 7y ago
Especially given we used to have Meetups at the office every Thursday night, where at least 1 new Orchestration project was launched/demoed every week. The initial project the team worked on was called Beam. After about 6 months and no progress to show, the conversations referenced above happened and this is the result.. Kubernetes launched at the first DockerCon[1], early 2014. Swarm was launched[2] in beta in Dec 2014. So, roughly 1 year late to market, 6 months after initial K8 launch. 1: https://www.youtube.com/watch?v=YrxnVKZeqK8 https://www.youtube.com/watch?v=YrxnVKZeqK8 2: https://blog.docker.com/2014/12/announcing-docker-machine-swarm-and-compose-for-orchestrating-distributed-apps/ https://blog.docker.com/2014/12/announcing-docker-machine-sw...
- cpuguy83 7y ago
  I still rather like some of the output beam (libchan), just that GRPC came along and it's all history now. But yes agreed this was all completely frustrating at the time, and completely depressing now.

donmcronald 7y ago

That might have been great for Docker the company, but I wonder how it would have been for Docker the technology. Maybe Kubernetes would have ended up being less open. I don't know much about it beyond my own perception, but I think of the cloud vendors are doing as much as possible to seem neutral / safe while usurping business logic at every turn. Things like an API gateway that's specific to a cloud provider seem like nothing more than super risky vendor lock-in to me. Another example is all the serverless rage with tech like Lambda@Edge and the equivalents. Who's realistically going to move that type of stuff between providers once they hit a certain scale? However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible.

nickstinemates 7y ago
> However, I don't have that same cynical view of Docker. For me, Docker has become a safe bet of sorts. I know that anything running in a Docker container is pretty safe in terms of portability between cloud providers, so it becomes the default choice for me whenever possible. That's great to hear as it means it has served its initial intended purpose. We take it for granted now, but the mere concept of doing this so easily in 2014 was really exciting stuff, especially when the workflow of build->publish to N cloud services is measured in minutes/seconds not hours/days.

zapita 7y ago

Wasn’t Kubernetes introduced at Dockercon, and entirely built around Docker from day one? Seems like a pretty close collaboration to me. What kind of collaboration could have taken place beyond that?

TheDong 7y ago
The two-ish years of Docker Swarm trying to fight with k8s and the weird tensions around Docker as the runtime in k8s probably wouldn't have happened if Docker had decided to join forces rather than actively compete. Anyone familiar with how the swarm and k8s politics played out would know it was not a collaboration at all.
- zapita 7y ago
  I agree that Docker took too long to embrace Kubernetes once it was obvious it had more momentum than all other orchestration projects combined. But nickstinemates suggests that Docker could have and should have “collaborated” much sooner than that, even before Kubernetes had launched. I wonder what that means in practice. What exactly should Docker have done, that they didn’t? And how would it have changed the outcome?
  - wmf 7y ago
    Docker could have never created Swarm and Compose at all. In hindsight if they went all-in on k8s from the beginning then they might now be the leader in enterprise k8s instead of Red Hat and IBM would be buying them. But this wasn't clear at all in 2014-2015.
    - cpuguy83 7y ago
      Compose existed before k8s, and was created by a small company that Docker acquihired.
    - GordonS 7y ago
      Personally, I like Docker Compose and Swarm, at the very least for non-production workloads - they're just so much lighter and simpler than k8s. I actually would have liked to see Docker not give up on Swarm so readily. There's absolutely room for a something simpler than k8s.

cpuguy83 7y ago

This is definitely true, but as you say orchestration frameworks were a dime a dozen at the time, and Kubernetes, when launched at Dockercon, was barely that. Of course we actively chose to not collaborate on it, even after it matured a bit and had a good community.