14 ms·

I doubt they would ever consider it, but I think Docker Inc's best move would be to push reset for Docker 2.0: - Fully embrace Kubernetes for orchestration -

by csears 10y ago

I doubt they would ever consider it, but I think Docker Inc's best move would be to push reset for Docker 2.0: - Fully embrace Kubernetes for orchestration - Drop Swarm - Roll Docker Engine back to its pre-1.12 scope - Get on board with standardizing the image format, now - Stop fighting Google and instead let them help you succeed A Docker distro of Kubernetes would do very well in enterprise on-prem or private cloud environments. They already have a great developer experience. Companies will pay for support on both. Continuing to oppose Kubernetes risks damaging the significant brand equity they've accrued as containers in production become mainstream.

hosh 10y ago
As the proverb goes, "Choose, or someone will choose for you." rkt is getting into Kubernetes as an alternative runtime engine: http://thenewstack.io/kubernetes-chief-we-back-docker-although-appc-might-have-merit/ http://thenewstack.io/kubernetes-chief-we-back-docker-althou... (2015) http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes.html http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-contai... (2016) Back then it was, "It's sad to see so much drama; Docker engine has much more traction." Remember all of that? The story is now, "hey, rkt lets us test out our framework for supporting alternative runtime engine". There's a shifting attitude there. Goodwill from the community is eroding. I don't know how long this window will remain open, but it won't remain open indefinitely.
- amouat 10y ago
  I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Also, Mesos have started shipping their own container runtime. This feels like an inflection point in the history of containers.
  - cyphar 10y ago
    > I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Actually, we're working on getting generic OCI runtimes supported (runC being an example of such a runtime). In principle, you should be able to swap out the OCI runtime and still get Kubernetes to work with that runtime. It's an exciting time. :D
felixgallo 10y ago
Unfortunately there is no way to justify a unicorn valuation if all that you have as an asset is an open source file format. Consider Vagrant -- like Docker, it's essentially a wrapper around other people's facilities and libraries. Mitchell and co appear to be trying to escape the trap by moving into nearby areas of real value, but there's no meaningful way to monetize Vagrant no matter how popular it is.
- kordless 10y ago
  > Unfortunately there is no way to justify a unicorn valuation Then it is indeed unfortunate that Docker is building infrastructure code which is tainted by the game theory surrounding the need for a unicorn valuation. Maybe that's the problem, instead of Docker itself.
  - sjellis 10y ago
    That is exactly the problem. Linux containerisation is done by building tooling that uses kernel-level features. You don't need a start-up with millions in VC funding to implement the basic feature-set. At the other end of the complexity scale, both flatpak and systemd-nspawn are more specialist containerisation tools, which are each largely the product of just one person.
  - cookiecaper 10y ago
    Docker itself is part of that problem, not separate to it. They willingly accepted almost $200 million in venture capital. We all know what the VC game is. If they can't turn that $200M into a $5B+ exit, they lost.
    - dragonwriter 10y ago
      > If they can't turn that $200M into a $5B+ exit, they lost. Well, the VCs lost. Presumably, the people at Docker -- including the people who would do fantastically well with an exit that also made VCs happy -- are drawing paychecks, in some cases substantial ones, and will have in many cases done tolerably well (rather than have "lost") if no VC-friendly exit ever occurs.
