Hacker News Reader

Comment by zenexer | Hacker News Reader

I’m failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker’s death. Why would that be the case? Competition is great, but it’ll be a while before others can match Docker’s maturity and ubiquity. Even then, there’s no guarantee that any of them will be better than Docker, never mind good enough to warrant switching.

What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?

The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.

View on HN

You're missing the point of the author. It's not so much that Docker as a technology is bad; there's nothing wrong with it. The point is that Docker, the company, cannot monetize upon the technology, because the moment they start charging for their containerization technology, people will switch to an alternative container technology, especially now that Kubernetes has won the orchestration "wars" and made it so easy to switch the underlying technology.

Personally, I have to agree with the author and think it's difficult to see a bright future for the company that lives up to its $1.3B valuation.

The story of Docker, Inc should be read as a cautionary tale to those who think that every random bit of open source should be “monetized” by seeking rent for its continued use and support.

Or that open source isn’t always a good idea, at least from the point of view of certain parties.

Exactly, when will Silicon valley investors understand that Open Source:

1. Doesn't grow revenue at the speeds they want returns 2. Isn't "free marketing" (dear God I have seen this one too many times, CTOs even write it out in blogs sometimes) 3. Only really makes sense when you get out more than you put in, aka is community drive . Community driven open source is really the only profitable open source.

Would a $32B valuation of Red Hat make you reconsider?

That's a good point, there's huge market demand for technology and talent in the cloud native space.

However I don't see how Docker Inc can be substainable in the long run.

What's most likely to happen is Docker being acqui-hired by someone like Microsoft.

Understood, and I'm fairly certain that a large corporation that uses and markets Docker extensively will look to acquire it sometime in the future. Docker's ubiquity is exactly what makes it valuable.

Could be any of the FAANG companies but I posit Microsoft since they noticeably try to make Docker on Windows a seamless experience and also push Docker within their cloud offerings to modernize legacy apps towards Azure. They've already purchased a large community-oriented company (GitHub) and have acquired companies at a surprisingly high price (LinkedIn).

And considering most all docker containers are based on and continuously updated from a GitHub repo, a docker acquisition makes a lot of sense. Gitlab already has its own container registry.

There are actually a lot of issues with Docker around breakage and stability. That's alluded to in the article.

Docker itself is in trouble because they got the wrong use case from the start. They completely missed out about orchestration.

Containerization requires to both have containers (docker images) and deploy them on fleet of servers (kubernetes orchestration). The later is where the value is.

> Docker itself is in trouble because they got the wrong use case from the start. They completely missed out about orchestration.

That's actually how they started -- they were a PaaS called dotCloud before they were Docker!

This was before the term "orchestration" became common, but the point was that they were running apps in multiple languages. They were like Heroku except they supported more than one language (back when Heroku was basically Rails apps).

They didn't get much traction and had to pivot to Docker. I think the underlying reason is that writing a PaaS / distributed OS like Kubernetes is extremely difficult, and they were spread too thin. They didn't really nail a single use case like Heroku nailed Rails apps. They were trying to run everything and ended up running nothing.

----

This "rhyming" of history makes me smile, and makes me think how important timing is. dotCloud was the right product, done too early and done poorly. Docker was arugably the wrong product at the right time! I say "wrong" because I never thought it was a sustainable product or business, but it did come about at a time when people really needed a quick and dirty solution.

And now the surrounding ecosystem has changed drastically and I agree with the OP that Docker may be left out of it.

----

Another thing I find funny is that App Engine was already "serverless" 10+ years ago... you wrote Python apps and uploaded them as .zip files (web or batch processing). You didn't manage virtual machines. So somehow they were also a bit early, and maybe the product was lacking in some ways as a result.

Agreed.

I'm not sure that dotcloud and App Engine though were the right products though.

They have shown that a fully managed cloud solution is not the answer. Barely no company could use it, let alone migrate existing software to a whole new platform. It's limited to a very small niche.

Docker and Kubernetes are standalone products. Companies can use them internally and make it work with what they already have.

Amazon did it first with elastic apps, uploading a plain WAR file, and letting it run somehow, with transparent mySQL connections.

Docker Inc is fine. It would be silly to charge for the actual containerization because that's not really the value of their platform.

Things Docker can/does charge for and could do very well with.

- Support: Businesses are happy to pay maintenance contracts for fixed LTS versions of Docker which is their EE product.

- Kube: Docker has pivoted their UCP product into a turnkey on-prem Kubernetes distribution. Plenty of room in that space to grow.

