On this blog, we talk quite a bit about Docker. We have our opinions about what Docker is and when to use it or what the top 10 Docker tools are.

But today, we had the opportunity to learn about Docker from the Chief Executive Officer of Docker, Ben Golub. Since Ben is the CEO, I tried to keep the questions around the business of Docker. I plan to interview Solomon Hykes (the CTO of Docker) soon and we will get into the more technical aspects of Docker.

Background

Ben Golub, Docker CEO

Ben Golub has been CEO of Docker since April of 2013. Prior to Docker, Golub was CEO of Gluster, the open source, scale-out storage company, which was successfully acquired by Red Hat in 2011.

Before joining Gluster, Golub was CEO of social media pioneer Plaxo, which was acquired by Comcast in 2008. Golub also spent eight years at VeriSign, Inc., serving as Chief Marketing Officer, as Senior Vice President of the security and payments business, and as General Manager of VeriSign's managed security services business.

Watch the Interview

Listen to the Podcast

You can subscribe to this podcast on:

Show Notes

Tell us about your background

This is my 5th startup and 3rd as CEO. I grew up in Cupertino growing apricots near Apple Headquarters. I worked for Sun and Verisign. I was CEO of Plaxo and then CEO of Gluster (open-source storage acquired by RedHat). I started talking to Solomon Hykes about Docker when it was changing from DotCloud and started to see how Docker could break developers free from the pain they had to deal with on a daily basis. Simultaneously, it freed the sysadmins from all the chaos to help them build scalable stable solutions.

Tell us about Docker and who should use it? Developers? Ops? Both?

Developers should be building containers and ops guys should be deploying containers and managing Docker.

You were the CEO of Gluster, that's cool! Distributed filesystem is one of the biggest asks of the Docker community. Is something happening there soon?

Actually, Gluster just announced official Gluster containers for Docker! The job of Docker is to create the right hooks for the community to build on.

How is Docker different than Linux Containers?

Before Docker, Linux Containers were:

  • used mainly by people like Google for specialized tools
  • weren't portable or interoperable between different environments
  • wasn't an ecosystem
  • used mainly by sysadmins, not developers

Docker adds on top of Linux Container:

  • interoperability and portability so they can run anywhere with any Linux distribution that has a modern kernel
  • standard APIs (hooks and holes in the same places for the "shipping container" analogy)

The Docker project is very grateful to the work of Linux Containers for paving the way for Docker.

@mattapperson on Twitter asked: What docker based host OS will go the distance? (CoreOS for example) What is the best way to run Docker?

Twitter screenshot

We worked really hard to make sure Docker runs great on every Linux operating system with a modern kernel. We also have worked hard to make it easy to run a Docker compatible Linux distribution on Mac OS X and Windows. Boot2Docker has a minimal OS and CoreOS also has a minimal OS. The right question is not which host OS works best for Docker, it is a question of which works best in your environment. There is some people who want to use Docker in a really radical way on a minimal OS like CoreOS and Atomic. There are other people who want the full stack so they use something like RHEL or Ubuntu.

Are Linux Containers going to replace Virtual Machines?

There are a lot of use-cases that people use for VMs where VMs really aren't well suited. Also a lot of places where VMs make sense and Linux Containers don't make sense.

Why would someone pick a VM over a Linux Container?

If you are trying to mix different OS families (Linux, Windows, etc), you are going to need a VM. If what you really need to do is build flexible infrastructure, then a VM makes sense.

Why would someone pick a Linux Container over a VM?

If you are tying to create and burst applications quickly or if you want to build applications from many loosely coupled components, that's where Docker really shines. In the VM model, the application becomes indistinguishable from the server. The application code and the system code become tightly coupled and intertwined. In a Docker world, the application and system code are decoupled. You don't have to worry in advanced what the underlying system is going to be. For example, the underlying host might be RedHat Enterprise Linux, but the developer could use Ubuntu in his containers.

Is Docker forever tied to Linux Containers or could it manage Virtual Machines in the future too?

