4 ms·

It seems like Docker is in a really awkward place as a company. Their strategy was clearly to get everyone on the container hyper train then monetize by selling

by mbell 8y ago

It seems like Docker is in a really awkward place as a company. Their strategy was clearly to get everyone on the container hyper train then monetize by selling the production orchestration / runtime. But Kubernetes happened and GCP / AWS have rolled out competition in all the other supporting system needed; container registries, build pipelines, etc. What is the actual pitch for Docker EE now? Their marketing is pushing hard on 'security', but otherwise it seems like they are just selling a pretty UI for K8s. I don't see that being enough to support a company that has taken 250M in funding.

dan_quixote 8y ago
The k8s community is moving full steam ahead toward replacing docker containers with OCI-compliant cri-o/podman. Docker had a good run with a great idea, but it doesn’t make sense to leave all of this vendor-agnostic tooling reliant on Docker (the company).
- radus 8y ago
  What about a docker-compose alternative?
  - mbell 8y ago
    https://github.com/kubernetes/kompose https://github.com/kubernetes/kompose or https://github.com/helm/helm https://github.com/helm/helm or keep using docker's dev client, it can target a locally running k8s now.
- rattray 8y ago
  Interesting, where can we learn more about this? (eg; cri-o, podman, I saw rkt mentioned elsewhere)
  - dan_quixote 8y ago
    This is a post explaining how the k8s community got to the current state: https://medium.com/cri-o/container-runtimes-clarity-342b62172dc3 https://medium.com/cri-o/container-runtimes-clarity-342b6217... And here’s a little info on why we’re using cri-o at SUSE: https://www.suse.com/c/cri-o-container-runtime-on-suse-caas-platform-3/ https://www.suse.com/c/cri-o-container-runtime-on-suse-caas-...
    - rattray 8y ago
      cool, thanks!
  - bacongobbler 8y ago
    hit up SIG-Architecture. https://github.com/kubernetes/community/tree/master/sig-architecture https://github.com/kubernetes/community/tree/master/sig-arch...
  - rwmj 8y ago
    I've been reading Dan Walsh's blog about podman & cri-o: https://medium.com/@rhatdan https://medium.com/@rhatdan (Disclaimer, I work in the same company, but not in the same department/group)
- raesene9 8y ago
  I don't think that all the k8s distros are looking at cri-o, I think that many are considering cri-containerd instead, which kind of makes sense as they're all using containerd, so whether you need a whole separate program to manage that interface is debatable.
skrebbel 8y ago
Wow, I'd never realized that. I wonder whether Google greenlighted significant investment into Kubernetes because they saw Docker Inc as a threat to Google Cloud and wanted to kill it early. It's not precisely the same playbook as Embrace, Extend, Extinguish and it's been played out significantly less evilly (is that a word?) and more openly, but, well, they embraced Docker, extended it with K8s and are now well on the path towards "extinguish".
- oblio 8y ago
  It's way more likely that Google was targeting Amazon with Kubernetes. AWS is the leading cloud providing and commoditizing cloud computing with containers would level the playing field and maybe even tilt it towards the creator for the tool. It seems to have worked, at least a bit, since Kubernetes has gained adoption. AWS is still ahead, though.