- Registry; You wouldn't run random images from DockerHub in production, right? Similar to Red Hat's product in this space there's a lot of money to be made in having officially supported images. Images with a pedigree, aduit trail, CVE reporting, yada yada. Partner with Canonical and since it's way easier to do this when you already have distro maintainers and you have a solid RH competitor that devs will like more.

- Security: Audit your images that have been sitting around and not updated in ages.

- Hosting: They'll be one of many but there's plenty of space in providing some ergonomics compared to Google/AWS's offerings.

That's not a billion dollars company though.

Seems like it's more valuable and ubiquitous than mongo db, and their valuations exceed 1.5B

Ubiquitous does not equal value. Docker doesn’t do anything you can’t do with lxc tooling and an object store (registry). That’s the benefit: containers are free, the orchestration is free, and the registry tooling is free and easily replicated.

Mongo equally so (JSON in PostgreSQL). These valuations are fantasy.

Building a scalable service on top of that is not free, nor easy :)

You're spending those scaling dollars regardless (developers with devops knowledge, infrastructure/SRE folks). Better to spend it on competent staff than a company lighting VC money on fire, no?

i think it's a bit more complicated than that. very skilled developers that know this tech won't jump ship to many borderline broke startups which could easily just get started with docker with less than 'rockstar' devs

> Better to spend it on competent staff than a company lighting VC money on fire, no?

False dichotomy though. You either acknowledge that getting a vendor to do that for you also implies competent staff or you acknowledge that hiring "competent staff" is not like flipping a switch and requires training, ramp-up time, few wrong hires, getting managers to guide the teams, etc

I'm not sure which way is better, but I don't think the industry has decided either :)

It's already a billion dollar company.

https://techcrunch.com/2018/10/15/docker-has-raised-92-milli...

That's the point of parent and the article: It has a billion dollar valuation, but they doubt it can back that up with actual revenue and profits.

Of course not, a product company like docker is built for acquisition.

I can think of a few companies that might want to buy Docker. I can think of no company that would buy it at a billion dollar valuation.

I can think of a few companies that may pay an absurd vaulation for Docker; IBM and Microsoft.

Microsoft's containerization strategy heavily depends on Docker (they've got a licensing deal so that Windows server can use Docker EE for free) they might well pay good money to by Docker

Didn't IBM just buy Red Hat for $34 Billion? Can you imagine a future where Amazon acquires Docker to optimize it to run on AWS and perhaps perform a bit worse on GCP. Any small advantage you could get in the space would equate to large changes with as ubiquitous Docker is and as large as AWS is.

Perhaps but given AWS is a heavy Xen and KVM shop something like Kata Containers might suit them better.

Dockerhub doesn’t even support MFA, not to mention their IAM is all or nothing (there’s only 2 roles). I don’t think they’re focusing on the things that they should be.

Well, if you're focused on MFA and elaborate IAM for Dockerhub as "big problems", then I don’t think you're focusing on the things that you should be.

Those are more like enterprise checklist items than real needs...

Yes. As a response to a comment talking about enterprise support contracts as a main source of revenue for Docker, I think enterprise checklist items are entirely valid items to focus on.

I guess if the focus is "enterprise support contracts", that's legit.

Well this is the inherent push-pull of the industry, isn't it? The ones with money generally have insane compliance requirements (because they have money, they have more risk); the places without money care more about getting things done (since they're trying to make money...).

If it weren't so, we'd all just sell our hot new WhateverAsAService to banks straight away, right?

Fun fact: if you use Red Hat, you have to use Docker EE. You don't even have the option of getting CE and taking responsibility for Docker support yourself.

Could you explain that a bit more?

That isn't true. You can also use podman, and cri-o in the case of Kubernetes.

> if you use Red Hat...

"Red Hat" as in RHEL specifically, or are you meaning any of the family (eg CentOS)?

Asking because I've not hit any problems using Docker CE with CentOS 7. Well, aside from general bugs (etc). But nothing seems to force the use of EE instead of CE.

Docker CE is officially supported (well, it's not supported because its CE, but it's packaged, repos, install guide) etc. but only EE is packaged for RHEL. RedHat also has their own docker package like many other distros, so you can still get it free easily, but you have to get it through them and wait on them for updates.

If you're using RHEL why wouldn't you default to using Red Hat's build of Docker? I definitely prefer it to the official builds. Red Hat in general seems very annoyed at Docker and carries quite a few QoL patches like being able to add registries to search.

Also: container orchestration if _far_ from solved problem. Kubernetes is a nice try, but it screams for a better layer above it that would allow devs to deploy services _easily_.