You can already put Linux Containers inside of VMs and VMs inside of Linux containers. Docker right now supports a whole bunch of kinds of Linux Containers. We have also built primitives in place to extend it to Solaris Zones or BSD Jails. The natural next step is to use something like Docker to manage things that look like containers inside of a Windows environment, which we are exploring but won't be available this year.

Do you see bigger players getting into pure Docker hosting like Tutum and Orchard?

Yes, absolutely. Many providers are working to various degrees on this like Rackspace, Amazon, Google, Azure and CenturyLink Cloud.

What use-cases make most sense for Docker? How are enterprises and large companies adopting Docker?

The first thing to do is try the [15 minute tutorial].

If I can do it and my CFO can do it, anyone can do it. Most people don't realize that if you use an Android phone, you are already using Linux Containers. Applications like Angry Birds aren't just a bit of code or a VM, they are actually distributed as a Linux Container and you know that it is isolated so that it doesn't mess up your address book.

Use Case #1: Developers

Most organizations start by incorporating Docker by encouraging developers to create containers for stateless modern apps (example: API-driven Node apps).

Use Case #2: Ops

After they containerize their apps, they then try to figure out how to deploy them in a multi-server complex environment.

Best Case Scenario

Using CI/CD (through Drone, Shippable, or even Jenkins) with Docker to make the transition from use case #1 to use case #2 as smooth and automated as possible. Gilt and Ebay deployments went from weeks to minutes using this method. There are over 50 example uses cases listed on the Docker website.

What are the biggest problems in real-life Docker adoption today for organizations?

We just released 1.0 and Docker, Inc. is only 42 people and the project is only 15 months old, so it is still very young. Docker is not a VM and won't replace VMs. If you have an app that you really need VM functionality, don't adopt Docker. You need to use Docker to re-think your assumptions when building applications. The old way of thinking is that application = servers and servers = hard to build and spin up. With Docker, you can spin up containers in milliseconds, destroy them in milliseconds. You can migrate them easily, so a lot of the pain and complication to manage apps as if they were servers goes away.

How will Docker, Inc. make money?

We want to encourage people to build above and below Docker. Some of those things will compete with what Docker, Inc. does and some won't. That's ok because we want the best tools to win. A few things we won't do:

  • Won't dis-advantage a competitor by messing with the open-source or API
  • No hidden roadmaps, all Docker engine work is done in the open, governance is in the open
  • No commercialized Docker engine that is better than the open-source version

Here is a few things we have planned to do to make money:

  • Launched Docker Hub with content, collaboration, workflow tools
  • Launched Commercial Support
  • Working on On-Prem Docker Hub
  • Tools for Management and Orchestration of Containers

We are committed to building the company around open and transparent ideals.

How will adding transparency and collaboration to the ops process change the industry?

Our mission is to build tools of mass innovation. Docker is the gateway technology to making 12-factor application building a reality. We shouldn't have to care what kind of server our apps run on and bring consistency in what you deploy to production. We want to enable new kinds of collaboration. Docker Hub is the GitHub for DevOps people. It builds a bridge between the developer and the ops communities, which have traditionally been often at odds with each other. Docker is the soap that let's oil and water mix.

How many people are on Docker Hub?

Multiple thousands of new developers and ops people sign up every day. Over 16,000 containers have been published on Docker Hub already. Docker meet-ups in 100 cities across 35 countries on every continent except Antarctica.

What’s next for Docker?

libcontainer, libchan, and libswarm are really important enhancements to Docker for linking containers together. On Docker Hub we are adding more collaboration tools and making it easier to hook in tools like Jenkins, Bamboo, Chef, Puppet or Salt. You will start seeing more and more use cases from large enterprises and banks using Docker more openly.

Full Transcript

Lucas Carlson: Hello. This is Lucas Carlson from CenturyLink and CenturyLink Labs. I'm super excited, because today we get to talk with Ben Golub, CEO of Docker, about how he came to Docker, what Docker is doing, how it's changing the world.

