Docker largely solved users’ problems so well—and for free—that there wasn’t much left to sell.
Since its debut in March 2013, Docker has captured the hearts, minds, and CLIs of the IT industry. But when most people talk about Docker, they’re talking about Docker Community Edition (CE), a popular command-line tool and open-source project, rather than Docker Enterprise Edition (EE), a portfolio of paid products targeted at businesses. Both are platforms created by Docker Inc., but while Docker CE skyrocketed in popularity, the company struggled to monetize the colossus it had created, eventually selling Docker EE to Mirantis in November 2019.
How did Docker CE—which, in keeping with the spirit of the community, I’ll refer to as Docker from here on out—become a tech darling overnight while Docker EE failed to achieve the same success? In my estimation, Docker EE struggled precisely because of Docker’s popularity, not in spite of it. A community-driven effort with a thriving ecosystem, replete with knowledge and reusable content, Docker largely solved users’ problems so well—and for free—that there wasn’t much left to sell. Meanwhile, the few gaps that Docker EE left open were quickly filled by other tools before the company could find a way in. It’s a lot of ground to cover, but together, let’s explore a few of the critical points at which Docker and Docker EE’s paths diverged.
The land before Docker
To appreciate Docker’s rise, we must first consider the technological landscape it entered into. Imagine it’s 2012: You’re watching the London Summer Olympics, bopping to “Gangnam Style,” and using VMs all over the place. Programmers are developing applications either by setting up a VM or installing directly to their desktop. QA is running automated test suites on shared Jenkins workers, which take hours to set up and must service multiple projects. System administrators deploy apps by provisioning a “vanilla” operating system, installing necessary requirements, configuring the app, then maintaining those long-lived servers with configuration management.
In retrospect, every step in this process was delicate and used unnecessary resources. VMs are a fantastic means of isolation, but workloads often don’t need operating system–level isolation from one another. Using VMs made environments hard to reliably reproduce, while bare
chroots made it hard to fully isolate processes. These flaws could lead to bugs, tests that passed locally but failed in CI, packages that weren’t reproducible, and unpredictable deployments. While the idea of process isolation already existed in the form of FreeBSD jails, Solaris Zones, LXC, and the like, it was neither cross-platform nor easy to adopt.
Docker would change all that.
Docker is the new black
Developed as an in-house tool at dotCloud, a platform as a service (PaaS) startup, Docker was first demoed to the public at PyCon in March 2013 and open sourced a few days later. It wasn’t related to dotCloud’s core business and seemed to have been inspired by a desire to share a useful tool with the community—one that could simplify environment isolation and allow even more workloads to be packed onto servers.
“They solved the whole problem and hit the ceiling of that problem: Create an image, build it, store it somewhere, and then run it. What else is there to do?”
Few foresaw how enthusiastically Docker would be received. By September of that year, its interactive tutorial had been run more than 10,000 times, and by June 2014 the platform had been downloaded over 2.75 million times and had 400 outside contributors. “Docker solved a real problem that real people were having, and that’s very rare,” says Kelsey Hightower, developer advocate at Google. It delivered on its promises of “build once, run anywhere” and “configure once, run anything,” and infrastructure engineers could learn it in less than a day.
“They focused on ease of use from the get-go,” adds Red Hat Kubernetes community manager Josh Berkus, recalling his experience working as a software consultant in 2015. “We could go [to a client] and say, ‘We want to use this, not just because it solves a technical problem, but because it’s literally easier than the other options.’”
Docker was more than a usable interface for isolating processes on Linux systems—it represented a paradigm shift. Containers enabled workloads to be ephemeral and reproducible, so sysadmins could build or reuse images with just runtime dependencies, load their application into it with Dockerfiles (“basically Bash scripts,” says Hightower), and have a network-isolated, user-isolated, and process-isolated environment. Its popularity was well-earned, but with such an effective free product available, Docker Inc. would have a hard time making bank further down the road.
“They put something out for free that nailed it, home run,” Hightower says. “They solved the whole problem and hit the ceiling of that problem: Create an image, build it, store it somewhere, and then run it. What else is there to do?”
Docker goes for gold
As adoption soared, dotCloud realized it had struck gold with Docker and focused entirely on productizing it. The company rebranded as Docker Inc. in October 2013 and sold the PaaS arm of the business to cloudControl in August 2014. Now, they were faced with the difficult task of developing a business plan around a tool they hadn’t planned to make money off of. “I think they did the right thing; they made this hard pivot,” says Hightower. “But what business plan do you have that says, ‘If any hard pivots ever show up that become more popular than [our PaaS business], this is what we should do about it’?”
As the company sought to monetize, it certainly got some products right, all of which live on in its offerings today. Docker Enterprise Support, which launched alongside Docker 1.0 in June 2014, is a natural fit for users in need of quick, reliable assistance, but it’s unclear whether it’s ever been able to fully fund the company. Between Docker’s ease of use and the plethora of existing expertise and free resources within the community, including meetups and countless tutorials, Enterprise Support had an uphill battle to, well, support Docker Inc.
The company also profits from its image registry, Docker Hub, which allows it to charge for unlimited access, private repositories, image vulnerability scanning, audit logging, and more. But prior attempts to monetize Docker Hub were less successful. The company introduced Docker Trusted Registry in June 2015 as a secure on-prem container registry with role-based access control features and vulnerability scanning, but it faced stiff competition from the likes of Red Hat and Amazon. It also tried to go the paid content route in 2016 with Docker Store, which hosted verified and trusted images, but the store was merged back in with Docker Hub after two years following pushback from the community over issues like needing to log in to download images.
Kubernetes killed the Docker Enterprise star
Where Docker EE really seemed to lose momentum was with container orchestration. In June 2014, just two days before the first DockerCon, Google introduced Kubernetes, an open-source container orchestration system. Like Docker, it solved a real problem engineers were having: managing the collective life cycles of their increasingly containerized workloads.
For Docker Inc. circa 2014, Kubernetes’ arrival was both a blessing and a curse. On the one hand, having one of the biggest companies in tech put its weight behind containers was great for driving adoption. On the other, it meant competition from a free and robust tool that carried Google’s cachet. Docker Inc.’s own open-source container clustering solution, Docker Swarm, had had its first commit just one month earlier, and users couldn’t help but compare the two.
Docker Swarm, which is still a free part of Docker today, “was not a production solution, because it had no feature for plugging into cloud storage in a reliable, repeatable way,” notes Berkus. While it’s easy to learn and embedded in the Docker toolset, it lacks features for addressing more complex use cases, not to mention the near-mythical reputation of Kubernetes.
Kubernetes also addressed a problem Docker Inc. hadn’t solved: persistent storage. Docker had become synonymous with ephemeral containers, thanks in part to the Twelve-Factor App methodology, which suggested healthy applications could be spun up or down frequently—the exact workflow Docker made easy. But applications still needed state for databases, caches, logs, and the like, that couldn’t be part of those disappearing containers. Kubernetes made storage stable and pluggable, and often only Kubernetes could be used in production due to its storage solutions and better cloud integrations. As developer and podcaster Dave Rael, writing for Stackify in 2019, put it: “Kubernetes is a great choice for all but the smallest and simplest of workloads.”
Docker Inc. still put up a fight. In 2017, the company integrated Docker Swarm into Docker EE and began building a tiered subscription offering around it—but by then, Kubernetes and its vast orbit of related tooling had firmly established itself as the gold standard for. In fact, Container Journal went so far as to proclaim 2017 the year “Kubernetes took over the container world.” It was the beginning of the end of Docker EE’s run at Docker Inc., presaging the sale to Mirantis.
Docker, Docker, everywhere
Today, Mirantis continues to maintain and release new versions of Docker EE, which has since been renamed the Mirantis Kubernetes Engine. Meanwhile, Docker Inc. uses classic open-source business strategies like support and licensing, in addition to its Docker Hub revenue stream, to fund its toolset. As a free, open-source product suite, Docker remains as fundamental to sysadmins and DevOps engineers as GNU utils; as Hightower puts it, “I don’t see Docker going anywhere.”
Docker remains as fundamental to sysadmins and DevOps engineers as GNU utils.
In February 2021, the company published a blog post sharing some of its adoption metrics, which showed 3.3 million Docker downloads in 2020 alone. A few interesting competitors have popped up—Podman is a daemonless container engine, and LXD also virtualizes the guest OS, providing a mix of VM and container capabilities—but the experts I spoke to agreed that Docker has captured the container engine market, and, with its ease of use and wide adoption, it’s difficult to see how any other technology could establish enough of a foothold to unsettle it.
To me, Docker Inc.’s struggle to monetize signals a thriving open-source ecosystem and tool. It’s easy to learn and use, and it safely and effectively packs more portable workloads onto servers. Many users can rely on knowledge freely available in the community to solve their problems, and where that fails there’s always Docker Inc.’s customer support. It may not have conquered the container orchestration space, but it holds an enduring place within the DevOps pantheon. So, while Docker EE’s sale to Mirantis may have signaled the end of an era to some, I prefer to consider it a sign that free, open-source software has won.