How to Write a Technical Book and Sell Worldwide
On October 10, 2025, I had the privilege of presenting at FikaWorks Day 2025 in Amsterdam—a free, community-driven event bringing together freelancers, consultants, entrepreneurs, and tech enthusiasts in the AI & Cloud Native space.
Held at Startup Village (Science Park 608, Amsterdam), the event featured expert talks, hands-on workshops, unconference sessions, and real conversations about the future of independent consulting and technology collaboration.
Arriving in the morning: the Event Space (the sign says it’s sponsored by Equinix) and the FikaWorks Day poster at the Startup Village entrance.
Event Photos
Morning talk: from Dagster assets to a platform
The first session I photographed came from Overstory, whose logo was on every slide. It was a practical story about running data pipelines with Dagster, in a room lit pink and purple under big wicker lamps.
The event space just before it filled up, with the Dagster slide on screen.
The talk moved from Dagster’s asset model (“Enter the world of Assets…”, with an asset graph on screen) to how the pipeline steps actually get scheduled on Kubernetes. One slide compared two layouts:
- Single-Pod, Single-Node: all three steps in one pod, sized at 4 CPUs and 8 GB.
- Multiple-Pods, Multiple-Nodes: each step in its own pod, sized for its job: 4 CPUs/8 GB for step 1, 16 CPUs/32 GB with a GPU for step 2, and 8 CPUs/16 GB with ephemeral storage for step 3.
Left: Dagster’s asset model. Right: one pod for the whole pipeline versus one right-sized pod per step.
“The next steps… Building a platform”: where the pipeline story was heading.
My take: this is the path I see in many teams. A pipeline starts as one big pod. Then one step needs a GPU and another needs scratch disk, so you split it. Before long you’re building an internal platform. Splitting per step is the point where Kubernetes resource requests, node pools and GPU scheduling start paying for themselves.
My Talk: From Engineer to Published Author
In my session “How to Write a Technical Book and Sell Worldwide”, I shared my journey from platform engineer to six-time published author with leading publishers including Apress (Springer Nature), BPB, and Packt Publishing.
How the session actually ran
I kept it interactive, because everyone was heading for lunch and I wanted a conversation rather than a lecture. There was a single slide, with the covers of my books, and I brought a printed copy so people could handle a real book instead of looking at thumbnails. Most of the time went on audience questions. What I said, in short:
- Where it started. Years of consulting for large companies left me keeping an archive of what was relevant. That became a blog during the pandemic, plus a YouTube channel (I was deep into Ansible then). Packing the blog posts into a book looked easy and was a lesson in how much more a book needs. The first one was Ansible for VMware by Example, and it is still one of my best sellers, because VMware is still everywhere in regulated enterprises such as banks, insurers and airlines, where Ansible is used a lot.
- Traditional publishers. I work with Apress (Springer Nature, a global team based in New York) and BPB (based in New Delhi). In both cases there is one editor and one project manager from the moment you send a book outline, which is essentially a table of contents with titles and subtitles. You then write chapter by chapter in a shared document, the outline can still change, and the closer you get to production the more reviewers and layout rules come in.
- What editors changed in my writing. For every chapter I got feedback. They asked me to explain code line by line for a beginner and to state the intent of each snippet, because for me the code was “self-explanatory”. They also pushed me towards more inclusive wording (allow list and deny list, “we” instead of “you”). The first Leanpub manuscript was copied from my blog; the publisher had me write about half of it again and add new sections.
- Self-publishing. I also use Leanpub and Amazon KDP, which has print on demand. Amazon’s royalty share is around 70%, but nobody validates the text, so quality is on you. The upside is speed: you can update whenever you like, and I mentioned an author who publishes a new edition every year. A traditional publication cycle is closer to three years. I use both, because they reach different readers.
- Why would a publisher pick an unknown author? Publishers are open to proposals. Send the outline and explain why you are the right person. Writing is also a way to think: some of the Kubernetes material in Kubernetes Recipes covered topics I did not fully understand when I started, so I built and tested them in a lab. And if you suffer from imposter syndrome, as I did, send the proposal anyway.
- Money. I was honest that I am not getting rich from royalties. Most technical authors write to build authority and a personal brand and to open doors to consulting, speaking and rooms where you can talk at management level and at engineer level.
I also said I had just finished another manuscript, hoped for December. The recording of the last audience question (about expanding the community) is too garbled for me to summarise, so I leave it out.
The outline I prepared
Ever thought about writing a tech book but didn’t know where to start? This is the outline I prepared for the session; the discussion above covered most of it, in the order the audience asked:
1. Finding Your Topic
- How to identify compelling subjects that publishers want
- Validating market demand before investing time
- Leveraging your expertise and unique perspective
2. Pitching to Publishers
- Crafting proposals that get noticed
- Understanding publisher expectations and contracts
- Navigating advance payments and royalty structures
3. Structuring Your Manuscript
- Building a coherent narrative arc for technical content
- Balancing theory with practical examples
- Managing technical reviewers and editor feedback
4. Global Distribution
- How traditional publishers amplify your reach
- Tapping into international markets (US, Europe, Asia)
- E-book vs. print vs. audiobook considerations
5. Career Impact
- Writing as a tool for building authority and credibility
- Creating new income streams beyond consulting
- How books open doors to speaking, training, and consulting opportunities
Key Takeaways
Attendees left with:
- Actionable frameworks for planning and executing a book project
- Real-world insights from my publishing successes (and mistakes)
- Clarity on the business side of technical authorship
- Motivation to start their own writing journey—whether it’s their first book or their fifth
Why This Matters for Freelancers & Consultants
For independent professionals, writing a technical book is more than just sharing knowledge—it’s a strategic career investment:
- Differentiation: Stand out in a crowded consulting market
- Passive Income: Books generate revenue long after publication
- Authority Building: Being a published author instantly elevates your credibility
- Network Growth: Books connect you with readers, clients, and collaborators worldwide
Afternoon: Kubernetes and local AI on tiny edge devices
After lunch I sat in on a talk by two speakers who split it between Kairos and Cluster API. I could not read their names on any slide, so I leave them unnamed. They began by showing what an “edge device” can be: a single-board computer such as a Raspberry Pi, an ARM or x86 box, an MRI machine, a satellite or a drone.
Trade-offs. They organised the talk around the BLERP framework from the Edge AI and Vision Alliance, which lists five trade-offs for edge AI: bandwidth, latency, economics (or energy), reliability and privacy. Their examples were practical. Keep traffic low by shipping pre-built images and only the delta. Do inference next to the data, for instance on a single-board system watching wildlife in a forest with no network. Edge nodes do not need to be highly available, but they must be reliable. And because the device sits somewhere you cannot reach, whoever has physical access must not be able to compromise the data or steal the hardware.
Why classic bare-metal provisioning does not fit. The standard flow they described: rack the machine, register it in asset management, associate a machine template, let Cluster API create a node, install the OS and Kubernetes, then deploy the workload. Metal3 does this on Kubernetes, with Ironic talking to the board management controller, writing an image to disk (a dd-style write, not an install) and rebooting. That breaks down on single-board computers, which have no BMC. It also does not understand immutable operating systems, which need partitions for A/B rollback and, when a TPM is present, a way to write encryption keys. One speaker presented his own project, Beskar7 (named after the Mandalorian metal), a Cluster API infrastructure provider for bare-metal immutable systems. It deliberately covers only the infrastructure contract, because the control plane is baked into the image. He said it works against BMCs through Redfish, with custom resources for physical hosts, machines and clusters, and it supports Kairos first, plus Flatcar and Leap Micro. He said he had meant to open-source it on stage and found it was already public.
The building blocks. Kubernetes here was k0s, a lightweight distribution whose controller needs no kubelet ports of its own and can use something other than etcd. The OS was Kairos, an immutable, container-based Linux (a CNCF sandbox project): you define it with a Dockerfile and YAML, turn it into a bootable ISO, USB or raw/cloud image, and get atomic upgrades with automatic fallback, factory reset and peer-to-peer cluster enrolment, so three devices can decide among themselves which is the control plane. Inference ran on LocalAI, which is built on llama.cpp so it can run on CPU as well as GPU, and which exposes an OpenAI-compatible API. A model you trained on your own data never leaves the device.
The demo. The plan was to flash a machine and let it install itself, zero-touch, the way you would hand a data scientist a box and say “plug it in”. The speaker said he had tried to prepare it on the train the day before, with USB sticks and a small device on his lap, which drew some looks. The live install ran in the background while he showed a pre-built version: the device advertised itself on the network (ai.local), served a ChatGPT-style chat UI with the model already baked into the image, and was slow, as expected on such a small box, but capable. For real workloads you would pick the right hardware, for example an NVIDIA board. Afterwards a VM booted by the same flow came up fully configured, and k9s showed an ordinary Kubernetes cluster.
In the Q&A they covered the model types LocalAI supports (chat, image generation if you have a strong GPU, text to speech), why you pre-load models at the edge, how Kairos applies cloud-config with its own implementation rather than cloud-init, and the air-gap catch: you must put every container image inside the OS image. They also explained that nodes can be assigned control-plane or worker roles in advance or negotiate them peer to peer.
My take: the point I would carry into client work is that an edge fleet should be treated as appliances. Build the image in CI, bake in the control plane and the model, upgrade atomically and roll back, and never patch in place. The BLERP list is a useful review checklist for any edge AI design, and it explains why a standard cloud-style bare-metal pipeline is the wrong tool for a Raspberry Pi in a field.
About FikaWorks Day
FikaWorks Day is an annual gathering where the community builds the agenda together. The 2025 edition featured:
- Expert keynotes on AI, Cloud Native, and business development
- Interactive workshops on facilitation, AI tools (MCP), and freelancing
- Open Space sessions where participants shaped discussions in real-time
- Networking over coffee, lunch, and evening drinks
The Open Spaces board in the morning. Topics included “CNCF: Certifications”, “Recruiters & finding projects” and “Working in a coop. What does this exactly mean?”
The board covered what independent consultants actually deal with: which certifications are worth it, how to find projects without relying only on recruiters, and what working in a cooperative means in practice.
Closing: a book raffle
Fittingly for a day where I talked about writing books, the programme ended with a book raffle “@16:45 - before closing remarks”. The slide introduced From Cloud Native to AI Native: Catching the Next Wave of Innovation by Pini Reznik and Michael Müller. Pini explained that it follows Cloud Native Transformation, the book he co-wrote about five or six years earlier. The new one is about the transformation process itself: what it takes to actually finish a cloud native transformation, and then move on to AI native. He described it as full of patterns drawn from their own experience, written for the change agents who bring new technology into organisations. Before the raffle I recorded a short video with Pini and Michael, and my copy came back signed; they stressed that the book helps companies make the move to AI in the right way, and Pini added that it is a collection of stories and experience from decades in the field. Pini also said the new book is built around six modes of operation in a transformation, and is aimed at change agents and consultants. Copies of the new book sat on the stage stool next to a copy of my own Kubernetes Recipes.
Left: the raffle slide for From Cloud Native to AI Native. Right: “Thanks for joining us!”, followed by drinks and a food reception at Eetcafé Oerknal.
Four days later I heard Pini speak again, this time about writing a book with AI: Writing a Book with AI: Pini Reznik at ING Amsterdam.
The event exemplifies the FikaWorks cooperative model—independent consultants working collectively to shape the future of technology and consulting.
My Published Books
Throughout my career, I’ve authored six technical books covering Ansible, Kubernetes, Red Hat Enterprise Linux, and Platform Engineering. Here are my published works:
Practical RHEL AI
Designing, Deploying and Scaling AI Solutions with Red Hat Enterprise Linux
Author: Luca Berton
Publisher: Apress (Pre-order)
Amazon: Buy on Amazon
Kubernetes Recipes
Practical Guide for Container Orchestration and Deployment
Authors: Luca Berton & Grzegorz Stencel
Publisher: Apress
Amazon: Buy on Amazon
Apress: Direct Link
Website: kubernetes.recipes
Red Hat Enterprise Linux 9 for SysAdmins
A technical guide for building secure production systems using RHEL 9 administration
Author: Luca Berton
Publisher: BPB Publications
Amazon: Buy on Amazon
BPB: Direct Link
Blog: Read Blog Post
Mastering the Red Hat Certified Engineer (RHCE) Exam
Your complete guide to Linux administration, automation, and certification
Author: Luca Berton
Publisher: BPB Publications
Amazon: Buy on Amazon
BPB: Direct Link
Blog: Read Blog Post
Red Hat Ansible Automation
Deep dive into advanced Ansible techniques, covering complex playbooks, modules, and custom integrations
Author: Luca Berton
Publisher: BPB Publications
Amazon: Buy on Amazon
BPB: Direct Link
Blog: Read Blog Post
Hands-on Ansible Automation
This book provides insights on managing hybrid cloud environments with Ansible, covering multi-cloud orchestration
Author: Luca Berton
Publisher: BPB Publications
Amazon: Buy on Amazon
BPB: Direct Link
Blog: Read Blog Post
Ansible for Kubernetes by Example
Learn how to automate Kubernetes clusters with Ansible. Streamline your container orchestration processes
Author: Luca Berton
Publisher: Apress
Amazon: Buy on Amazon
Apress: Direct Link
Blog: Read Blog Post
Ansible for VMware by Examples
Automate VMware environments with Ansible. This book covers all you need to manage your VMware infrastructure with Ansible
Author: Luca Berton
Publisher: Apress
Amazon: Buy on Amazon
Apress: Direct Link
Blog: Read Blog Post
Learn Ansible 2nd edition (Technical Review)
Automate your cloud infrastructure, security configuration, and application deployment with Ansible
Author: Russ McKendrick
Technical Reviewer: Luca Berton
Publisher: Packt Publishing
Amazon: Buy on Amazon
Each book reached thousands of readers globally and opened doors to consulting engagements, training opportunities, and speaking invitations at major conferences.
Ready to Write Your Book?
Whether you’re eyeing your first technical book or looking to expand your publishing portfolio, the path is more accessible than you think. Key advice:
- Start small: Begin with blog posts or white papers to build your writing habit
- Be specific: Narrow topics often sell better than broad overviews
- Know your audience: Write for the reader you once were
- Don’t wait for perfection: Publishers value practical, timely content
- Build in public: Share your writing journey to build an audience before launch
Connect & Learn More
Interested in learning more about technical writing, publishing, or my consulting work?
- FikaWorks: https://fika.works
- My Books: Available on Amazon, Apress, Packt, and BPB
- Speaking & Training: Open for engagements on Platform Engineering, Ansible, Kubernetes, and Career Development
FikaWorks Day 2025 was a testament to the power of community-driven learning and collaboration. Thank you to the organizers, speakers, and all attendees who made it an unforgettable experience!
#TechnicalWriting #Publishing #FikaWorks #CloudNative #FreelanceConsulting #CareerDevelopment