This is an awesome treat to hear about somebody really leading the way with the technology that, I think, is going to be one of the basic technologies we all use in our command line experience every day within the next few years.

Ben, thank you so much for coming. Thank you. Tell us about your background, about yourself, and how did you get to Docker.

Ben Golub: First of all, thank you, Lucas, for inviting me. As I always tell anybody who wants to give props for what's happening with Docker, the real props go to the community.

My background, this is my fifth start-up, the third as CEO. So, I've been around the block a bit. I grew up in Cupertino. My first Silicon Valley job was cutting apricots.

They paved over the orchard. They built Apple headquarters there. In between, worked for Sun, tried to start a business school in Tashkent, my first failed startup. And worked at Verisign for eight years trying to build up the foundations for Internet commerce, was CEO of Plaxo. Immediately prior to this, was CEO of Gluster which was open source storage, eventually, became part of Red Hat.

I've seen a lot of the good and I've seen a lot of the bad. As you may know, the company that is now Docker was originally known as dotCloud. It was a platform as a service company. They were started in 2011.

I went to speak to Solomon in February of last year, when he had in his mind the notion of taking the fundamental container technology that was used at dotCloud, open sourcing it, and trying to create a company around it.

The more I spoke to him, the more I understood his vision. I really saw what this could be in terms of breaking developers free from a lot of the really horrible things that they have to deal with on a daily basis and allowing them to just build great applications, and similarly, freeing the sysadmins from all of the chaos allowing them to build scalable, stable solutions.

It just seemed like a natural. As you said, it has the potential to change the world, in development at least. So far, that seems to be happening. So I'm really pleased.

Lucas: That's awesome you came from Gluster. Gluster is also a great technology. It's fascinating, because I think one of the concerns that I've heard most from the Docker community is, "How is the file system stuff going to work with Docker?" I'm not saying that Gluster is going to be the solutions, but it's great that the CEO of Docker used to be the CEO of a file system company. Is there anything there?

Ben: Well, yeah. First, the guys at Gluster just released a really interesting integration with Gluster and Docker. That was Fred Kautz and Harshavardhana who did that. I think, more generally, what we're recognizing is that having built Docker, we now need to put in place the primitives that enable people to do the things they want to do with storage, the things they want to do with networking, the things they want to do with security.

Our general philosophy at Docker is, our job is to build the right primitives into Docker, or to use the analogy of a shipping container, put the hooks and holes in the right places, and then let people build what it is that they want to build.

We don't want to be in the business of saying, you should run Docker on any particular operating system, or run it on a VM versus not on a VM. We don't want to be in the business of telling you how to orchestrate Docker containers.

We want to make sure that we build the fundamental technologies in there. So that people can create an ecosystem and business solutions around Docker.

Lucas: That's really cool. Let's back up to people that might not be as familiar with Docker. Who should use Docker? What is it for? Should developers use it, ops people, IT? Who do you think is the right audience for Docker?

Ben: Docker is designed to change the way that people build, ship, and run applications. There's a great deal of benefit for developers using Docker and there's a great deal of benefit for ops type in using Docker.

A lot of the benefit, actually, comes from the fact that we draw nice, clean separation between dev and ops. Devs, if you will, can be really, flexible and creative inside the container. And yet, the outside of the container always stays the same, which enables ops guys to build stable, secure, automatable stems.

A very fundamental level of Docker lets you take any application and its dependencies, package them in a lightweight container that will run virtually anywhere. Today, that means, you can take any Linux application, or components of a Linux application, containerize them, and then run them in that same container on pretty much any Linux server.

It doesn't matter whether it's Red Hat or Ubuntu, whether it's physical or virtual, whether it's at Amazon or Rackspace or SoftLayer or Google and, in fact, move back and forth between them.

Lucas: That's really cool. It's for the developers to work in the container, and it's for the ops guys to manage the Docker system itself. Is that right?