kuberwho 10y ago
Kubernetes was founded by a former Google Engineer. I'm getting tired of being told every aspect of our developer lives or lives in general will only be better if we submit to some Google designed or related technology.
- cyphar 10y ago
  Except of course considering the fact that Google Engineers probably have some experience with scalability. Not to mention that the current Kubernetes community has an incredibly open design process, and is very community-oriented. So it's very far from its origins as an ex-Googler project.
  - cmcluck 10y ago
    Disclosure: I am one of the Google people who founded the k8s project. Product guy, not engineer though. We are really concerned about 'writing letters from the future' to the development community and trying to sell people on a set of solutions that were designed for internet scale problems and that don't necessarily apply to the real problems that engineers have. I spent a lot of time early on trying to figure out whether we wanted to compete with Docker, or embrace and support Docker. It was a pretty easy decision to make. We knew that Docker solved problems that we didn't have in the development domain, and Docker provided a neat set of experiences. We had 'better' container technology in the market (anyone remember LMCTFY?) but the magic was in how it was exposed to engineers and Docker put lightening in a bottle. The big things were creating a composable file system, and delivering a really strong tool chain are the obvious two, but there were others. I remember saying 'we will end up with a Betamax to Docker's VHS' and I believe that remains true. Having said that there are a number of things that weren't obvious to people who weren't running containers in product and at scale. It is not obvious how containers judiciously scheduled can drive your resource utilization substantially north of 50% for mixed workloads. It isn't obvious how much trouble you can get into with port mapping solutions at scale if you make the wrong decisions around network design. It isn't obvious that labels based solutions are the only practical way to add semantic meaning to running systems. It isn't obvious that you need to decentralize the control model (ala replication managers) to accomplish better scale and robustness. It isn't obvious that containers are most powerful when you add co-deployment with sidecar modules and use them as resource isolation frameworks (pods vs discrete containers), etc, etc, etc. The community would have got there eventually, we just figured we could help them get there quicker given our work and having been burned by missing this first time around with Borg. Our ambition was to find a way to connect a decade of experience to the community, and work in the open with the community to build something that solved our problems as much as outside developers problems. Omega (Borg's successor) captured some great ideas, but it certainly wasn't going the way we all hoped. Kind of classic second system problem. Please consider K8s a legitimate attempt to find a better way to build both internal Google systems and the next wave of cloud products in the open with the community. We are aware that we don't know everything and learned a lot by working with people like Clayton Coleman from Red Hat (and hundreds of other engineers) by building something in the open. I think k8s is far better than any system we could have built by ourselves. And in the end we only wrote a little over 50% of the system. Google has contributed, but I just don't see it as a Google system at this point.
kozikow 10y ago
Sadly, the current situation seems to be optimal for Docker inc, even if it is not optimal for users of Docker. K8s makes docker commoditized. For example, I am running GKE k8s cluster and I only use docker directly to take Dockerfile and produce an image. I push images to google replacement of docker hub - google container registry. I run things locally via minikube. If GKE would be using something custom to run images I would not even notice. I am close to the point that switching from docker to rkt would be barely noticeable.
- mstade 10y ago
  OT: any chance you have or will do a write up on your set up and process? It sounds interesting!
  - kozikow 10y ago
    This is pretty much what you would end up with when following official google cloud tutorials. Some time ago I started with https://cloud.google.com/python/django/container-engine https://cloud.google.com/python/django/container-engine. I still run django based on this tutorial in addition to a few more things. Some things like minikube are somewhat bleeding edge, so maybe they are worth describing.
ktamura 10y ago
>A Docker distro of Kubernetes would do very well in enterprise on-prem or private cloud environments. They already have a great developer experience. Companies will pay for support on both. Some early data here: https://twitter.com/dberkholz/status/720686568671940608 https://twitter.com/dberkholz/status/720686568671940608
- dmourati 10y ago
  Interesting thing about that survey is that it covers PaaS solutions (Cloud Foundry, Kubernetes, etc) on top of OpenStack. Other folks seem to be going in the other direction using PaaS to deploy OpenStack. https://tectonic.com/openstack/ https://tectonic.com/openstack/ http://www.tcpcloud.eu/en/blog/2016/06/27/making-openstack-production-ready-kubernetes-and-openstack-salt-part-2/ http://www.tcpcloud.eu/en/blog/2016/06/27/making-openstack-p...
jondubois 10y ago
Yes, I think the 'Not invented here' syndrome has reached epidemic proportions - Especially within open source communities where a lot of people create stuff from scratch just for the fun of it. When I read the article announcing Docker v1.12, it was riddled with enthusiasm - That's a red flag - This rarely happens in our industry. Working on open source is not like working in a startup; it's not like riding a roller coaster; it's more like riding the metro - You spend most of your time underground and when you finally arrive at your destination, the slow ascent up the escalator is rarely that exciting.
SEJeff 10y ago
One word for you: Investors They could never do that and expect to survive as a company as it would be "giving away" money on the table so to speak.

