This week we spoke to a leading member of the Docker community, James Turnbull. James is the VP of Services & Support at Docker and also the author of The Docker Book. He's the authoritative brain-to-pick when it comes to all things Docker.
James describes himself as being “in IT far too long, about 20 years". He has a broad experience across platforms; having started on the mainframes, he's seen the whole evolution. He's been a systems programmer, system administrator, security guy, and an operator way back when ops meant getting in to the office in the morning and distributing the overnight printouts from the mainframe to each department.
James Turnbull VP of Engineering at Kickstarter
James Turnbull is an Australian free software and open source author, security specialist, and software developer. He lives in Brooklyn, New York where he is VP of Engineering at Kickstarter and an advisor at Docker Inc.
Watch the Interview
Listen to the Podcast
You can subscribe to this podcast on:
What books have you written?
In addition to haven just written The Docker Book, James also has written many more books including Pro Puppet, Hardening Linux, Pro Linux System Administration, Pro Nagios and The Logstash Book
What is the history of containers?
Containers and like technology have been around in one form or another for ages; from old-school IBM VM technology -- perhaps better known now as z/VM -- to Solaris Zones. Linux has had a surprisingly long history with containers, largely through LXC's interface to kernel functionality. What Docker has done here is make containers easy to use and share, providing tools to create images that can be used to quickly realize new, running containers.
Will containers replace virtual machines?
This will probably depend on specific considerations about real-world workloads and the fundamental differences between machines (virtual or not) and containers impact their desirability? What about security and other considerations? There's a lot to consider before we can declare virtual machines dead.
How has Docker changed the concept of DevOps?
Docker has "accelerated the concept of DevOps, not changed it" by making Linux containerization technology easily accessible to the masses as well as providing the tools and infrastructure to shuttle images around. We see some prior art here (term used very loosely), with tools like Vagrant leveraging virtualization technology like VirtualBox to create custom VM instances "on demand".
Is the trend towards minimized container hosts, like CoreOS?
Docker and containers, by their nature, have helped lead to a reexamination of existing architecture. As we break our applications down into smaller and smaller chunks to take advantage of containerization -- "microservices" -- we see a lessening of the importance of the operating system itself. In this way, Docker has been a huge unanticipated benefit for Service Oriented Architecture.
Are we moving towards minimized, single-binary containers?
With static compiling, how about it? What's the thinking and pros vs cons behind single-file containers -- that is, containers who only contain a single file, with all its dependencies statically linked in.
Where should I look first when considering adopting Docker?
Look at your workloads and workflows. You may find looking at the creation of "dev-centric" workflows will take you to a happy place of "dev and ops harmony"! Tools like Puppet tend to encourage "dev vs ops"; while Docker containers and container images tend towards "dev + ops".
What are the biggest challenges to Docker adoption today?
Everything is very dynamic at the moment; orchestration tools, trust, multi-host deployment and service discovery all have a great deal of focus and a ways to go before we catch up with the tools available for traditional VM's. That's not to say Docker won't catch up, just that other companies like VMware have been doing this for years longer than we have :)
Tangent: What good interactions have you had with technical recruiters?
Very, very few. About 1% "have a clue" -- those that do also tend to have a clear definition of the role they're recruiting for. There's a big opportunity to "get it right" in this area right now!
What's it like working at a company with such amazing focus on its product?
Docker is an Open-Source project that has faced more attention and focus in the last 18 months than most do in 18 years. We're busy building out tools and infrastructure (like the Docker Hub), and design in the open by default. Docker the company is quite the "friendly, happy place to work." If anything, one of our largest challenges is "too much work; not enough people to do it" -- one of the better challenges to have, I think.
- The Docker Book and a number of others
- logstash and Kibana vs Splunk
- IBM OS/400 and successors ... and IBM iSeries System Software
- Solaris Containers and WikiPedia
- Service Oriented Architecture and "microservices"
- What Recruiters Do Wrong
- Orchard (recently acquired by Docker)
- Fig (acquired and renamed Docker Compose)
- IBM Cloud
- Cloud Foundry
- Docker Hub