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.
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.
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.
Those are more like enterprise checklist items than real needs...
If it weren't so, we'd all just sell our hot new WhateverAsAService to banks straight away, right?
Mongo equally so (JSON in PostgreSQL). These valuations are fantasy.
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 :)
https://techcrunch.com/2018/10/15/docker-has-raised-92-milli...
"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.
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).
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Strict versioning of every dependency - exactly the thing a packaging system solves.
Specific system configuration? Also not a problem at all with netboot images.
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
It could have easily been VMs instead of containers. IMHO, it was all the packaging...
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.
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 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.
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".
Made up, but I imagine something like that.
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.
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...
A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).
https://containerjournal.com/2019/01/22/5-container-alternat...
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 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?
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.
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.
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.