There is plenty of ways Docker Inc. can create and capture value in this space. Their unique value is that whatever product they make, the world will check it out... They "just" need to make it good and figure out the business behind it.

> The point is that Docker, the company, cannot monetize upon the technology, because the moment they start charging for their containerization technology, people will switch to an alternative container technology...

I see the thought process but disagree with the premise that they need to charge for their container technology directly.

For example, GitHub does not charge for git, but instead for the convenient layers that they add on top of it.

Another example is that Google does not charge for Kubernetes but you can buy support which every enterprise company wants and since GKE happens to be the most convenient way to get a K8s cluster rolling in the cloud (for most circumstances) and also now on a box now with GKE On-Prem, many will choose that path so Google still gets their money, just from product / services / support on top of the free core.

They can also monetize the "fallout paths" — turns out you're in over your head running all of that K8s stuff yourself? Come pay us more and use our K8s PaaS instead! Not sure if they actually have one yet, but consider something like GKE Serverless here.

Enterprise features and support around running containers in production are worth a lot of money.

Docker can continue charging for all of its porcelain layers on top like Docker Hub and Docker Enterprise and make plenty of money off of big fish.

They could also monetize by being acquired by Microsoft, Google, or Amazon.

1. GitHub was struggling badly. They had lay-offs, etc.

2. Google still makes the lion's share of it's money from search/ads. Google Compute is struggling and being subsidized by search/ads.

IMHO, Docker's only exit strategy is to sell. They don't have enough time left to grow an organic business. Silicon Valley money always wants paid back, sooner rather than later.

The layoffs and new CFO at Docker, IMHO, are all about cleaning up the finances so that a sale is possible at a good price.

Their last round of investment barely averted a down round. The value bump was minimal and the investors are mostly from a bank in Brazil that likely doesn't understand exactly what they bought into (a lot of uneducated money out there right now because there is no place to put it). None of the original investors participated which shows they don't believe in the company anymore.

Their most valuable asset is Windows support. Hence, the most likely aquirerer would be Microsoft. I'll bet a paycheck they sell for somewhere between 1.5B and 2.5B. Keep this thread for posterity :-)

It's painfully obvious to anybody that has been in this game for a while...

(opinions and analysis my own)

1 - Having too many people is more an indicator that they hired too fast or more than they could sustainably afford rather than indicating anything about their inherent monetization strategy and approach. Every company has a ceiling somewhere, even if it's getting acquired by Microsoft for $7.5B. That's a pretty nice ceiling to have.

2 - That seems fine and besides the point... Google is massive. Google Cloud (excluding the half that comes from G Suite) brings in $2B per year in revenue. That might only be a few percent of Google's overall, but a few percent of $80B is still a massive number.

I read the finer point of the argument to be that Docker got the layer of abstraction wrong for monetization. That Kubernetes (which orchestrates containers) is the tool at the layer of abstraction where a company could provide a product that has enterprise demand similar to Red Hat. And that Docker is a replaceable piece of technology in the market of managing cloud architecture.

> What’s wrong with Docker?

What's wrong with not using Docker? Outside of cloud/SOA/webscale sector, people having hard time to simply comprehend the drama.

I have not seen any justification for using containers on any scaleable system on real hardware for example.

In "ad-farm" world, running ad farms on pure hardware with netboot provisioning has been the "gold standard" since time immemorial.

Few points:

1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.)

2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems.

3. Less attack surface for hackers.

4. Hard lockup proof - hardware watchdogs are more or less foolproof.

5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network.

6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.

Containerization is a cost effective alternative to building and running immutable VM images, which is a best practice in terms of CD. Another way to put it is: don't build in production, instead build in CI, test your image and then just deploy it on your environments (you probably should have at least two: staging and production).

One reason I see as an open source developer is low touch adoption and environment control. Over with build support on many Linux flavors (redhat from the past, archlinux from the ghetto :) ), use dockerized version instead. This might be my narrow corner of the world but users have driven me to dockerize much of what I do code, and my support hassle has lowered, a lot.

That sounds like a pretty solid system, but it’s not at all what the author is advocating. The author states that Docker is destined to be replaced by other containerization frameworks. The functionality differences won’t be as stark as what you’ve described, so this isn’t really a good comparison.

That being said, I’d agree that netboot + tmpfs has a lot of advantages; unfortunately, it’s not always practical, especially at smaller scales. Containers are convenient and don’t require any special hardware accommodations.