Ben: That's right. Now, of course, some developers also act like ops folks and vice versa. The set of issues that people worry about in terms of application creation in management get really neatly separated on the inside of the container, if you will. The outside of the container hooks into whatever infrastructure management people decide is best for them.

What we like to say is that, as opposed to the VM model which says an application is really indistinguishable from the application server. They are tightly bound, in the Docker world, they're separated.

Applications can be whatever they want to be and not have to worry, in advance, about what the infrastructure is going to be. People who are building infrastructure, can build the infrastructure that they want.

If that's a set of commodity servers that are all running Red Hat, that's great. If it's an open stack, that's great. If it's VMware, VMs, that's great. If it's outsourcing the whole thing to Amazon, that's great too.

Lucas: How is Docker different than Linux containers? Linux containers have been around for quite a while. What does Docker bring to the world that Linux containers didn't have?

Ben: There is core technology that we built on top of. We have to give a lot of credit to the people, who built the underlying technology. Before Docker, Linux containers were the providence of people like Google, who had specialized tools and training.

They weren't portable between different environments. There wasn't an ecosystem around them. For the most part, they were a tool that was used by sysadmins, in very specialized organizations. They weren't useful for developers.

We like to draw the analogy between Docker and shipping containers a lot. What I like to say is that, the basic technology was like steel boxes. What we have done is, make them all the same size and put hooks and holes in all the same places.

Lucas: Fascinating. I know, you said you wouldn't do this. We got a question from one of the people in Twitter. Matt Apperson asked, "What Docker based host OS will go the distance." He was mentioning, is it going to be CoreOS? Is it going to be Red Hat? What do you guys think is the best way to run Docker?

Ben: I think, the best way to run Docker is on a Linux server with a sufficiently modern kernel. We worked really hard to work well with Red Hat, so we're shipping with RHEL. We've worked really hard to work with Canonical, so we're shipping in Ubuntu.

We work on VMs. We have something called Boot-To-Docker, which is a great solution if you want a very minimal OS. CoreOS is another really minimal OS. I think, the question is not which of these will work best for Docker, but which works best in your environment.

There are some people, who want to use Docker in a really radical way on minimal OS. They're looking at things like, CoreOS or Atomic. Then, there are people that want a full stack, in which case they're looking at RHEL or Ubuntu or something like that.

Lucas: That makes a lot of sense. Are Linux containers going to replace virtual machines? We've been hearing in the news a lot about this. I'm curious what you have to say about that.

Ben: What I believe is that, there are a lot of use cases that people put VMs to where VMs really weren't suited. I think you are going to see a lot of use cases where people are using Linux containers instead of VMs.

There are a lot of use cases where VMs make sense and Linux containers don't make sense. There are a lot of use cases where the right answer is to run a bunch of containers inside of VM. Instead of having a thousand VMs, because you have a thousand applications, you have 10 VMs, which are each running 100 containers.

Lucas: Can you give us a general sense of why somebody would pick a VM over a Linux container? What value does the VM bring?

Ben: Yeah. Certainly, if you are trying to mix different OS families, you want to run a Windows app on a Linux box or vice versa, you're going to need a VM.

Similarly, if what people are really trying to do is build flexible infrastructure and they really want to move and allocate servers or virtual servers to people, then VM makes sense. But if you are trying to create applications, modify them quickly, burst them across the platform sub servers or burst them to the cloud or if you are trying to build an application from lots of lucid cup of components and you want to containerize each of them. That's where Docker really shines.

Lucas: So, the general idea here would be that a more consumer-facing thing might be, like a virtual desktop could be for virtual machines, but more server side stuff might be better suited to containers. Is that a general guideline?

Ben: Well, again, if you want to combine, you want to run things in one operating system family on a machine that has a different host operating system, then, you need a VM. But if you are trying to build a system for creating, packaging and moving applications around and linking the components of an application together, you don't need a full VM. You don't need to treat and you shouldn't treat that application or that component as it were part of a whole server. And that's really where you want to use Linux Containers.

