Review: The Docker Book by James Turnbull

It is hard to avoid Docker. Hacker News has been abuzz with it for years, The Register ran an exhaustive feature about it a couple of months ago; indeed it seems to have taken over the DevOps world.

But why do I care? I am a developer, I live in the land of abstractions. The JVM is as low as I go my friends.

The problem is, all developers need to do releases.. And releases have a tendency to go very wrong..


So, I decided to educate myself. What is it about Docker that has got the cool kids on Hacker News all excited?

I took a look at some Youtube videos, tried out the tutorials and read a handful of blog posts and how-tos on Docker. I just couldn’t get my head around it! Finally I took the plunge and spent the last couple of weeks working through James Turnbull’s The Docker Book.

So, am I enlightened? The short answer is – yes, I have enjoyed working my way through the “Docker Book” and I have a much better idea on how to use Docker and the sort of use cases it is designed for.

The book is written in a tutorial format. We start with the basics about Docker and containers and move on to installing Docker on your favoured Linux(1) distribution.

Once we have Docker up and running, we learn about the basics of Docker. How containers can be created from images and how these images can layered. We learn about the Docker repository can be used to download standard images (for example, the image for ubuntu:14.04 can be used to build a base container that runs Ubuntu 14.04 LTS) and how to build containers from the images that we define. The author walks us through setting up and managing some simple containers.

All the Dockerfiles and any scripts and code used in the examples is readily available from the Github repository that the author has setup for the book(2).

I suspect most readers will get the most value out of chapters 6 and 7 of the book. Here the author goes through some examples including:

  • Using Docker to build a test environment
  • Building a continous integration pipeline using Jenkins and Docker
  • Building a web application that is deployed on multiple containers

These examples are quite detailed and well designed. Most of them could be used as a basis for a Docker based application stack “in the real world”.

Chapter 8 explores the eco-system(3) that is being build up around Docker focusing on service discovery with Consul and orchestration with Fig.

The book concludes with chapters on the Docker API and how Docker can be extended.

“The Docker Book” does not go into details on how containers work beyond the introductory chapters. The focus of the book is about learning what you can do with Docker and it succeeds admirably. I deducted half a star from the review simply because the author does not delve much into things like performance implications of using Docker or on how exactly the operating system may allocate resources to applications running in containers. There are plenty of resources online on these topics4.

You can’t go wrong with “The Docker Book” if you are looking for a hand-on introduction to Docker. James Turnbull is a good tutor and the resources accompanying the book are great.

Will Docker solve my release woes? Is it actually ready to be deployed in a corporate setting? Perhaps a topic for another post..

My Rating: 4.5 out of 5


  1. Instructions for use of Docker on Windows and MacOSX are provided but are skeletal. Basically you need to use Boot2Docker
  2. I worked through almost every single example from the Kindle edition and didn’t find a buggy script or typo!
  3. The eco-system is moving fast. Kubernetes from Google is also worth checking out.
  4. The Docker blog is excellent

Review: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim et. al

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business WinThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim
My rating: 4 of 5 stars

The “Phoenix Project..” is a parable about technology, business and an introduction to the hot new buzzword of the day – “DevOps”. We follow Bill as he is promoted to be the head of IT Operations in the fictitious auto parts company “Parts Unlimited”. Bill is in for a rude shock as he leaves his comfortable middle management job behind and is thrust into the world of corporate politics, disastrous projects and a company rapidly falling behind it’s competitors and losing market share and money. The root of the problem appears to be a dysfunctional technology group and a complete breakdown in communication between the business and technology groups within the company.

The issues explored here will be familiar to anyone who has worked within technology in any sort of corporate setting. The challenges Bill faces – unclear requirements, unrealistic expectations and ever tightening budget constraints – are present everywhere. The book focuses on technology operations and we go on a journey with Bill as he tries to institute a change management procedure, keep control of production environments and tries to balance key staff who seem to spend most of their times fighting fires instead of delivering on projects.

The methods and technologies Bill and his team adapt should also be familiar to most IT folks. We have change management procedures (ITIL), Kanban boards, and continuous delivery methods. Gene Kim et. al do an excellent job of explaining how these methods work and go beyond the buzzwords in showing how these can be effectively used. The situation Bill inherits at Parts Unlimited may be extreme but its not too far off the mark.

I strongly recommend the Phoenix Project to anyone who works in technology in any domain. As a developer, I don’t have much insight or indeed interest in how IT operations work and the sort of challenges they face. This book forced me to think more about why we have change management procedures and how operating and maintaining an IT infrastructure is as (and probably more) challenging than building the applications that run on that infrastructure.

I have deducted a star simply because the writing can be clunky in parts and I feel the book would have benefited from more editing. The characters are caricatures of the type of personalities you find in most corporate settings. It can be a bit much at times (like the binder carrying manic depressive CISO), but it didn’t detract from an informative and engaging book

View all my reviews

The WhatsApp acquisition

The water-cooler was abuzz this morning with news of Facebook’s $19 billion acquisition of WhatsApp, a tiny company. With the claimed 400 million users that WhatsApp brings to Facebook, the numbers involve value each user at $40. That is an astonishing amount of money for a service that is monetised through application sales, not via advertisement. There have been a number of articles and blog posts online analysing this deal. This is not one of them..

My colleagues are a quiet and taciturn lot. Office banter is limited to a “Good Morning” and a “See you later..” outside of the lunch hour. For the first time, in my admittedly short stint here, we had a bonafide conversation that was not even tangentially related to trading systems and market data feeds. We got talking about what it means to be a programmer working outside of the startup / silicon valley scene. One of my colleagues remarked that he spent half a decade in further education and a lot longer learning the ropes until he got to the point now where he is comfortable and financially secure. He wondered if that time would have been better spent writing a new chat or social network. Perhaps a new way of optimising the transmission and sharing of ribald jokes, or for improving the sexting workflow.

We carried on in a similar vein for a while when the most introverted of our lot spoke up. He said: “I was just never interested. The thought of building the next Facebook or Twitter just doesn’t excite me. It was never something that was on my radar.”

I spend way too much time on Hacker News. The Silicon Valley culture and eco-system fascinates me, but it does not inspire me. I marvel at the numbers that are thrown around. A few billion here, a few billion there, but I also wonder about the utility of it all. It is now fashionable to talk about how much of a talent drain banking has become. How so many people left promising careers in academia and engineering to cut code and make money on Wall Street and the City. In a few years I can see people talking in similar terms about Silicon Valley. “He was a promising scientist, but he joined Google to help them optimise the placement of adverts on search results.”

I find the earnest tone of discussions on Hacker News and of the job postings for these start ups deeply ironic. They talk about changing the world, wanting rockstars and working on cool new technologies. Yet, the end goal is a big payout via IPO or acquisition having built a better way of sharing food selfies. I think these headline acquisitions are a honey trap for programmers. Somebody, like my colleague, who wouldn’t really even think about working for a startup building a “trivial” app might realise that the App may be a gateway to that long dreamt of retirement on the beach.. You might get a lot more people ready to work for peanuts with the hope of striking it rich one day. Perhaps it is not a colossal waste of money after all..