Exactly, we have POCed Docker and realised we have a solution for every aspect that it is trying to address. I found one and exactly one use case for Docker, running CI/CD workload.

You kinda missed the point that docker is more about packaging the applications than running them. Running apps is easy. Packaging in such a way that they could be run without hassle - hard.

> could be run without hassle - hard.

Strict versioning of every dependency - exactly the thing a packaging system solves.

Specific system configuration? Also not a problem at all with netboot images.

Can I run netboot images anywhere easily from my command line?

Few companies that used them that I dealt with had their own tooling, but that was nothing special.

CI picks up your image build, then commits its record to a DB from which DHCP server looks up a boot image for given MAC, then it either SSHed a reboot command or used an IPMI reboot. Voila

Today, some server motherboard firmwares can boot images off HTTP, vlan, and can talk with the boot server itself on HTTP

Much more straightforward than docker!

You could have if HashiCorp had beaten Docker to market with a simple VagrantHub and bud tool...

It could have easily been VMs instead of containers. IMHO, it was all the packaging...

~$ qemu diskimage.img

Former Amazon engineer here. Despite the downvotes, you are making an excellent point.

Amazon, among other FAANG companies, never needed containers shipping entire bundled OSes.

Deploying a "base OS" (using PXE or netboot) can be done very reliably both on a hypervisors and VMs.

A simple build system can then generate traditional packages and push them into VMs allocated for a specific product.

It provides better security isolation and the ability to receive security updates on OSes and also on dynamically linked libraries.

Building and deploying new versions of you product is also much faster, especially at large scale: only your application package is rebuilt and deployed.

That's technically what companies with refined processes do by using "scratch" docker images that only contain the binaries needed for the application and nothing else.

The fact that many other containers run entire OS is because it's easier to get started, or there are runtimes needed, or people just build and deploy in the same image.

I agree that developed companies are doing what is described, but that is a completely separate thing than starting from scratch.

People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/19/2/linux-distributions-stil...

Even when you write a lot of software, environments always drag in existing tools and infrastructure (aka other open source). 99% it's easier to consume pre-built SME knowledge from. Linux distro #HailTheMaintainers

Exactly.

I see Docker as a framework. It's the "get me from nothing" to a fully featured solution for building, running and distributing containerized applications. And it happens to do it for anyone running Windows, MacOS or Linux.

It's the same reason why I would want to use a web framework. I don't necessarily want to write and string together a bunch of super low level things. I want to start at a higher level of abstraction so I can focus on writing the applications I care about.

As an end user, I don't necessarily care too much about OCI or the runtime spec. I care about running docker-compose up and having everything work.

The article is about the company, not the product. Which bits of what Docker provides would you pay for, given free alternatives exist now for basically all of it?

To be fair, the article is about both. To quote "in my humble opinion the days for Docker as a company are numbered and maybe also a technology as well."

I don't think I would pay for any of the core features, but that's mainly because I've been using Docker for 5 years with the current strategy of just about everything is open source. You pay if you want support and other enterprise features. Private hub repos are also reasonable to buy for most people because it's priced pretty competitively with rolling your own private registry on a cloud provider (ie. $7 / month for 5 repos isn't much more than $5 / month for the cheapest DO droplet but now you need to manage that machine yourself which is not worth the hassle for $2 less).

I would pay for an ecosystem of images that are vetted for security issues. They could even build an industry around security and privacy compliance and certification, which risk-averse companies (and those who want to do business with them) would pay for.

> Why would I want to switch to something else?

The core argument is that you wouldn't care if you were using something else. I use Kubernetes. That's what I care about. If I'm on AKS, GKE, EKS, any other managed Kubernetes service, the only time I ever even see the word Docker is in the filename of the Dockerfile. They could switch their default runtime to anything else and I might not notice.

> Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?

This is the exact same problem that Oracle has with Java, and MongoDB now has with their product. You can't make money off of an API, and implementation's are very rarely a differentiator. Another product will come along (actually, several already exist) that says "we support dockerfiles, we emulate the docker api, swap us out". There's nothing new to learn. The only thing that product needs is a benefit over normal docker, and if you think Amazon, Google, or Microsoft can't add value through more native integration with their cloud services, you're crazy.

Docker isn't going anywhere, but they become commoditized far too quickly than their valuation would suggest.

"Why would that be the case?"

One argument could be that their moat is mostly brand. And, increasingly, other brands are working around them. Like Kubernetes. They already offer non-docker runtimes. They could, at some point, offer and promote their own packaging tool too. People might use a K8S tool solely because it's the "default setting".

I have a ton of docker images already that work perfectly fine. Why would I switch to something else?

These container images will continue to work.

There will be more created in the future, than was in the past.

The OCI standards make it so that it doesn't matter if you switch or not. Your images will work anywhere with any tool (aka Cloud Providers, Kubernetes, Podman, Buildah, etc.) Everybody has OCI compliant tools, even Docker - Docker founded the OCI.

Same point though. If docker works, why switch to anything else?

"The Kubernetes project is excited to announce kocker, a new docker compatible image management tool. Kocker will support features you've been asking for, like non-priv-by-default containers, enhanced performance in k8s..."

Made up, but I imagine something like that.

That's podman you are describing an it alrwady exists.

Docker is drifting towards being a standardizes deployment unit. This is especially apparent with advent of Alpine Linux based images or even more so with distroless.

With these changes going on, docker becomes just a fancy zip file, and since now there is a committee to design a standardized container there really is nothing left for for the Docker company.

Kubernetes IMO just used Docker's popularity to gain its own, but at this point the actual docker itself is no longer essential.

> What’s wrong with Docker? Why would I want to switch to something else?

Security, performance, reliability and following best engineering practices. Everything else is fine.

https://arxiv.org/pdf/1804.05039.pdf

https://hackernoon.com/another-reason-why-your-docker-contai...

https://www.scylladb.com/2018/08/09/cost-containerization-sc...

https://thehftguy.com/2017/02/23/docker-in-production-an-upd...

http://catern.com/posts/docker.html

It's kinda useless when it's not compared against alternatives.

A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).

