The Making Of The Serverless Book — Part 2

Sheen Brisals
9 min readFeb 5, 2024

This article is the continuation of the journey Luke Hedger and I have been through to bring out our book Serverless Development on AWS: Building Enterprise Scale Serverless Solutions (O’Reilly, 2024).

In Part 1: The Proposal, I covered the idea inception, the proposal, and signing the contract with O’Reilly. This article details the rest of the process involved in bringing the book to your hands.

The Writing

As you expect, writing is the longest phase. With our project and development editor in place, the process became streamlined — like project management and product delivery. Development editors are capable content editors who act as project managers and handle multiple book projects at the same time.

NOTE: While creating the book outline, Luke and I split the chapters between us based on our expertise and the subject of each chapter. This helped us reduce the overall duration and reflected in the delivery schedule as captured in the contract.

Writing tool

O’Reilly has an application called Atlas that supports AsciiDoc and other markup languages with Git integration. But, for simplicity and convenience, we decided to use Google Docs. I usually had my drafts on Microsoft Word before transferring them to Google Docs. I had Grammarly to catch any obvious mistakes before submitting them for review.

We set up a shared folder with a Google Doc for each chapter. Once Luke and I were ready with the draft of a chapter, we shared it with our project editor first and then with our technical reviewers.

The significance of the initial chapters

We had a jumpstart! During the proposal phase, rather than sitting idle, we were writing. By the time we signed the contract, we had the drafts of nearly three chapters, and it helped us calm the nerves a bit.

The on-time completion and the quality of the initial few chapters are crucial. Development editors use these chapters to assess the authors' quality and ability to deliver. They will also get thumbs-up/down feedback from their SMEs and tech reviewers as well.

TIP: Once I heard from a popular author that nearly half of book writing projects never get completed. Publishers will be very pleased if they see a constant progress with clarity and confidence from the author(s).

The writing style

Luke and I followed our individual writing style. One common theme we decided on was to keep things simple. There were no specific instructions from O’Reilly, but our development editor advised us to use the ‘you’ tone to sound as if we were engaging or talking directly with the reader.

During the writing phase, it’s not essential to perfect the content beyond the need of the review. Later, the production team will bring content editors for in-depth scrutiny of every word in every chapter!

Collaboration with the project development editor

As an author, you will have a long association with your development editor. Luke and I used to have a fortnightly online check-in for 15-30 minutes until we entered the production phase. This is the time to bring any concerns, questions, clarifications, and so on. They will also provide feedback and update you on processes.

TIP: Delays and disruptions are often inevitable. Be open and bring them up with the development editor to adjust the schedule and expectations. Events such as holidays, family occasions, weekend getaways, or business trips when you are least productive are worth flagging as early as possible.


Every publisher has a unique diagramming style. That means, regardless of how fancy your diagrams are, they will get redrawn (unless you request to use any of them as is).

I used, Lucidchart, and PowerPoint to draw my diagrams.

We maintained a shared Figure Log folder to upload all our diagrams for each chapter with the figure number and label. The production team brought in illustrators to redraw these diagrams as per O’Reilly’s style.

As several of our diagrams contained AWS service icons, we downloaded the latest PowerPoint slide deck from AWS Architecture Icons and shared it with the O’Reilly team. To make the illustrator’s job easier, we cross-referenced the slide number and the icon name in the slide deck for each of our diagrams that had AWS icons.

TIP: As diagams will be redrawn by the publisher, as an author, thre’s no need to spend hours perfecting your diagrams — saving valuable time during writing. In some cases, even photos of handdrawn sketches are perfectly acceptable!

Availability of O’Reilly resources

O’Reilly’s learning platform is vast and wide and contains books from O’Reilly and other publishers. As O’Reilly authors, we had full access, and it served us as an ocean of resources during writing.

Another great privilege we had was receiving the requested print editions of O’Reilly books as references and having them delivered.

NOTE: Use of third-party pictures requires permission to be included in the book. Every reference, quote, etc., will be fact-checked during content editing.

As the draft of chapters becomes available, O’Reilly will create the early-release version of the book and start sharing the content online via O’Reilly’s learning platform. It acts as an advertisement but importantly, a way to gather feedback from the community.

The Review

Technical review is a significant activity, passing the content through the scrutiny of subject matter experts. We put forward names, and O’Reilly suggested a few. The three technical reviewers of our book are giants in the industry, and we couldn't have asked for anyone better.

  • Jeff Barr, VP & Chief Evangelist, Amazon Web Services.
  • Luca Mezzalira, Principal Serverless Solutions Architect, Amazon Web Services; O’Reilly author.
  • Mike Roberts, Cloud architecture & DevOps consultant; O’Reilly author.
  • Adrian Cockroft, Partner, OrionX. (Special reviewer for chapter 10).

The chapter review process

It was a scary process for me. I always had this question: is my content good enough for the experts? Once the draft of a chapter is ready or nearly ready, the development editor will suggest sharing it with the reviewers. Sometimes, two or three chapters go together for the review.

