The author offers some reasonably strong evidence to discuss:
1) rapid adoption of Kubernetes
2) shiftless response strategy
3) aspects of the response strategy that imply internal *recognition* the company won't last
4) changes to organizational structure / personnel
(I suspect, as other commenters have pointed out, that you are conflating Docker with LXC. This is understandable! Docker-the-company was/is very good with branding!)
The argument is Docker is the company, and that company is in the best case going to be acquired (go away gracefully) or melt away. The technology is immortalized in Moby.
The article doesn't make a concluding prognostication about Moby vis-à-vis Kubernetes but very clearly thinks the momentum is behind Kubernetes because of the incoherent strategy behind Moby (other than as a means to throw the technology a life line beyond the fate of Docker).
isn't that the point? Docker is just the company now, because docker spun out their technology into moby. there's still a binary on my computer called docker, but it seems that docker, inc wishes that weren't so.
Rkt is functionally different enough from Docker to be called a different tech, and Kubernetes is, like, a totally different category. Are you also calling bicycles, cars and motorbikes the same technology, because they all use the technology called "wheel" somewhere?
Typical for HN, the article got hidden. It's well known YC alumni have some additional HN mod permissions and Docker is YC S10 (Summer 2010 batch of YCombinator).
This comment was killed because the commenter is banned for serial abuse of HN. I'm going to unkill it because I don't like to leave smears unreplied to.
Moderators didn't touch this article or affect it in any way; users flagged it.
YC alumni do not have HN mod permissions or any ability to demote articles beyond the flagging ability all users get (once their karma passes 30).
If Docker's future is an acquisition, who will it be? I have not thought deeply about this, but like the author, I have also heard scuttlebutt.
From the "good for us" perspective, the community would not miss the company's leadership on Linux Container standardization nearly as much as the aggregation service that is DockerHub. But from the "good for the acquiring company" perspective, who would care? A GitHub or a RedHat has the mission and user base where it might make sense, but both companies already have plenty of their own infrastructure tooling. I'm also not sure either company would bid very hard against an Oracle or Google.
The most strategic acquirer sounds to my ear like Microsoft. Their recent Linux compatibility investments prove they might actually Extend instead of Extinguish. We've gotten some time to get used to Microsoft not being The Enemy anymore. Heck, you could even say I'd be a little enthusiastic if this news dropped.
I'm not sure how you put GitHub in the mix to acquire Docker, they are not a very big company in terms of revenue (currently they talk about a $200m run rate, which is pitiful even compared to RedHat).
But I agree Microsoft is the most likely buyer. They are probably just waiting for the bottom to fall out for Docker and they can snap it up for the right price.
An earlier draft of that comment had "not sure either company would bid very hard" phrased as "not sure either company has the financials to support" so I looked up RHT's market cap, saw it was in the 10s of billions, remembered GitHub is still privately held, and decided to stop the detailed research at that point.
Good catch, though. GitHub is a candidate because their core business model, like Most Linux Distributors, is built around aggregating and re-distributing open source software in a trustworthy fashion. (And support contracts around that.)
No acquisition is also a possibility. Neither Docker the tech nor Docker the company is too big to fail right now.
Oh my yes, the quiet release of CRI-O by RedHat and Google recently was a pivotal moment. You can run a container orchestration environment in production without anything from Docker the company. You still need it to build and maybe host images but the rest is pluggable.
It's been my impression that they're angling for either a VMWare or Microsoft acquisition. They both like buying things that live at the edge of enterprise-y and trendy.
I know what you meant, but I think it's helpful to talk about "trendy" in the context that matters: something popular that will either widen the competitive moat for existing customers, or bring in new customers that are soon to graduate into wanting enterprise support from a VMWare or a Microsoft.
VMWare is an interesting possibility! Docker seems like it would cannibalize too much of their existing product line, but VMWare's existing products are already kind of self-cannibalizing. (This is why many engineers find the enterprise market so confusing. Nobody differentiates products well, because past a certain size, networks of human relationships [sales, support, etc.] matter more than branding.)
But from that "good for us" perspective, VMWare looks as bad as Oracle these days. I would still "vote" for Microsoft.
Docker would fit nicely Microsoft’s Azure container offensive and new found love for all things Linux. They tried Mesosphere, but that didn’t work out.
Microsoft made an offer for Mesosphere, but they turned it down [0].
These deals are of course never that "snappy". They probably had long and hard negotiations, but the deal never happened.
Agree that Microsoft would be a plausible buyer. They have deep pockets, have hired ex-Docker engineers such as Jess Frazelle on the Azure team, and are investing heavily in the capability to run Linux-based Docker containers seamlessly on Windows. However, they still need to persuade people to use their stack. Aquiring Docker-the-company is the sort of thing Microsoft would do to buy their way into the market.
Despite the rise of Kubernetes, it's not for every use case and far from it. Docker Swarm and Docker Compose are extremely valuable with small deployments and development. It's by the far the easiest and simplest way to get a cluster up and running.
The use case I was initially attracted to was making it slightly easier to develop & test components in a service-oriented application. Docker Compose makes it possible to stand up a handful of services without too much fuss.
The main problem is that no one is going to setup their own Kubernetes cluster, it has become a commodity cloud service. You might run minikube on your laptop, but unless you are a large company with a dedicated Kubernetes team you are not going to run it yourself.
Docker swarm is easier and better if you just need a small local cluster. Though for most things just a single system setup with docker-compose will suffice.
The article title should probably differentiate between the state of Docker as a company, and Docker as a software product.
That said, with all major cloud providers now offering Kubernetes cluster management with a free Kubernetes host, and the economy-of-scale offered by those cloud providers driving the costs of cloud computing down, I'm not sure how Docker Swarm can compete.
It does, the entire point of the last section is that Docker, Inc's moves look very much like they're setting up for the survival of the tech (containerd and Moby) regardless of the company's.
The nature of clickbait titles is that they instill a misleadingly false, exaggerated, or ambiguous narrative that is not matched by the content. This title is ambiguous, and has lead many of us on with the more enticing (controversial) narrative that containerization is dead. It doesn't matter what is in the content.
Docker as a software product may die pretty soon as people switch to containerd which includes more or less all the functionality you want and none of the bugs you don't want.
Despite the rise of Kubernetes, it's not for every use case and far from it. Docker Swarm and Docker Compose are extremely valuable with small deployments and development. It's by the far the easiest and simplest way to get a cluster up and running.
> It is said that, “Great civilizations are not murdered. They commit suicide.” Docker has done just that.
It's easy to find fault. It's not easy to find solutions. Chris, what should Docker have done differently to succeed as a company during the rise of kubernetes?
Not a Docker fanboy, but...
- Docker !== Kubernetes.
- not liking a company !== the company’s product is obsolete.
- clumsy marketing !== the company’s product is obsolete.
I do agree with the sentiment that docker, the company, probably won't be around forever. I'm hopeful that the docker binary stays, however. It's not really useful in a business setting, but quite nice to experiment a little on developer machines.
TLDR - author disapproves of Docker's management & monetization strategy. However, offers no evidence for a "dying" docker. ClickBait.