It's interesting, because I think, once you probably realize that your Android phone, you've got a bunch of Linux containers. When you download Angry Bird, you are not downloading a VM. You are downloading something in a Linux Container and you know, it is isolated, so it doesn't mess up your address book. We do the same thing. We do it far more complicated, far more in-depth issue of running in the background on servers.

Lucas: That's fascinating. I think, that really helps people think about it. So, do you think that the world is going to go back to bare metal hosting and do Linux Containers on bare metal rather than virtual machines -- we're cloud 1.0. Do you see us going back to dedicated hardware and adding Linux containers to them? Is that the next generation of cloud in your opinion?

Ben: What I'll say is, Linux containers are far more flexible, they are much easier to spin up, they are much easier to destroy, and you can get significantly better performance density out of them. So, I certainly think, you are going to see a lot of usage of Docker on bare metal in the hosting environment.

On the other hand, Docker and Linux containers in general, don't yet have a lot of the features that people have come to expect from VMs just because VMs have been around a lot longer. So I don't want to say that Cloud 1.0 is VM, Cloud 2 is Docker or Containers, but I will say that Cloud 2 will have a very healthy mix of Docker and VMs.

Lucas: Radical. So that raises another question, because especially, in large enterprise a lot of development is still done on Windows machines, and right now, Docker is highly tied to Linux. Is Docker going to always be tied to Linux or could it potentially manage even virtual machines, regardless of Windows or whatever virtual machine you have.

Ben: Yeah, also I was saying, today you can put VMs inside of Docker and you can put Docker inside of VMs. So, let's say what you are talking about you can already do. You can also run Docker host on a Windows machine using Boot2Docker. We have got some other way there. I think, what you all see is that Docker, right now, supports a whole bunch of different flavors of Linux Containers.

We have also built the primitives in place so that we can extend that to things like Solaris Jones or BST JX which are more associated with Unix. And, of course, the natural place to go from there is to use something like Docker, to manage things that look like Containers inside of a Windows environment. That's certainly something we are exploring. We are talking to a lot of folks about doing it, but it won't be this year.

Lucas: Got it. So, eventually, we will be able to run Windows apps within Docker, but it's not going to happen in the short term.

Ben: That's right, and I think, more importantly, you will be able to create those apps using Docker to containerize all the components. And then, run them anywhere, at least, on any Windows machine.

Lucas: Right. So it will still be running Linux applications, but it's all on Windows machine.

Ben: Well, Docker relies on the Linux kernel. So, we need a Linux kernel somewhere. So, right now, you can create Linux apps and run them on a really light-weight Docker VM on a Windows box. Where we want to get in the near future is, where you can be really flexible in terms of creating Windows apps and run them on the Windows box.

Lucas: Yeah, so, we've seen some of these new hosting providers, like Tutum, come out with Pure Docker host. We have only seen that in start-ups, but big cloud offerings like Amazon leaving central in cloud could go into the space as well and do you see that as part of the future too?

Ben: Absolutely. We are really excited. At Docker Con, which was two weeks ago, we were joined by large numbers of people, who are creating Dockers as service offerings that includes people, who are Docker from the ground up like Tutum or Orchard as well as larger providers like, Rackspace, Google and Amazon, and Azure who have announced Docker support. And CenturyLink, we are really excited to be working with as well.

Lucas: Great. So, what use cases make more sense for Docker? People that haven't yet used it, how are enterprises and large companies that you have been interacting with, adopting Docker? Where is the lowest hanging fruit? Where would it make sense to if you hadn't done something? Is there a kind of project? Did you try Docker with that?

Ben: Yeah. I always recommend anybody who wants to get started with Docker should go to our site and do a 15 minute tutorial that we have online. It takes 15 minutes to get through and when I made it through successfully and our CFO made it through successfully, we know that we had something that was easy to use.

But, I think, what you start to see is that most of us tend to start on one end of the software development life cycle. So starting with the developer, I am saying, how can I make the developer's life easy and make this path that goes from developer through test, QA stage into production work well.