- raesene9 8y ago
  Whilst I have no inside knowledge that's not the way I think this has developed. Docker got in as a container runtime, without any orchestration capabilities, then K8s came along to do orchestration but didn't provide it's own container runtime, so they used Docker. After that there was some tension as Docker wanted to move "up the stack" to provide features like orchestration (with Docker Swarm) but the k8s community saw that as unecessary, they wanted a simple container runtime to sit under their orchestration layer. Now we have options like cri-o or cri-containerd which are likely in the medium term to take over from Docker as the container runtime underneath Kubernetes installs. I'd expect that Docker will see more use in dev/test environments where full scale clusters are not required.
  - chii 8y ago
    > Docker wanted to move "up the stack" nobody who wants to make money likes being at the bottom of the stack (as it's where commoditization happens). Moving up means you have a bit more lock-in (via specific business requirements), and/or provide services that can be bought by stakeholders (vs a tech choice by the "lowly" engineers). This is why i want my infrastructure to be owned by a non-profit. Just maintain the commodity infrastructure, no fancy, shmancy value-adds.

by mbell 8y ago

dan_quixote 8y ago

The k8s community is moving full steam ahead toward replacing docker containers with OCI-compliant cri-o/podman. Docker had a good run with a great idea, but it doesn’t make sense to leave all of this vendor-agnostic tooling reliant on Docker (the company).

radus 8y ago
What about a docker-compose alternative?
- mbell 8y ago
  https://github.com/kubernetes/kompose https://github.com/kubernetes/kompose or https://github.com/helm/helm https://github.com/helm/helm or keep using docker's dev client, it can target a locally running k8s now.
rattray 8y ago
Interesting, where can we learn more about this? (eg; cri-o, podman, I saw rkt mentioned elsewhere)
- dan_quixote 8y ago
  This is a post explaining how the k8s community got to the current state: https://medium.com/cri-o/container-runtimes-clarity-342b62172dc3 https://medium.com/cri-o/container-runtimes-clarity-342b6217... And here’s a little info on why we’re using cri-o at SUSE: https://www.suse.com/c/cri-o-container-runtime-on-suse-caas-platform-3/ https://www.suse.com/c/cri-o-container-runtime-on-suse-caas-...
  - rattray 8y ago
    cool, thanks!
- bacongobbler 8y ago
  hit up SIG-Architecture. https://github.com/kubernetes/community/tree/master/sig-architecture https://github.com/kubernetes/community/tree/master/sig-arch...
- rwmj 8y ago
  I've been reading Dan Walsh's blog about podman & cri-o: https://medium.com/@rhatdan https://medium.com/@rhatdan (Disclaimer, I work in the same company, but not in the same department/group)
raesene9 8y ago
I don't think that all the k8s distros are looking at cri-o, I think that many are considering cri-containerd instead, which kind of makes sense as they're all using containerd, so whether you need a whole separate program to manage that interface is debatable.

skrebbel 8y ago

Wow, I'd never realized that. I wonder whether Google greenlighted significant investment into Kubernetes because they saw Docker Inc as a threat to Google Cloud and wanted to kill it early. It's not precisely the same playbook as Embrace, Extend, Extinguish and it's been played out significantly less evilly (is that a word?) and more openly, but, well, they embraced Docker, extended it with K8s and are now well on the path towards "extinguish".

oblio 8y ago
It's way more likely that Google was targeting Amazon with Kubernetes. AWS is the leading cloud providing and commoditizing cloud computing with containers would level the playing field and maybe even tilt it towards the creator for the tool. It seems to have worked, at least a bit, since Kubernetes has gained adoption. AWS is still ahead, though.
raesene9 8y ago
Whilst I have no inside knowledge that's not the way I think this has developed. Docker got in as a container runtime, without any orchestration capabilities, then K8s came along to do orchestration but didn't provide it's own container runtime, so they used Docker. After that there was some tension as Docker wanted to move "up the stack" to provide features like orchestration (with Docker Swarm) but the k8s community saw that as unecessary, they wanted a simple container runtime to sit under their orchestration layer. Now we have options like cri-o or cri-containerd which are likely in the medium term to take over from Docker as the container runtime underneath Kubernetes installs. I'd expect that Docker will see more use in dev/test environments where full scale clusters are not required.
- chii 8y ago
  > Docker wanted to move "up the stack" nobody who wants to make money likes being at the bottom of the stack (as it's where commoditization happens). Moving up means you have a bit more lock-in (via specific business requirements), and/or provide services that can be bought by stakeholders (vs a tech choice by the "lowly" engineers). This is why i want my infrastructure to be owned by a non-profit. Just maintain the commodity infrastructure, no fancy, shmancy value-adds.