My name is Eyal, and I am a cloud security architect.
In my spare time, I promote cloud adoption, by sharing knowledge, writing blog posts, and from time to time, conducting lectures about various aspects of cloud services.
In 2022, I published my first book – Cloud Security Handbook by PACKT Publishing, which provides knowledge about cloud security services, for anyone who uses AWS, Azure, or GCP.
In May 2023, I began considering writing my second book.
To write a book, you need to contact a book publisher and submit a book proposal, and if everyone agrees on the contract terms, you will sign a contract with the book publisher, and begin writing chapters, according to an agreed time frame.
In June 2023, I was approached by BPB Publications, with an offer to write a book about "Cloud Auditing", and since this topic is not my specialty, we scheduled a meeting and I was offered another opportunity to write a book about security in cloud-native applications.
Writing process
From my personal view, cloud-native applications are considered one of the hottest topics in the IT and development domain.
Although I come from an infrastructure security background, I considered the offer for writing a book, as my next professional challenge.
It requires me to do research while writing the book, conduct experiments in different services from AWS, Azure, and GCP, read vendors' documentation, understand best practices, and more.
It took me out of my comfort zone or things I did and experienced in the past, such as writing short samples of code, creating test labs for Kubernetes, etc.
Writing blog posts, comes naturally for me, meaning, once I find a topic, I believe people are missing information about, combined with a muse for writing (something difficult to catch), I’m able to complete 3-5 pages of a blog post, easily.
Writing an entire book (200+ pages) is a challenging process.
You should align to a predefined schedule, you need to think in advance about the number of chapters, topics, and headlines, and begin filling each chapter with content.
In this book, I put a lot of effort into creating diagrams, to make the topics easy to understand by the readers.
Another thing I did to make the book practical, was to find and embed code samples. Some of the code samples were full (and I had to test them, to make sure that are fully functional), and some were just partial code samples (which I added a note for the readers).
My goal, same as I had in the first book, was to write a practical book – something that a reader can refer to, everything they stumble on a topic that they are looking for more information, best practices, etc.
On average, my schedule was to deliver a new chapter every 2-3 weeks, depending on the length of the chapter, so most of my work was usually during weekends since I am working a full-time job.
Working on my second book, was pretty much like the work I did on my first book.
Usually, book publishers have their template for writing the chapters (in terms of fonts, headlines, etc.)
You duplicate the original template for the first chapter you write, and then, when you move on to the next chapter, you can duplicate the previous chapter, adjust the title and headlines, clean everything else, and begin the hard work of writing a new chapter.
When I prepared the book proposal, I had to imagine in my head what topics would appear in each chapter, so the next thing I usually do, is to begin researching the topic – investing time in searching for references in the vendor's documentation, blog post, etc.
For this specific book, since it focuses on applications, I also took the time to search and adjust code samples, deploy test labs, try some open-source tools to be able to take some screenshots and make sure all code samples are fully functional, and if adjustments are required, I would add notes below the code samples.
As always, when you write a book talking about the technical aspects of three cloud providers, you find out that even though in most cases they are trying to achieve the same goal, or to have the same capabilities, there are many examples that each cloud provider implements its services differently, or that their services' capabilities are different.
Reviewal process
Once I completed writing each chapter, I used to submit my draft for review by a content development editor, who used to review my draft, make grammar and some other design adjustments, and send me a copy of the draft to accept or reject the changes.
After I finish accepting the changes to the draft, the draft is sent to a technical reviewer, to add his comments and recommendations for fixing some of the content, or adding some additional content, until finally the work on each chapter is completed.
Working with a technical reviewer requires attention to his comments. You need to fully understand the comments and make a decision whether you need to make adjustments or keep things the way you wrote them.
Luckily, the technical reviewer was a colleague of mine, so I was able to chat with him directly, understand his comments, and make sure everything I write is correct and all code samples were working.
One last thing about the review process – once I received the final drafts of each chapter, I wanted to make sure everything would look perfect – meaning, no spelling mistakes, and no paragraph or code samples break between pages, to make it easy for the readers.
Making things practical
Since technology keeps evolving, during the technical review process, I found out that some of the cloud provider’s service names were changed over time, some capabilities were deprecated and some of the commands I wrote in the book (after testing them on my environment), were not working, and I had to replace them and test them again before publishing the book.
Since the book focuses on technical materials, and since the technology discussed in the book keeps evolving, whenever I get a new draft of my chapters, I try to make sure that if new features are released or if service names are changed, I will be able to update the content, before the final copy of each chapter is approved, and before the book is released.
Side projects
Other than the actual work on research, practice, and writing content for the book chapters, I had another challenge – before committing to writing my second book, I volunteered to be a technical reviewer for three other books.
During my writing process, one of the books I was a technical reviewer for, was released - Practical Cybersecurity Architecture.
Another thing I didn’t want to limit myself and my creativity, was finding spare time to write blog posts, in parallel to writing the book. It requires the time for research on a topic I wanted to write about. During the time of working on my book, I managed to find time (and muse) to write 16 blog posts on various topics, that I believed required writing about (since in many cases, they were not getting enough attention from my point of view).
Summary
I am looking at writing a book as a journey or something I chose to do, and I enjoyed it.
Sure, not all the time I have the muse to complete another chapter. Sometimes I had to research and deploy test labs to gain hands-on experience with the services I wrote about, and there were cases where I had to sit for several days and figure out why the vendor’s documentation didn’t work in my test lab, as I expected. At the end of the day, it was a good practice for me and a good educational experience.
Now that the work on the book is completed, I will return to writing blog posts, and probably soon, once I find a topic I care about, I will begin another project of writing my next book.
If you are interested in learning how to secure cloud-native applications, my book "Security for Cloud Native Applications" is available for purchase on Amazon bookstore: https://www.amazon.com/dp/B0CYYFNSSQ
About the Author
Eyal Estrin is a cloud and information security architect, and the author of the books Cloud Security Handbook, and Security for Cloud Native Applications, with more than 20 years in the IT industry. You can connect with him on Twitter.
Opinions are his own and not the views of his employer.
Top comments (0)