Once they have gotten that use case one down, then they start looking at, "Hey, how can I use Docker to scale in production, whether that's across clusters or between clouds, et cetera." I think most people start with use case number one and they generally, start with stateless apps just because that's the easiest. What I think they often find is that using Docker is much faster to develop apps.

I think, they also find that you can create a system, where you can go from dev to test to staging to production in minutes rather than in weeks, and have something that, goes smoothly rather than having things break at every step along the way, and have people pointing fingers at every step along the way.

That's what we hear from people like Guilt and eBay and others who use Docker say. It went from weeks to minutes, nobody points fingers and basically developer pushes a button, the container gets built automatically, gets picked up by the automated testing system and 90 percent of the time it passes and it goes directly into production.

The 10 percent of the time when it doesn't work, it's really clear whether the issue is inside the container and development needs to fix something or it is outside container and ops needs to fix something.

Lucas: Yeah. I think that one of the really cool projects out there is around the CICD pipeline stuff. I know Drone is doing a pure Docker stuff. I also know that some of the big guys, Jenkins, are working on incorporating more Docker into some of the more traditional tooling for CICD.

That really makes sense. For people that need a first application to try to Dockerize, would APIs or something around a modern API app, maybe a node app, make sense for Docker?

Ben: Yeah. I think that'd be a good, easy place to go. Again, what I will say is, if you go to the Docker website, there are 50 different use cases that are published.

Then to your point about things like Jenkins, one of the great things about Docker being so radically open and embracing the whole open source community ethos is that, we've got first-class integrations with Chef, Puppet, Salt, Ansible, Jenkins, Travis. And if you go on GitHub and you search for Docker projects, there are over 7,000 that have been done.

There's a huge ecosystem of tooling and projects around Docker. If you go to Docker's hub, you'll also see that there are some 16,000 applications that have already been Dockerized that the community has published.

There are lots of good use cases to look at, lots of good base components to get started with, and lots of great tools that allow you to build what you want with Docker as a LEGO kit.

Lucas: That's really cool. If that's the best place for adopting Docker, what's the worst place? What are some of the biggest challenges and problems in adopting Docker into real life use cases right now? Where is it weakest?

Ben: Sure. We just released 1.0. I always want to make sure people understand that, this is a 15-month-old project, and Docker Inc is 42 people and a pet turtle. Keeping that in mind, that can't even afford good headsets.

Lucas: [laughs]

Ben: I think that, certainly, Docker is not a VM. If what you want is a VM and you really understand what you want is a VM versus Docker, then, you shouldn't use Docker.

Certainly, if you're trying to mix operating systems, if you've got an app where you really need to be able to freeze state and live migrate, we just don't have that functionality built in yet, but things are coming.

On the other hand, what I encourage people to do is use Docker and containers in general as an opportunity to rethink a lot of their long-held assumptions. Because, I think, a lot of the tooling and the methodology we've built around ourselves assumes that application equals application server and that VMs are hard to build, take a long time to spin up, et cetera, and are expensive.

In the case of a container right there, you can create them in milliseconds, you can destroy them in milliseconds, and you can migrate them easily, and so results a lot of the pain and complications that we've put into things to manage all of our apps, as if they were servers. You can rethink it and drill out.

Lucas: Got it. That makes a lot of sense. In a few weeks I'll be interviewing Solomon on this podcast. For him, I'm going to be going a lot more into the technical weeds and asking him a lot of those kind of questions, but for you, I'm particularly curious.

As CEO, how will Docker make money? Because I think a lot of the ecosystem around Docker, right now, does have a concern. Are we just building something that the Docker guys are going to eat our lunch?

[indecipherable 0:23:00] , originally, had some private hosted Docker repositories, and now with the Docker hub, now Docker has that as well. How is Docker planning to make money?

Ben: Good question. We've tried to be pretty transparent in terms of how we're planning to make money. We're also trying very hard to be good stewards.

We know that we've got an open platform. There are going to be people who build on top and below us in that platform. Some of those things will compete with what Docker Inc does and some won't, and that's OK, because we want the best tools to win.

