Skip to main content

Writing a book about Docker in 2022?

I recently joined Greg Lim’s Part time author course. A quick brief on the course itself: It is a cohort based course where Greg walks you through the process of writing, publishing and marketing a non-fiction book on Amazon. What I love about the course is:

  1. Greg’s unassuming teaching style and willingness to go out of the way and help us.
  2. The course is cohort based. That means that I have a greater chance of actually completing it. I can’t begin to count how many video courses are lying unwatched in my graveyard right now!
  3. A discord community where we can bounce off ideas and get quality feedback.

NOTE I’m not affiliated with the course, and I simply have all good things to say about Greg and his course.

I like my courses to be actionable. Especially the cohort based ones. I’m not sure if Greg has considered this. I want to simultaneously write and publish a non-fiction book as I go through the course. I chose to write tech books, as that is what I wanted to write always, for obvious reasons:

  • share my knowledge
  • build credibility, have a business card on steroids
  • $$

But I have no idea about the kindle e-book publishing process. To make things easier, I decided to go with a technology I’m familiar with, Docker and containers, so that I’m not doing too many new things at the same time. Also, this topic is in the Goldilocks zone for me.

  • I’ve been working with with docker and containers for last 7 years now. I just have to rest my rear and write down whatever I know.
  • There have been some improvements since I learned it(rootless containers, other ways of building images). So, I don’t give up the beginner mindset entirely while writing the book.
  • This is a high demand topic. But still there is a chance to sneak my book into the market. One of the insights Greg gave was to go through the 3-star user reviews of existing books and identify what is lacking in them and try to address those concerns. There is a possibility that I might end up selling very few copies. Frankly, I’m not too worried about the sales right now. We will cross the bridge when we come to it. At least, I’ll get familiar with the KDP publishing process.

Now that I’m armed with the clarity of what to do, I decided to do an idea dump. Here’s a typical ToC for a book about containers:

  1. What problem does docker solve
  2. History. I believe a history lesson or two is important in technical books. This helps readers appreciate why things are designed the way they are.
  3. Installation
  4. Baby steps
  5. How containers work under the hood. Some folks aren’t curious to know this, so give a caveat saying that reading this chapter is totally optional.
  6. Containerize your application(one section for each stack)
  7. Docker compose
  8. Optimising your docker images
    1. Reducing the size of images
    2. Keeping images up to date
    3. Securing your images
    4. Best practices
  9. Docker registries and how to use them
  10. Building container images using other means
  11. Docker ecosystem. Depending upon the size of the book, I may drop this chapter.
    1. Amazon ECS
    2. Azure containers
    3. Google cloud run

Go code it! #

The next step is to produce a clean first draft right? Wrong! Greg suggests that we first write the code for all the scenarios in the book. I also want to take the liberty of adding a lot of exercises. I read somewhere that readers perceive more value if a technical book or course contains ton of exercises. Once the code is written out there, writing becomes easier, because all we are doing is explaining our code. So, it is “off to the IDE” for me now! I’ll update my progress here as I attend future sessions of the cohort.

Want the source code used in this post?

Share your email and I'll send an invitation to the Github repo which contains the source code used in this post.

    By clicking subscribe you agree to share your email address with me to receive emails. Use the unsubscribe link in those emails to opt out at any time.