Review comments would come in from each reviewer at different times, and we would’ve moved on to writing a different chapter. To minimize disruption and avoid getting sidetracked, we often resisted attending to the comments until we finished the chapter in progress.

Incorporating review comments

As an author, you go through a challenging situation here. Tech reviewers add comments to make the book better, but you may find some comments disruptive to the content you have already written. It requires a balancing act. You have to develop a mindset to accept suggestions that enrich and add value to the content, but at the same time, in certain places, you stick to your original idea. Our development editor would often remind us: You are the experts, and it is your creation.

Each reviewer’s style of review is different. For example, Jeff Barr’s reviews were deep. He made a mark on the book's opening statement and finished with a “yay” for the last sentence of the final chapter. While thanking Jeff for his contribution when I met him at AWS re: Invent 2023, I conveyed our admiration for his detailed review. For this, he answered-

When I review content, I would like to do a thorough job and not leave it to others to pick things up!

The Production

On 31st October 2023, our project formally entered the production phase, and the production team came on board to work with us.

Though Luke and I had completed the chapters and figures, we still had a few parts of the book outstanding at this stage— case studies, foreword, and a few experts’ Q&A.

Roles and responsibilities

While the development editor is still part of the process, here are a few roles we interacted with.

Production Editor — the one in charge of the preparations and activities to get across the finish line.

Copy Editor — an awesome content editor who can turn your content upside down and make it readable for everyone.

Illustration team — one or more people who take care of redrawing the diagrams.

Indexer — the person who creates the book index.

Marketing team — one or more people who engage with the authors to provide guidance on marketing the book.

The publication schedule

We were given a provisional schedule to work with as soon as the production editor and team were assigned. From here, it was push-push-push until publishing.

  • Copy editing: 1st to 14th November 2023
  • Copy edit review: 15th to 17th November 2023
  • Content cleanup: 20th to 21st November 2023
  • Content conversion (from Google Docs to O’Reilly platform): 22nd November to 5th December 2023
  • Quality Control (QC) preparation and art review: 6th to 7th December 2023
  • QC1: 8th to 15th December
  • QC1 edits: 18th December 2023 to 2nd January 2024
  • Praise quote deadline: 2nd January 2024
  • QC2: 4th to 5th January 2024
  • QC2 edits: 8th January 2024
  • Out The Door (OTD): 9th January 2024
  • Files to Printer (FTP): 10th January

The above was the original intended schedule. However, after a couple of weeks of delay, our production was completed on the 23rd of January, 2024, when we received the following message from our production editor!

Hi Sheen and Luke,

Congratulations! Your book went to print today, and we’ve now completed production.

The ebook versions will be available within a week, and print books will start appearing in about 3–4 weeks.

Sustaining the book

Though the digital and print editions complete the work, marketing, gathering reviews, and attending to the book errata continue.

If you have noted an error with our work, please raise it here:

Behind The Scene

Though everything sounded smooth and planned, it wasn’t always like that. We had our fair share of frustrations, self-doubts, schedule slips, disappointments, and so on.

At times, it was tough balancing writing with the day job. I didn’t lock myself inside a room or travel to any tranquil place for writing. My productive writing happened during the early mornings. I maximized my weekends and vacation days without sacrificing much on my personal and family duties. Long walks, for example, have been my thinking times to generate ideas, which I do even when I write blogs or prepare for a talk.

Chapter experts

For the chapter experts, Luke and I wanted to bring in a mix of thought leaders, technical experts, AWS Heroes, software engineers, and community champions. We pitched the idea to them when we met a few of them at conferences; otherwise, via detailed emails. The AWS and serverless communities were extremely helpful with this.

Realizing that everyone is busy with their commitments, we maintained a list of experts for each chapter.

Case studies

The serverless adoption case studies in the book are from two great organizations of different domains. They have already achieved amazing things with the adoption, and their journeys are still continuing in front of our eyes. Our collaborators for the case studies are our community friends and well-wishers; we learn from each other and have mutual respect.

Though the stories are different, we wanted to present them through the same lens to make them consistent — to compare and contrast — for the readers. For this, we provided a template to capture their stories.

Now, It’s Your Turn!

There you have it — the proposal-to-production journey of our book Serverless Development on AWS! Next time when you hold/read an O’Reilly book, I hope you can somewhat visualize its journey.

Luke and I are no experts in writing, except for a few blogs in our names. This is our first attempt. We are two simple and ordinary engineers who somehow managed to cross the river (as in the wildebeest migration), fly safely to the destination (as in the annual journey of birds), or reach the upstream river (as defiant as the Atlantic salmon).

Thank you all so much for your support and appreciation during our journey. We hope what we have packed in the book enables you to navigate the unknowns of serverless to bring joy and value to your work.

If our story inspired you to bring out that idea you have kept in your mind for years, go on and share it with the world. Several publishers are waiting to listen to you.

If you need help or direction, please feel free to reach out to us via social media.

We did it. You can, too!



Sheen Brisals

Co-author of Serverless Development on AWS (O'Reilly, 2024) | Engineer. Architect. Leader. Writer. Speaker. AWS Serverless Hero.