A few things that I'll say that we won't do. We will never disadvantage any competitor by messing around with open source and messing with the API. We drive nice clean APIs that we use and everybody else uses.

We don't have any hidden roadmaps. All the work that's done on Docker engine is done out in the open. The governance is out in the open.

We've committed to not doing open core, so we're not going to create some commercial version of Docker that's better than the open source, or commercial version of Docker engine that's better than the open source engine.

With that having said, what do we plan to do? We've launched Docker Hub. We've launched commercial support, so we're offering commercial support for Docker.

Docker Hub, today, has a lot of tools around content and collaboration and workflow for that CICD use case. Right now, it's delivered purely as a service.

We've also got lots of people who have expressed an interest in being able to bring Docker Hub on-premise or to extend its functionality to more production type use cases, management, marketing and orchestration of containers.

Those are the directions that, we're going in to make money. Again, what we think is that, we've drawn a nice clean line between Docker and what's open source and are committed to maintaining that as a platform that will allow a lot of different tools to develop and some will compete with us, some won't.

Again we think that the best tools will win.

Lucas: This is really fascinating. Seeing companies grow up in an open source way, rather than you look at older companies like VMware that have built up great companies building great software that have been adopted by every Fortune 1,000 out there.

It's fascinating to see different approaches and this open source stuff is a really interesting way to embrace a community, but also build a business.

You launched Docker Hub, and that's an amazing thing. It's really cool to see this, because, for me, I've had a foot in system administration for a large part of my career. I've been doing the DevOps thing for a very long time. I've run large clustered systems, I've written the code for large clustered systems.

It's fascinating to see things like GitHub come out and make coding collaborative. We've had version control for many decades and those version controlling tools were things, that we could use maybe internally and [indecipherable 0:26:49] within our own team, but now GitHub blasts that out of the sky.

Anyone in the world can collaborate with you, and it makes it terrifically easy to work together, collaborate on open source software, on systems, on code, with people you might never have met.

I think the things like the success of Bitcoin have come out of this. Whether Bitcoin could have survived as an open source project before the open collaborative stuff like GitHub existed is, I think a big question.

One of the things that I think is, so cool about the Docker Hub is that it does for the DevOps community, for the system administrator community, a similar thing to what GitHub did for developers.

Is that what you intended? Is this what you meant to do?

Ben: Yes. What we wanted to enable is a lot of different kinds of collaboration.

We've gone from a world where apps were long-lived, proprietary, monolithic, and deployed to a single server, to a world where development is iterative and constant. It's built from lots of loosely coupled components, tends to be open and tends to be deployed across huge numbers of servers.

We want to create the collaboration tools for that environment, which means making it really easy for developers to collaborate with each other, really easy for them, to collaborate with sysadmins and DevOps types, and really provide the tools that makes DevOps not a fantasy, but a reality.

You were thinking about the cultural and business implications of open source, and I think that, Docker brings along some other really important cultural and business implications.

One of them is recognizing that instead of concerns that developers have...developers tend to like to experiment, try new things, break things and ops tends to like to have things be automated, consistent, secure, performant, all of those good things.

They're both right, but getting them to agree on a set of tools and a set of methodologies is really difficult, because what one person does endangers the job of the other person.

With Docker and with Docker Hub in particular, we get the best of both worlds, in that you can be really creative and share and reuse components as a developer, and yet as a sysadmin there's a nice clean boundary between it. You can automate the whole testing process and you can have a lot more consistency in how you deploy to production.

For me, it's all really exciting, as exciting on a community and a business standpoint as it is on a technical standpoint.

Lucas: Yeah. That makes a ton of sense. It really has the potential to transform an industry.

How do you actually see Docker transforming the industry? What do you think it's going to do to the way people think about creating applications? Is this the gateway technology to making 12-factor application building a reality?

Ben: Yeah. I hope so. I hope that it's the gateway towards a new era of development, where people really can develop anywhere and can be unleashed to develop amazing things without being shackled by concerns of knowing in advance, how things are going to run, where they're going to run.

