Ansible for Kubernetes, my second self-published book

Five years ago, I set out to write a book. For a topic, I picked Ansible, since I was familiar with the software, and noticed there weren't any other books about it. I struck gold with Ansible for DevOps, and have since sold over 22,000 copies between eBook and paperback copies.

I've written about self-publishing before, and my opinion about publishing technical works is stronger than ever:

• Don't write for a publisher (usually)
• Use the Lean Publishing process

I wrote an entire article (Self-Publish, don't write for a Publisher) on the first topic. Regarding the second topic, I see writing a technical book on the same plane as building a software project:

Version 1 sucks, but ship it anyway.

If I didn't start publishing Ansible for DevOps when I only had three rocky chapters, I wouldn't have gotten the early feedback that made the book a hundred times better. I also wouldn't have realized the demand there was for the book—I hoped for 100 sales, and planned on writing around 100 pages. Before I released version 1.0, I had sold 2,000 copies and written 400 pages!

That blew my mind (and still does). Since releasing 1.0, I've published more than 20 major revisions. I update the book regularly across LeanPub, Amazon (Kindle and paperback), and iBooks¹, and have received tons of feedback from my book's readers, who continue improving the book's relevance. I also have automated test coverage for the majority of the examples used in the book, so I can maintain and keep relevant all the different 'infrastructure cookbooks' inside.

Building on success with my second book

With that in mind, I started working on a second book in late 2017. Unfortunately, life got in the way. My body was almost literally committing seppuku, so I had a major surgery. My job was not helping much, as I got caught up juggling three concurrent stressful projects².

Writer's block can be crushing when you don't have the strength to push through. It also didn't help that I have three active kids under 7, whereas I had one sleepy newborn while writing Ansible for DevOps! Luckily, I have been doing (mostly) good health-wise since mid-2018, and moved on from the stressful work environment.

And now I'm writing. I have almost four complete chapters, and an outline and material for at least five more. Just like Ansible for DevOps, I'm publishing book as I write it on LeanPub. And my book will always be DRM-free³, available in any format you like, with free updates forever.

When will the book be complete?

That's a good question! If you asked me the same about Ansible for DevOps, I might say "never!", as the book has had four new chapters added throughout its 20 revisions, with two or three complete chapter rewrites for new Ansible versions. I don't use 'Editions' because that would gobble up precious ISBN numbers, require a drawn out process to get the new editions listed properly in all the bookstores, and is generally a heavyweight process that doesn't jive with lean publishing.

But I do hope to reach a version 1.0 by the end of next year.

So then the question is: why should I buy the book today if it's not yet complete?

The answer to that is easy: lean publishing means I already provide value through the partially-complete book—and you will get continuous improvements to the book as I update it. Another early-mover advantage is you can help shape the content of the book. There are a number of sections in Ansible for DevOps which wouldn't be there without readers requesting their addition, and it will be the same for Ansible for Kubernetes.

Why should I care about Ansible and Kubernetes?

One question I get a lot: Ansible seems irrelevant in a cloud-native Kubernetes environment. Why write a book on these two orthogonal⁴ technologies?

I'd reply that I've never seen a complete, functional, maintainable, real-world infrastructure at a company which is 100% cloud-native, and integrates with zero extra-K8s-cluster resources, and requires no form of orchestration. Sure, there are a few apps which can run completely independent and stateless, and some teams can glue things together using serverless technologies.

But you almost always have to do things like tie an application into a separate cloud service, or link two systems together. Ansible excels at multi-cloud orchestration, and even integrates with Windows hosts and networking gear. It has thorough Kubernetes integration, and can be used to manage infrastructure resources and applications either standalone, or in tandem with other tools like Terraform.

The book explores the question in-depth, offering many solutions to common Kubernetes problems using Ansible. Though, I quote from the book itself:

While Ansible can do almost everything for you, it may not be the right tool for every aspect of your infrastructure automation. Sometimes there are other tools which may more cleanly integrate with your application developers' workflows, or have better support from app vendors.

Ansible is rarely used for everything in a cloud-native app lifecycle, but it's good to know that it can be used, and is often easier to implement and maintain than other solutions.

Don't let 'cloud-native' become your golden hammer⁵.

Some of the topics I cover or will cover in the book include:

• Building Kubernetes clusters with Ansible
• Managing managed Kubernetes (EKS, AKS, GKE, etc.) clusters with Ansible
• Using Ansible in your container build, test, and deployment (CI/CD) workflows
• Integrating Kubernetes apps with external resources with Ansible
• The Operator SDK and Ansible-based Kubernetes operators

You might even learn a little bit of Go in the course of the first chapter!

Where can I buy it?

You can purchase Ansible for Kubernetes from LeanPub today, and no matter when you purchase it, you will get free updates for as long as I keep updating the book—hopefully until I'm no longer able to write!

¹iBooks barely moves the needle on sales. I'm still not sure if it's worth the ~30 minutes per quarter it takes to update the book on iBooks, for the paucity of sales I see on that platform.

²What corporate software project isn't that way? My problem was I was in the midst of three of these... I could maybe handle one at a time!

³I see Ansible for DevOps PDFs published to all kinds of seedy sites on a weekly basis, and some people have asked why I don't use DRM or file DMCA takedowns. Two reasons: that's a huge time commitment, and I just keep updating the book, so the free archived PDFs people find are never going to be as good as 'the real deal'!

⁴I avoid using this term, but found it funny it popped into my head here; I think the only times I've ever seen the term used is on Hacker News, when someone complains that two things everyone else are relating are, indeed, unrelated and should never be related. I imagine if this post gains any traction there, someone on HN will ask that exact question... and maybe use 'orthogonal' to describe Ansible and Kubernetes.

⁵Some argue Ansible is my golden hammer. And they're probably right. But hey, I started out with PHP. Golden hammers are kind of our specialty.