The alternative solution has been working for decades: software packaging.

Not even remotely accessible to end users like containers are today.

Except it hasn't been working; with few exceptions we still deal with dependency hell / isolation issues in system package managers. Surely if it worked as well as you posit we would have long ago had a Kubernetes built upon apt or yum?

I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. Apt and yum are not the right set of tools for this job, Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.

> I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing.

I'm not sure what you're advocating for exactly, but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. This was suboptimal so Google et al pioneered containers and others followed suit. This is exactly what gave rise to Docker and Kubernetes. This seems a lot like saying, "ships solved the transportation problem so planes are not useful".

Never mind that most people don't have the resources to build, maintain, and operate their own orchestration systems.

> Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.

Build tooling is an important but orthogonal concern (you can use Bazel and friends to build container images). I'm not sure what you mean when you say Kubernetes doesn't solve those problems today.

To be clear, I'm not a Docker/K8s fanatic; they can be frustrating at times and something better will surely come along and replace them eventually. However, they're a lot better than what existed before (which to be clear were not off-the-shelf solutions but rather patterns that a large, wealthy, competent organizations could use to build their own solution).

> I'm not sure what you're advocating for exactly

I am not advocating for anything just pointing out that the features atributed to Docker existed before.

> but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images.

Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably.

> Build tooling is an important but orthogonal concern

Is this why the same features set claimed by both things?

Again, what is the problem you are trying to solve with Docker/K8?

> I am not advocating for anything just pointing out that the features atributed to Docker existed before.

No one contends that they existed before in isolation or even as a proprietary assemblage; the contention is whether or not they were available as an off-the-shelf tool or a simpler assemblage that is affordable to companies who are not "leading tech companies".

> Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably.

Why do you think "Amazon never had such a system" is a definitive rebuttal to "most leading tech companies had a system like X"? In any case, tell me about the systems that existed at leading tech companies that were comparable to Docker and accessible/practical for non-industry leaders...

> Is this why the same features set claimed by both things?

I'm not sure how to parse this, but it sounds like you might be implying something like "because Docker has a naive image building story, its primary purpose is to be an softare build system".

> Again, what is the problem you are trying to solve with Docker/K8?

Docker solves for standard software packaging and distribution; kubernetes solves for standard, efficient software orchestration. Of course you can throw really smart, well-paid engineers at the problem to devise, build, maintain, and operate a bespoke system that accomplishes a similar end.

I used the Amazon system a lot and saying that "Apt and yum are not the right set of tools for this job" is incorrect.

APT and yum simply install packages assuming the dependencies resolve correctly. The [unnamed ;)] system could be modified to generate a set of .deb and .rpm files (with locked versions) to deploy a product.

It's still working very well for Amazon, and the company evaluated alternatives and choose to stick with packages because they have the right granularity.

Linux vs many BSD flavours.

https://containerjournal.com/2019/01/22/5-container-alternat...

Yep, you just gave me an idea of a blog post.

Reply on news.ycombinator.com