Our mission, as a company is to build tools of mass innovation, which sounds a little corny, but we really do think, it can be that significant. Stupid historical analogy, but why was the printing press so cool? It's because, it meant that the active creating content and creating new ideas, wasn't bound to your ability to produce books.

Why was the Internet so cool? Because to get to the nth level, and then, you didn't have to worry about the cost of producing books, and you can collaborate in creating things.

Why else was the Internet cool? Because you could send a message from one place to other. You don't have to worry about how it was getting from point A to point B.

We think we can achieve all those things with the application world as well, right? Make it easy to create application without worrying about how they're going to run, make it easy to collaborate in the creation of applications. Also as Solomon says, "Make running an application on the Internet, as easy as sending a message across the Internet."

You send a message across the Internet, we don't care which routers are between point A and point B. [indecipherable 0:32:01] we shouldn't care, which servers are an application are going to run on. I just accept in term of highly secure types of scenarios.

Lucas: It could really build the bridge between developers and ops teams. It could combine those oil and water that they've been always [indecipherable 0:32:25] .

Ben: We're the soap, that less oil and water.

Lucas: [laughs] That's really cool. What's next for Docker? What's on the horizon? 1.0 just came out. DockerCon was a huge success, lots of interest. Do you guys share how many people are on Docker Hub? Is that one of your public statistics?

Ben: It isn't yet. We need to figure out what the good measurement is of it. We've had multiple thousands of people signing up per day, which is really exciting.

Lucas: That's great.

Ben: Docker, itself, we talked about, it has been downloaded, 3 million times, 16,000 applications published to the Docker index, 7,000 projects on GitHub. My favorite step though is that, we now have Docker Meetups in 100 cities across 35 countries in every continent except for Antarctica. If you know somebody in Antarctica...

Lucas: You better take in Antarctica. One of our viewers is up there. Let's do this.

Ben: We want to do it. We want to get all seven.

Lucas: What's next? What's on the horizon? What's past, what we can see right now?

Ben: Docker 1.0 was a huge milestone, but the Docker engine side, there's clearly a lot more that we need to do. Solomon spoke about some of the things that we're trying to do around libcontainer, libgen, and libswarm, which are all really important enhancements to Docker.

In general, we'll be able to get much better in orchestrating containers in a consistent way, looking at containers together, and dealing with things like storage and networking.

On the hub side, it also just released the DockerCon. We've got a huge list of improvements that we want to make, adding more collaboration tools, making it even easier to hook in tools like Jenkins or Bamboo or Chef or Puppet or Salt.

What you're also going to see from Docker over the next several months now, that we've announced commercial support is more and more use cases that people in places like financial institutions or Fortune 500 toward using Docker.

Talking about it publicly, we've had huge numbers of web companies like Guilt and Groupon and eBay and Spotify talking about their use of Docker. I think that the more conservative organizations are waiting to hear from their own, before they jump in. A lot of them are now starting to jump in.

Lucas: That's very cool. It has been a real pleasure to have you on. It's really great to pick your brain and understand where things are going and how the industry is changing. I really look forward to continuing the dialogue. I can't wait to see more. Solomon mentioned some stuff around security. Is that also in the future?

Ben: Absolutely. I think, we've also talked a little bit about this. If the future is lots of applications that are changing constantly built out of components themselves, containerized, and moved everywhere, obviously, security becomes a concern.

We think that the right thing to do is just to start by building that in, at the container level, which means things like container signing, understanding where containers came from, who created them, when they were created, and what are some of the fundamental capabilities that containers are asking for.

It's really easy to build security around containers if you know where they came from, who created them, setting policies around whether you're going to allow container rude access or not, et cetera. That's it.

I've got other thing on our long list, but DockerCon just finished. We're giving ourselves the weekend off, and then we're going to get going.

Lucas: Great. I am very, very happy. Thank you for your time. It's been great talking with you.

Ben. Thank you, Lucas.