by csears 10y ago

hosh 10y ago

As the proverb goes, "Choose, or someone will choose for you." rkt is getting into Kubernetes as an alternative runtime engine: http://thenewstack.io/kubernetes-chief-we-back-docker-although-appc-might-have-merit/ http://thenewstack.io/kubernetes-chief-we-back-docker-althou... (2015) http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-container-engine-to-Kubernetes.html http://blog.kubernetes.io/2016/07/rktnetes-brings-rkt-contai... (2016) Back then it was, "It's sad to see so much drama; Docker engine has much more traction." Remember all of that? The story is now, "hey, rkt lets us test out our framework for supporting alternative runtime engine". There's a shifting attitude there. Goodwill from the community is eroding. I don't know how long this window will remain open, but it won't remain open indefinitely.

amouat 10y ago
I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Also, Mesos have started shipping their own container runtime. This feels like an inflection point in the history of containers.
- cyphar 10y ago
  > I think there's also momentum to add runc as an alternative runtime engine, which makes sense. Actually, we're working on getting generic OCI runtimes supported (runC being an example of such a runtime). In principle, you should be able to swap out the OCI runtime and still get Kubernetes to work with that runtime. It's an exciting time. :D

felixgallo 10y ago

Unfortunately there is no way to justify a unicorn valuation if all that you have as an asset is an open source file format. Consider Vagrant -- like Docker, it's essentially a wrapper around other people's facilities and libraries. Mitchell and co appear to be trying to escape the trap by moving into nearby areas of real value, but there's no meaningful way to monetize Vagrant no matter how popular it is.

kordless 10y ago
> Unfortunately there is no way to justify a unicorn valuation Then it is indeed unfortunate that Docker is building infrastructure code which is tainted by the game theory surrounding the need for a unicorn valuation. Maybe that's the problem, instead of Docker itself.
- sjellis 10y ago
  That is exactly the problem. Linux containerisation is done by building tooling that uses kernel-level features. You don't need a start-up with millions in VC funding to implement the basic feature-set. At the other end of the complexity scale, both flatpak and systemd-nspawn are more specialist containerisation tools, which are each largely the product of just one person.
- cookiecaper 10y ago
  Docker itself is part of that problem, not separate to it. They willingly accepted almost $200 million in venture capital. We all know what the VC game is. If they can't turn that $200M into a $5B+ exit, they lost.
  - dragonwriter 10y ago
    > If they can't turn that $200M into a $5B+ exit, they lost. Well, the VCs lost. Presumably, the people at Docker -- including the people who would do fantastically well with an exit that also made VCs happy -- are drawing paychecks, in some cases substantial ones, and will have in many cases done tolerably well (rather than have "lost") if no VC-friendly exit ever occurs.

kuberwho 10y ago

Kubernetes was founded by a former Google Engineer. I'm getting tired of being told every aspect of our developer lives or lives in general will only be better if we submit to some Google designed or related technology.

