Just based on the details mentioned in the keynote, the services API and swarm features look very similar to what's offered by Kubernetes... service discovery, rolling updates, load balancing, health checks, auto-healing, advanced scheduling.
I guess this was to be expected, but it's also kind of sad. I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.
The problem for docker is that just by building docker engine, they don't really have a way to make money – so stuff like this is probably all an attempt to actually have differentiating products that can generate revenue.
I don't think this is an attempt by Docker to sell tools to make money. They are improving their ecosystem to make their company more relevant which may or may not snowball into other companies actually paying for their services (Docker Cloud, etc).
Few companies are investing in making money by selling tools. Instead, you see Google/Amazon/Microsoft improving their cloud offerings and hoping you will your money there. They are giving away their tools (Kubernetes, Visual Studio, etc) hoping their environments become more attractive to you.
I hope we are not repeating history with the "DAB" the same way the container spec in the past. The industry is tired of these format fights and we need standardization to move things forward. I would put more faith in the "DAB" format if it was announced as something coming from the CNCF or similar. During the keynote the Atomic Nulecule [1] format came to mind... I don't know how it compares but it looks similar.
I should clarify: CoreOS + Kubernetes using rocket by default. From what I understand, CoreOS is driving the effort to get rocket supported by Kubernetes. K8S looks like it is going for agnostic implementation.
There is a log of emphasis going on in Kube right now in making sure that there is lots of room for experimentation around container formats, tools, and architectures - while at the same time, trying to keep Docker working well at scale and introducing Rktnetes. There's also work being done around runc support and VMs (from the hyper guys). Ultimately containers are just processes (some of them kernels), images are just another archive format, and the glue is what makes them interesting.
> I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.
Here's my theory.
Kubernetes is a product given away to entice you to buy a service from Google. (Edit: a better way to put this is that Google have nothing to lose and everything to gain from giving away Kubernetes, insofar as GCP has the best hosted Kubernetes offering).
Docker can't make money from a service, so they need to sell a product.
Disclaimer: I work for Pivotal, we donate the majority of engineering to the Cloud Foundry project. Insofar as Docker are moving back into PaaSes, we're competitors.
If people start running their apps on Kubernetes, even on AWS- Google has a shot at getting them over to GCE/GKE. On the other hand, apps that are tied tightly to AWS services are very difficult to move.
Have you ever tried running Kubernetes yourself ? Kubernetes is cool yes, but only on GCE, and managed by Google people. Apart from that, its nowhere near usable.
Docker 1.12 does just what Docker does best: Making complex stuff simple to use and give control back to people.
I guess this was to be expected, but it's also kind of sad. I think it would have been a more strategic move to embrace Kubernetes instead of trying to compete with it.