1. Author’s purpose

The author, Yevgeniy Brikman, had a firsthand experience of the impact of DevOps practices in the company he worked for in 2011 (LinkedIn).
The company, at that time, despite excellent financial results, was almost stalled: releases were done only once every two weeks and were risky and error-prone.
A 10 billion dollar company could not deploy code! (p. xiv).

To fix this, the company halted the development of all new features (for several months) until the release bottleneck could be solved: This was called Project Inversion. The project was successful, and after it, LinkedIn could deploy dozens of times per day, with fewer issues, outages, and overall, the company moved faster (p. xiv).

What impacted the author was that 15 years later, the techniques used by LinkedIn and other top tech companies have not trickled down to the rest of the industry.
15 years later, the top companies can deploy 182 times more often than the low performers, with 1/8 of the failures, with a recovery almost 3 times faster (p. xv), and yet the techniques have not reached the masses.

Hence, the author wrote this book to share the techniques of the top players in software delivery, so that the new generation of companies can profit from the knowledge (p xv). And that the reader
can learn from the experience of others instead of learning the hard way.

On top of this, the author noticed that there is no hands-on guide to teaching software delivery end-to-end (p xiv).
So this book also has the purpose to fulfill a gap: a hands-on guide to DevOps and software delivery targeted at practitioners (p. xxii)

2. Main themes of the book

The main theme of the Fundamentals of DevOps and Software Delivery (henceforth FSDS) is what Brikman calls “The Evolution of DevOps”.
For a previous book (“Hello, Startup”), Brikman interviewed early employees of successful startups, including Google, Facebook, LinkedIn, Twitter, GitHub, Stripe, Instagram, and Pinterest.
When he asked them about architecture and software delivery, he found out that almost all of these startups followed a similar trajectory. He broke that trajectory into 9 steps.

The first step is an app deployed manually (ClickOps) into a single server (probably in a closet of the office).
The last step is multi-datacenter, multienvironment (Dev, Stage, Prod), with Microservices, Service Mesh, Observability, Caching, Multiple databases, Data warehouse, event-streaming platform, developer platform, feature toggles, infrastructure as code, encryption for secrets, monitoring, continuous delivery, Continuous Integration etc.

What is interesting is what Brikman says next: “There’s no one best practice or one right way to ‘do DevOps’. Your architecture and processes need to be adapted to your company’s needs, and those needs will change” (p. 33)
And “Adopt the architecture and software delivery processes that are appropriate for your stage of company” (p.33).

This is so good that I will quote another paragraph, “What you don’t want to do is to immediately jump to the end and use the architecture and processes of the largest companies. Let’s be Honest here: your company probably isn’t Google or Netflix; you don’t have the same scale, you don’t have the same problems to solve, and therefore, the same solutions won’t be a good fit. In fact, adopting the solutions for a different state of company be actively harmful. Every time I see a three-person startup running an architecture with 12 microservices, Kubernetes, a service mesh, and an event-streaming platform, I just shake my head; they’re paying a massive cost to solve problems they don’t have” (p.33)

“The Evolution of DevOps” is the column of the book. Brikman then spends several chapters covering the different aspects of his theory, and he develops it in the following chapters:

1 How to deploy your app
2 How to manage Your infrastructure as code
3 How to manage your apps by using orchestration tools
4 How to version, build and test your code
5 How to set up continuous integration and continuous delivery
6 How to work with multiple teams and environments
7 How to set up networking.
8 How to secure communication and storage
9 How to store data
10 How to monitor your systems
11 The future of DevOps and software delivery.

As another way to see Brikman’s book, I believe he also divides each chapter in two:

1. Critical analysis of major decisions technologies DevOps/Developers, Architects should take.
2. Short tutorials to bring you up to speed on some of the basics of DevOps deploying techniques and tooling in 2025.

3. Commonalities with other books

In this book, the reader will find mentions and short tutorials on the technologies that are associated with a “DevOps job” in 2025.
In this sense, the reader will find mentions to the cloud, infrastructure as code tools, CICD pipelines, containers, orchestration,
networking, security, etc. Most of these technologies have been covered in other books like the Unix and Linux System Administration Handbook.
The advantage of Brikman’s book, is that it’s updated to 2025, so it’s more relevant. Example instead of covering Jenkins, the pipelines are created with GitHub Actions.

Concerning the pure technology aspect, this book is a great overview of the technologies that a DevOps Engineer/ System Administrator
will need to touch on a daily basis. It is a good introduction for a developer or a CTO. However, given that the book is written to introduce the technologies, it doesn’t go very deep in each.
The author’s style in this regard is to communicate, introduce, give a flavor, but not become a reference manual for each technology.
In contrast to Brikman’s other book, Terraform Up and Running, in which the author offers the mastery of a single technology.

I still have profited from the technology the author introduced. For example, I found useful to know how to deploy a function in render.com;
I also found useful the recommendations on providers for feature toggles. Other interesting technology aspects that I found useful:

• The jinja pipeline he created inside an Ansible playbook (p. 91)
• The way the author administers his dynamic inventory in Ansible.
• Interesting how he does rollout updates with Ansible.
• Rollout updates using Auto Scaling Groups with Terraform/OpenTofu
• The introduction to serverless and the table of comparison between orchestration alternatives.
• Testing OpenTofu code with tofu test. Also, terrascan, terratest.
• Authentication using OIDC, and an example of GitHub communicating with AWS.
• How to add the “plan” of a terraform PR, inside the comments of a GitHub PR.

Despite all this, the strength of this book is not on the tutorials per se, this is not what makes this book unique.

4. Uniqueness of the book

This book is unique for 3 reasons. The first is Brikman’s concept of the “Evolution of DevOps”. As noted above, Brikman described the 9 stage scheme
on how successful enterprises went from a single workstation, to being a multinational with servers and points of presence all over the world.
With the focus on infrastructure management and software delivery.

The uniqueness of the book consists in that Brikman is the first to include the development of the enterprise as an important
factor in the decision-making process of technology (both code and infrastructure).
Enterprises should take decisions to solve the problems they have, not the problems FAANGs have.

Despite that this concept should be common knowledge, it isn’t, and it’s important that someone came in print with it. But what is new is coming with it in print, in a peer reviewed book, by an established publisher like O’Reilly.

The second topic that make this book unique, is the inclusion of material that is usually not covered in OPS books, but that should be included.

• Version control.
• Test Driven Development.
• Trunk-Based Development.
• Splitting the code in multiple libraries or services.
• Testing infrastructure code.

The third thing that makes the book unique is the amazing wealth of referenced resources. The resources that usually are shortened in an oreil.ly short URL are excellent.
One example of those is in page 494, the mentioning of Basecamp exiting AWS (oril.ly/rhm2Z). I followed the link and was amazed but the wealth of resources and opinions of
the creator of Basecamp (DHH), and followed an interesting rabbit trail of blog posts. The same was also true when the author referenced Leroy Jenkins, I couldn’t stop laughing
for several minutes! The website of the book also has excellent resources, I stumble upon interesting presentations: including one of Brikman himself explaining how to do
unit testing with Infrastructure as Code.

5. Was the author successful in proving his case?

Indeed, the author was successful in his purpose. The book describes to great extent the software delivery techniques of the top players.
He explains the techniques in the light of the “Evolution of DevOps” (described above) and then goes deeper on each topic throughout the book.

Concerning the author’s second objective, he indeed provided a hands-on guide to teaching software delivery end-to-end.
The author presented multiple examples and touched a wide breadth of technologies to do it.

6. Compare the book with the best in the field

The best book in the field is the Unix and Linux System Administration (Fifth Edition) (henceforth ULSAH) by Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley, and Dan Mackin. That book is the bible for Unix and Linux System Administrators, specifically administrators of Debian GNU/Linux, Ubuntu, Red Hat Enterprise Linux, CentOS, and FreeBSD.

Despite both books serve a similar market, they have several differences:

1. ULSAH is a book targeted to intermediate and advanced sysadmins/DevOps; while the FDSD is aimed to beginners, intermediate and advanced sysadmins/DevOps/developers.
2. I considered ULSAH to be a book between “how-to guide” and “reference” in the diataxis classification (https://diataxis.fr/); while the FDSD is more “tutorial” and “explanation”.
3. ULSAH covers more topics with great depth; but misses important topic for DevOps that FDSD have:
   (Testing infrastructure code; Test Driven Development; Trunk-Based Development; Splitting the code in multiple libraries or services, etc.)
4. ULSAH is 1200 page long, while FDSD is 520 pages long.
5. On average, ULSAH cover topics at a lower level; while FDSD covers topics at a higher level.

7. Conclusion

FDSD is an excellent book. It is a book that is suitable to a broad audience for sysadmins, DevOps and developers, of all ranges of experience: All can profit from the book.
This is a book that provides several actionable insights for you to learn and apply at your current company.
And not only the book discusses ideas (like the “Evolution of DevOps”), but also gives you code samples so that you can follow and implement on your own.

Perhaps, the best idea I got from the book was the “Evolution of DevOps”, which in my own words is: “the state of the enterprise as an important factor in the decision-making process of technology (both code and infrastructure).”
But it could also be summarized as “your company is not Netflix nor Google”.

I recommend this book to developers, sysadmins/devops and managers of all levels. For developers, it could be useful to better understand all the tools that they have at their disposal
to deploy code to production. This books would give more autonomy to developers and would help them better understand operations, specially in the cloud.
For sysadmin/devops, this book give is useful to better understands software delivery and to keep up to date with the current technologies in the operations.
For managers at all levels this book would give them vision. The vision on where should their current company should go in terms of developments and operations. And what type of projects
should be prioritized to improve the tech throughput of the company.