cyphar 10y ago
Except of course considering the fact that Google Engineers probably have some experience with scalability. Not to mention that the current Kubernetes community has an incredibly open design process, and is very community-oriented. So it's very far from its origins as an ex-Googler project.
- cmcluck 10y ago
  Disclosure: I am one of the Google people who founded the k8s project. Product guy, not engineer though. We are really concerned about 'writing letters from the future' to the development community and trying to sell people on a set of solutions that were designed for internet scale problems and that don't necessarily apply to the real problems that engineers have. I spent a lot of time early on trying to figure out whether we wanted to compete with Docker, or embrace and support Docker. It was a pretty easy decision to make. We knew that Docker solved problems that we didn't have in the development domain, and Docker provided a neat set of experiences. We had 'better' container technology in the market (anyone remember LMCTFY?) but the magic was in how it was exposed to engineers and Docker put lightening in a bottle. The big things were creating a composable file system, and delivering a really strong tool chain are the obvious two, but there were others. I remember saying 'we will end up with a Betamax to Docker's VHS' and I believe that remains true. Having said that there are a number of things that weren't obvious to people who weren't running containers in product and at scale. It is not obvious how containers judiciously scheduled can drive your resource utilization substantially north of 50% for mixed workloads. It isn't obvious how much trouble you can get into with port mapping solutions at scale if you make the wrong decisions around network design. It isn't obvious that labels based solutions are the only practical way to add semantic meaning to running systems. It isn't obvious that you need to decentralize the control model (ala replication managers) to accomplish better scale and robustness. It isn't obvious that containers are most powerful when you add co-deployment with sidecar modules and use them as resource isolation frameworks (pods vs discrete containers), etc, etc, etc. The community would have got there eventually, we just figured we could help them get there quicker given our work and having been burned by missing this first time around with Borg. Our ambition was to find a way to connect a decade of experience to the community, and work in the open with the community to build something that solved our problems as much as outside developers problems. Omega (Borg's successor) captured some great ideas, but it certainly wasn't going the way we all hoped. Kind of classic second system problem. Please consider K8s a legitimate attempt to find a better way to build both internal Google systems and the next wave of cloud products in the open with the community. We are aware that we don't know everything and learned a lot by working with people like Clayton Coleman from Red Hat (and hundreds of other engineers) by building something in the open. I think k8s is far better than any system we could have built by ourselves. And in the end we only wrote a little over 50% of the system. Google has contributed, but I just don't see it as a Google system at this point.

kozikow 10y ago

Sadly, the current situation seems to be optimal for Docker inc, even if it is not optimal for users of Docker. K8s makes docker commoditized. For example, I am running GKE k8s cluster and I only use docker directly to take Dockerfile and produce an image. I push images to google replacement of docker hub - google container registry. I run things locally via minikube. If GKE would be using something custom to run images I would not even notice. I am close to the point that switching from docker to rkt would be barely noticeable.

mstade 10y ago
OT: any chance you have or will do a write up on your set up and process? It sounds interesting!
- kozikow 10y ago
  This is pretty much what you would end up with when following official google cloud tutorials. Some time ago I started with https://cloud.google.com/python/django/container-engine https://cloud.google.com/python/django/container-engine. I still run django based on this tutorial in addition to a few more things. Some things like minikube are somewhat bleeding edge, so maybe they are worth describing.

ktamura 10y ago

>A Docker distro of Kubernetes would do very well in enterprise on-prem or private cloud environments. They already have a great developer experience. Companies will pay for support on both. Some early data here: https://twitter.com/dberkholz/status/720686568671940608 https://twitter.com/dberkholz/status/720686568671940608

dmourati 10y ago
Interesting thing about that survey is that it covers PaaS solutions (Cloud Foundry, Kubernetes, etc) on top of OpenStack. Other folks seem to be going in the other direction using PaaS to deploy OpenStack. https://tectonic.com/openstack/ https://tectonic.com/openstack/ http://www.tcpcloud.eu/en/blog/2016/06/27/making-openstack-production-ready-kubernetes-and-openstack-salt-part-2/ http://www.tcpcloud.eu/en/blog/2016/06/27/making-openstack-p...

jondubois 10y ago

Yes, I think the 'Not invented here' syndrome has reached epidemic proportions - Especially within open source communities where a lot of people create stuff from scratch just for the fun of it. When I read the article announcing Docker v1.12, it was riddled with enthusiasm - That's a red flag - This rarely happens in our industry. Working on open source is not like working in a startup; it's not like riding a roller coaster; it's more like riding the metro - You spend most of your time underground and when you finally arrive at your destination, the slow ascent up the escalator is rarely that exciting.

SEJeff 10y ago

One word for you: Investors They could never do that and expect to survive as a company as it would be "giving away" money on the table so to speak.