Starting late in 2020 and wrapping things up today, I streamed a new 10-episode series, Kubernetes 101 (the first episode is embedded below).
Five years, 834 commits, and 24 major revisions later, I've just published the 2nd edition of Ansible for DevOps, a book which has now sold over 60,000 copies and spawned a popular free Ansible 101 video series on YouTube.
Making good on my promise to make the ebook updates free, forever, I've published a new revision of the book at least once a quarter since I published the first revision (version
0.42) on LeanPub in 2014, and the second edition begins the
2.x series of book revisions.
The book covers the basics of managing Linux servers, then dives deeper into continuous integration, application deployments, container image management, and even Kubernetes cluster management with Ansible.
In March, I made my DevOps books free to help anyone who wanted to learn new skills during the global pandemic lockdown. In April, Device42 generously extended that offer for another month.
I originally had the idea to give the books away on a whim on a Sunday night, thinking I'd give up a fair chunk of revenue, but nothing too substantial. The response I did get was overwhelming, to say the least!
Every few months, it seems a new post decrying the use of markdown for documentation (or other things) rises to the top of Hacker News.
There are often good reasons for preferring a more structured option, like reStructuredText, LaTeX, or Asciidoc. Especially in projects where more formal text is required, or where you need to support specialized and structured text formatting.
But for 98% of software projects (and in my experience, 95% of all other text I've ever written), markdown suffices, and it is truly a low barrier compared to the alternatives. It's basically plain text (which anyone can learn to write in a few seconds) with extra features.
March 31st Update: Through Device42's generosity, this offer's been extended through the month of April!
The ongoing Coronavirus/COVID-19 pandemic and bear market made me realize how beneficial it has been to be adaptable in the tech industry. There are no guarantees in life, and the ability to earn a livelihood is probably the most underrated important aspect of overall health. Most people take it for granted until they are deeply affected by it.
I can't do much to help during this crises, but I figure that I can make my two books, Ansible for DevOps and Ansible for Kubernetes, free for anyone who wants to learn a new skillset as a buffer against possible coming layoffs.
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:
Since 2014, I've been working for Acquia, doing some fun work with a great team in Professional Services. I started out managing some huge Drupal site builds for Acquia clients, and ended up devoting all my time for the past couple years to some major infrastructure projects, diving deeper into operations work, Ansible, AWS, Docker, and Kubernetes in production.
In that same time period, I began work on my second book, Ansible for Kubernetes, but have not had the dedicated time to get too deep into writing—especially now that I have three young kids. When I started writing Ansible for DevOps, I had one newborn!
Though I've had a little less time to work on the book lately, I'm still very much invested in keeping Ansible for DevOps the best and most up-to-date guide to using Ansible for infrastructure automation. It's been over two years since the first '100% complete' edition was released, and in that time I have published over 200 updates on LeanPub—and even have full test coverage for all the book's examples, which are open-sourced and available in the Ansible for DevOps GitHub repo!
For this year's Black Friday, I'm discounting the book—50% off—but only on LeanPub. I like to push readers to LeanPub, because:
I'm not a writer. I'm a software developer who communicates well. Because I'm a developer and software architect, I spend time evaluating solutions to find the best one. There are often multiple good options, but I try to pick the best among them.
When I chose to write a book two years ago, I evaluated whether to self-publish or seek out a publisher. I spent a lot of time evaluating my options, and chose the self-publishing route.
Because I'm asked about this a lot, I decided to summarize my reasons in a blog post, both to posit why self-publishing is almost always the right option for a beginning author, and to challenge publishers to convince me I'm wrong.
Today LeanPub published it's 25th episode of the LeanPub Podcast, and in it, Len Epp asked me about a wide range of topics, including AI, the impact of smartphones on interpersonal relationships, how I got started in computing, and how I self-published a bestseller, Ansible for DevOps, on LeanPub.
A few decent quotes from the interview:
[On how I learned technical/tutorial writing:] Go sit down, sit through all the tutorials, and then write up a guide that will help people to quickly get up to speed on it”. Because the manuals you get with the manufacturer are pretty much junk.
As a technical person I hate the idea of DRM on a book. Because it’s like, when I go to a bookstore and buy a book, I don’t have like a locking mechanism that I have to unlock to read it.