Docker closes $40M Series C led by Sequoia
blog.docker.com
blog.docker.com
The reason I say this is because a VC who merely breaks even on investments will eventually go out of business, so it would be a mistake to invest unless the expectation is that Docker might be a win for them.
Assuming Sequoia owns, say, 35%, then that comes to an expected acquisition price of about $1.15B for Sequoia to earn 10x their money back.
What are some hypothetical scenarios which end with Docker going public? What are some scenarios where a company would acquire Docker for north of $1B?
I'm not trying to imply anything about Docker with these questions. Personally, I love Docker. It's just fun to theorycraft.
That said the investors would certainly be looking for >$1bn exit.
Bingo!
I don't think anyone would be interested in taking a round that would dilute us this much, especially when the need for money is not pressing.
I was just wondering about some scenarios where Docker could achieve that kind of price.
disclaimer: I work at greylock, who was an earlier investor, though have _zero_ inside knowledge of the deal as I work on unrelated stuff.
Not that I'd imagine Sequoia has to do this or has any issues with deal-flow, but any company doing cool things running on containers, who's going to be the VC they call first?
Docker doesn't replace VMs but there is an intersection in their use cases.
If Docker was about to be acquired, why would there be any interest in raising a round? That dilutes everyone for no purpose. That's not smart.
VMware? Google? Amazon? RedHat? HP? IBM?
> If Docker was about to be acquired, why would there be any interest in raising a round? That dilutes everyone for no purpose. That's not smart.
It moves the valuation up and it increases the chances of being acquired.
Companies such as Microsoft and VMware who are leaders in the Windows application virtualization sector (via App-V and ThinApp) don't have complete solutions in this space.
Their solutions do a lot of tricks to simulate a container (e.g: user mode hooking, filtering drivers) while Docker uses kernel extensions.
Build-up a widely recognized brand. Have a complete offering (all the way up to mgmt of containers, as the picture shows). Stay neutral, support all platforms equally well, for some more time (before one of the platforms may buy it). Probably Docker is project a really ambitious picture of wanting to be the big-blue-platform-in-the-cloud in 5-10 years; a picture that --with enough series of funding-- may not even be so far out.
> dilutes everyone for no purpose. That's not smart.
Dilute 10-40% for a company that will soon be making several times the profits; that is very acceptable. If Docker would get there "in time" by itself, it would still make no sense.
But I think Docker knows they need to keep up building out their biz, or they will end up open-source-zoned: everyone knows and uses your product, but you make no serious profits.
Getting open-source-zoned is not a bad thing... Just not a straight ticket to the millions.
It will definitely be interesting.
I'm sure they would make for a very interesting case study on how to do open source right.
I think there have been some companies that have died that way, yeah. It's tough to make money from open source, if obviously not impossible. Think how hard it is to get a regular old sell-something-for-money business off the ground, then throw in a way more complicated business model and relationships with community, customers and so on.... it's complicated!
This is not correct.
The Docker engine has an ability to use LXC userland tools as an execution environment, but it is not the primary choice. libcontainer (github.com/docker/libcontainer) is. libcontainer has adoption outside of the Docker world (Parallels, CloudFoundry, as examples) which we find to be a fundamentally good thing.
We can also spend time talking about the non-technical values of Docker, if you'd like to jump in to that.
Yes, please expound. I am largely just a lone developer looking to use docker for my fairly small projects. I currently just use Git for deployment. Is there any value to moving to Docker?
We would prefer and encourage for competition to exist at this level, but also to support all of the options with Docker as execution drivers.
This is a small example of our approach in general - Instead of locking existing technology out, Docker is designed to integrate seamlessly the choices you're living with today. If we don't do that well, it's a bug. Let's fix it.
> How are Docker monetizing their product?
We offer commercial support for Docker and also offer paid features on Docker Hub.
> Competition?
Docker is Apache 2 licensed. Anyone can fork Docker and start monetizing it tomorrow in a completely different way than we had anticipated.
This is actually a good thing. There's a separation of Docker between the project and the company, and there's a virtuous cycle of the company aligning to the objectives of the project and the project benefiting by all of the business-y things you can do.
> Competitive Advantage
We don't own the project, the community does. We fundamentally believe the value of a platform or ecosystem is proportional to the amount of competition it brings to everyone. As per above, we have no interest in locking in a competitive advantage on the Docker project that only we can benefit from.
> Doing Open Source Right
We have a long ways to go! We're certainly trying something new - but we've gathered a lot of momentum and our focus is just to continue working with the community, our great partners, and work diligently to deliver great product and support to our users.
But competition has nothing to do with open source. Source code is not a competitive advantage, even if you get minor quality improvements like increased code visibility and test coverage. No open source company has ever forked code from an existing product, started a competing business, and stolen business away from the originator. Companies that provide services on top of other people's code, however, often fall victim to a better sales pitch, customized tailored services or a shift in direction.
And honestly, the idea that 'the community' owns the Docker project is a joke. Is the community getting 40 million dollars? Is the community making the design decisions for the product? Is the community pushing the integration of your tool with other companies and services? As far as I can see, you have a company based on a product, and you give that product away because it costs you nothing to do so. Open Source is a marketing tool, and a great one at that.
Your main point stands, but one counter-example perhaps worth mentioning is MariaDB (the Enterprise version[1], not just the free version[2]). Oracle's treatment of MySQL was enough to force a reaction from the community to fork and continue to build a drop-in replacement. Although, for the same analogy to apply here a majority of the core Docker developers would need to defect to DockerFork.
> The partnerships you make build your product into other products, making it the default option for anything someone might need to do with containers.
I think you can view some partnerships through that lens, but as a whole I do not believe this statement holds at all.
My #1 partnering goal is to make sure that the interest that exists in Docker can be realized on the services and products that people are using today. You'll never see us form a partnership that has any conclusion, whether direct or indirect, that the only proper way to use docker is in combination with partner technology X.
I think you could also view projects like libcontainer, which is written by some of the maintainers of Docker, and understand that it's being used by other projects not related to Docker at all. In some cases, even by perceived competition (like Pivotal.)
> Then you increase the visibility of the product (and thus the company) by getting lots of PR and making sure VCs and potential customers read it.
It is important to highlight the reasons we make these partnerships - I can assure you, it's not to get VC attention. That's completely short-sighted and unsustainable.
To the best we can, we deflect the visibility on the project on to others, big or small, doing great things with Docker.
> And honestly, the idea that 'the community' owns the Docker project is a joke.
I'm not laughing. Maybe you're not familiar with how the Apache 2 license works. I'd get familiar with that. Link: http://en.wikipedia.org/wiki/Apache_License
> Is the community making the design decisions for the product?
Yes. The projects design is open. There is no privileged discussion about the Docker project - it happens all in the open on GitHub and IRC. If there's a specific area of conversation that requires in-depth collaboration, we sponsor people to meet in person. This happens regularly.
> Is the community pushing the integration of your tool with other companies and services?
Yes. Red Hat is a perfect example. Pre-0.7, any Red Hat customer could not use Docker because of 1) AUFS not being available on the platform, 2) Docker not being supported on Red Hat. So anyone using Docker on Red Hat at that time was breaking their agreement. That's a problem.
> As far as I can see, you have a company based on a product, and you give that product away because it costs you nothing to do so. Open Source is a marketing tool, and a great one at that.
We can argue the relative advantages and disadvantages of free vs. commercially licensed software all day. You can write Docker off as a sheer marketing ploy, but, I'd say that's a pretty disingenuous statement to make at an individual level of the company.
I'll also say, the trade-off does not come without cost. It's not even close to free.
In my world of bootstrapped, smaller apps looking for market traction, even if things go well, a few Linodes should be enough to handle most of the traffic I'll ever need to deal with, so this kind of thing is kind of foreign to me. I'm curious how people utilize it in practice.
In a nutshell, for me the value is in trivial repeatability. I can reproduce the entire build toolchain, test environment and produce artifacts all from a few KiB git repo which centres around the Dockerfile and submodules to dependencies.
Some of my ARM stuff takes hours to cross-compile and involves enormous amounts of fiddly babysitting normally. Dockerfiles have RUN statements (think lines a shell script) which are cached. My adjustments toward the end of a Dockerfile take only seconds to test and produces the exact same result as if it had really run each statement from the start, which doesn't sound like much but turns out (for me) to be pretty liberating compared to constantly trying to fight other automation where you have to dance around short-circuiting stuff to re-use bits of a past build to save time and get only a handful of "pristine" iterations in a day (that might differ to the iterations you rolled by hand).
There's two types of ARM builds, ones which can cross-compile and those that can't. The ones which can't cross-compile are done with qemu-binfmts and we chroot into an ARM filesystem and run the build there.
Perhaps the only useful contribution would be the fact that I persist the ccache up to the docker host with a shared ccache volume, and that helps enormously especially for the qemu-binfmts builds which can be quite slow.
For example, say I need libfoo, I have an amd64 host (being the docker container). Sometimes I just can't get the libfoo:armhf or libfoo-dev:armhf package installed because it would break/conflict with the amd64 host's version of it in some way. xapt often helps but then sometimes screws up by re-packaging something that has an "all" arch (non-arch-specific) to something armhf specific (eg. foo-data). This ultimately either conflicts with the host or fails to be named properly in such a way that it meets the build-deps of the project.
Sometimes I know it would be easier in some cases to avoid the debian packaging ecosystem, but for my workflow and distribution requirements it brings a lot of benefits.
Edit: see here https://wiki.debian.org/EmdebianToolchain
For me, my VMs are actually dead simple and relatively homogeneous. Fresh install + lock down SSH + lock down iptables + install Git + install Docker.
Then I build from the correct Dockerfile and open whichever port(s) on the VM. Bang, instant node that does [whatever]. Time to upgrade the DB/mail server/app? Build from the new Dockerfile, stop the existing container, bring up the new one. No worrying about installing/uninstalling the correct dependencies on the VM and getting into an inconsistent state.
That's what Docker does for you.
Don't get me wrong, I think docker is great, but this whole "I get simple idempotent machines" is a solved problem. Docker excels at bundling applications with all their dependencies as an modern analogue to statically linking, or a Linux equivalent to OSX's .app
I find it's easier to make the OS part as simple as possible and use Docker for everything else since you can strictly enforce that your Dockerfile will always build the same way regardless of which OS you build it on.
I think the point of Docker is that it decouples that "destroy a system and start a new one" from the VPS/cloud/server provider you're using; you can talk about "logical" systems as separate from whatever they're actually running on.
Personally, my use of NixOS means that I don't have the problem, so I don't need Docker. My systems get generated from scratch (logically speaking) whenever I upgrade without having to tear down the VM, and then some simple logic figures out which services to restart.
I've been running Dokku on DigitalOcean lately and it has been great (though I'm planning on eventually moving to Deis, now that DigitalOcean supports CoreOS).
https://github.com/progrium/dokku https://flynn.io http://deis.io
And if they don't, well having a fresh image that is easily rebuildable makes it easier for me to give demos than to spin fresh VMs. Arguably I could have done the same with Vagrant, but really didn't need the overhead of the VM.
But for using it in deployment, no.
TLS_RSA_WITH_RC4_128_SHA
docker.com actually does support TLS1.2, but their blog subdomain doesn't :\
Docker provides one more layer of abstraction and grouping where a machine (or, commonly, a virtual machine) abstracts its resources in order to provide them to thread-like "containers." These containers share their resources with other containers running on a given host.
A docker container, written like a spec into a `Dockerfile`, is a way to package your application as if there was a `run.sh` that would install your OS, any dependencies and your application itself -- and, importantly, run that application after everything is installed. The host can choose to surface to the world any ports on the running container, or keep them private to itself. The container draws from the host's pool of resources so long as your application continues to run inside the "thread" managed by docker.
Docker makes it easy to use features of the Linux kernel that have been around for a while. Expect Microsoft to discover this technique in a couple of years.
The overall idea is that I can make an app, use Docker to control things like versions of 3rd party apps that your app relies on. So for a web app I can include the version of MySQL, PHP, Ruby etc that I want, and then distribute a "dockerized" version of the app. Now when I distribute for testing or to other servers I don't need to worry about versions. It just works.
At least that's what I gather from reading their site last weekend. I plan to start using it for one of our projects soon.
Do you compile everything you install from source on your open hardware? If so, you are by far the minority here. If not, you're inconsistent.
But to get started with docker it's incredibely easy to download an image and have something running within minutes.
> Nonstandard argument format
This has changed
> some strange formatting in the manual page
Also has changed
> And the idea of downloading random software from strangers from the internet and running it on your machine creeps me out as well.
So you don't use any sort of package management with the distro of your choice?
BTW - you don't have to use docker the way you describe. You can `docker import` any rootfs to create a base image and only push/pull images you have created.
I'd encourage you to jump in. The IRC channel is fairly active and there's a ton of places to get started at all experience levels. Let me know if you need help.
See this thread (and previous discussions around the issue) begging for docker core to participate and getting nowhere for ~1 year: https://github.com/docker/docker/issues/7284
Is there an outline somewhere on your plan for governance and stewardship for community contributions, how proposals move through the pipeline, and whether anyone outside of Docker, Inc has the commit bit?
There are project maintainers that are not on the Docker, Inc. payroll, and getting anything committed requires the approval of at least 2. We actually consider this a litmus test for our involvement with the ecosystem, and it's fundamentally a great thing.
As for the issue at hand, I personally understand desire on both sides. I have been frustrated multiple times by the lack of being able to have multiple Dockerfiles per repo as a simple example. On the other, providing strict guarantees about context ensures true portability of Dockerfiles.
What I will say, is that this is a topic we talk about a lot, whether it be on the issues themselves or in IRC. It's tough to get the right balance.
This has been the case on other issues I have seen as well, either things languish, or they get magically swept into the project, with the decision happening elsewhere.
Stewardship would mean actually explaining the position above, and discussing with the community how the issue affects them in order to gain an understanding of what we are talking about.
Yelling "repeatability" with no context and then disappearing is pretty frustrating.
I know for a fact that you are aware of this since my comment was in direct response to you.
And since comments are still rolling in (even though there is already an open call for contribution, with a pre-approved design), I am focusing on it again this week [3].
There are definitely lots of growing pains in how we run the project, and having any participation at all from you is super appreciated. But the picture you pain here is unfair and inaccurate.
[1] https://github.com/docker/docker/issues/2112#issuecomment-39...
[2] https://github.com/docker/docker/issues/2112#issuecomment-47...
[3] https://github.com/docker/docker/issues/7284#issuecomment-55...
Free money from some dudes unrelated to the company's business really shouldn't indicate "stability", should it?
Well, in this way it is hot indeed.
I imagine they'll try to grow in that direction because their customers will hanker for it, but (and I'm biased here because I work for a PaaS developer) they'll find that building automagical distributed platforms is hard. Very hard.
Edit: from the blog post -- it looks like moving up into PaaS is their intention.
Today is a great day for the Docker team and the whole Docker ecosystem.
We are pleased to announce that Docker has closed a $40M Series C funding round led by Sequoia Capital. In addition to giving us significant financial resources, Docker now has the insights and support of a board that includes Benchmark, Greylock, Sequoia, Trinity, and Jerry Yang.
This puts us in a great position to invest aggressively in the future of distributed applications. We’ll be able to significantly expand and build the Docker platform and our ecosystem of developers, contributors, and partners, while developing a broader set of solutions for enterprise users. We are also very fortunate that we’ll be gaining the counsel of Bill Coughran, who was the SVP of Engineering at Google for eight years prior to joining Sequoia, and who helped spearhead the extensive adoption of container-based technologies in Google’s infrastructure.
While the size, composition, and valuation of the round are great, they are really a lagging indicator of the amazing work done by the Docker team and community. They demonstrate the amazing impact our open source project is having. Our user community has grown exponentially into the millions and we have a constantly expanding network of contributors, partners, and adopters. Search on GitHub, and you’ll now find over 13,000 projects with “Docker” in the title.
Docker’s 600 open source contributors can be proud that the Docker platform’s imprint has been so profound, so quickly. Before Docker, containers were viewed as an infrastructure-centric technology that was difficult to implement and remained largely in the purview of web-scale companies. Today, the Docker community has built that low-level technology into the basis of a whole new way to build, ship, and run applications.
Looking forward over the next 18 months, we’ll see another Docker-led transformation, this one aimed at the heart of application architecture. This transformation will be a shift from slow-to-evolve, monolithic applications to dynamic, distributed ones.
SHIFT IN APPLICATIONS
As we see it, apps will increasingly be composed of multiple Dockerized components, capable of being deployed as a logical, Docker unit across any combination of servers, clusters, or data-centers.
DISTRIBUTED, DOCKERIZED APPS
We’ve already seen large-scale web companies (such as GILT, eBay, Spotify, Yandex, and Baidu) weaving this new flexibility into the fabric of their application teams. At Gilt, for example, Docker functions as a tool of organizational empowerment, allowing small teams to own discrete services which they use to create innovations they can build into production over 100 times a day. Similar initiatives are also underway in more traditional enterprise environments, including many of the largest financial institutions and government agencies.
This movement towards distributed applications is evident when we look at the activity within Docker Hub Registry, where developers can actively share and collaborate on Dockerized components. In the three months since its launch, the registry has grown beyond 35,000 Dockerized applications, forming the basis for rapid and flexible composition of distributed applications leveraging a large library of stable, pre-built base images.
Future of Distributed Apps: 5 Easy Steps
The past 18 months have been largely about creating an interoperable, consistent format around containers, and building an ecosystem of users, tools, platforms, and applications to support that format. Over the next year, you’ll see that effort continue, as we put the proceeds of this round to use in driving advances in multiple areas to fully support multi-Docker container applications. (Look for significant advances in orchestration, clustering, scheduling, storage, and networking.) You’ll also see continued advances in the overall Docker platform–both Docker Hub and Docker Engine.
The work and feedback we’ve gotten from our customers as they evolve through these Docker-led transformations has profoundly influenced how Docker itself has evolved. We are deeply grateful for those contributions.
The journey we’ve undertaken with our community over the past 18 months has been humbling and thrilling. We are excited and energized for what’s coming next.
Now to yield a nice return on that they just have to turn docker into a ephemeral social photo sharing app for blind vegan Bulldogs and say they want to change the world ;)
I think containers as a concept have the chance to really fundamentally change the way applications are developed, delivered, and managed in data centers going forward - whether it's my own little rack sitting in a corner office, or a large scale, multi dc deployment.
We're betting on that being Docker, but, the worst thing that could happen is to become complacent and not recognize there's a tremendous amount of work left to do.
Not to take anything away from docker being a decent tool in some circumstances - but really this methodology has been around in one implementation for ages on Unix platforms.
What would be a good comparison for a component company like this getting to 100s of millions or $1b?
No, its not the first time any technologies with _some_ these types of capabilities have been available, but it is the first time this powerful combination of those capabilities have come together in a way that has so much momentum.
I would ask - why is it now that it's actually being used outside of the few boutique scenarios that came before?
I personally think it's a change at various levels of the industry (from the speed of ideation->delivery, inefficiency in process, dc consolidation, efficiency/density) and Docker is an integral piece in helping alleviate those problems