Preface
About This Book
Over the past few years, I’ve found myself solving the same problem again and again. With the rise of cloud computing and the shift of infrastructure closer to developers, engineering teams have reshaped the way they work and think about software delivery. We’ve moved from traditional IT and sysadmins managing servers, networks, and infrastructure, to a DevOps culture designed to bridge the gap between development and operations. It’s now clear that developers can take more responsibility for the infrastructure powering their applications.
However, in many organizations, developers neither have the time nor the desire to master infrastructure management. They want to focus on building products that deliver business value. While most of us agree that DevOps is the right direction, many organizations still struggle to make it work in practice.
That, in my view, is what gave rise to Platform Engineering. It doesn’t replace DevOps — it enables it at scale. Platform Engineering formalizes the creation of internal platforms that abstract away the underlying complexity of cloud infrastructure, providing developers with paved roads and self-service capabilities that make them more productive and autonomous. Developers can then focus on writing software while the platform takes care of networking, compute, automation, security, compliance, and scalability - the essential scaffolding that keeps everything running smoothly.
I’ve had the opportunity to tackle this challenge in several organizations, and I’ve never solved it the same way twice. There is no “one-size-fits-all” platform. Every company has its own DNA — its own culture, processes, and constraints. That’s why I believe building platforms is an artisanal craft. Yes, there are universal principles and foundational components. But how you combine them, and the trade-offs you make, will always depend on your specific context.
Cloud infrastructure, CI/CD, observability, vulnerability scanning, identity and access management, secrets management, internal developer portals, and more. Most of us would agree that these are the basic building blocks of modern platforms. But which clouds should you use? Which CI/CD stack? Do your engineering values align better with Azure or AWS? With GitHub or GitLab? What are your compliance requirements? Do you need multi-region deployments, hybrid setups, or on-prem integrations? What’s your capacity and money to invest in building a platform? These are the questions that shape your platform — and there’s never a single right answer. This book won’t give you exact answers to these questions. I am sorry. But hopefully will put you in the right path to craft a platform that works for your organization.
And, honestly, the hardest part is not even the technical implementation, but selling it to the rest of the team. Making it appealing for others to buy in, and move their workloads, pipelines and processes to it. A platform is a product, and like any product, it needs to find its market fit. It needs support too! This involves understanding the needs of your users (developers), communicating the value proposition effectively, and continuously iterating based on feedback. It’s a journey that requires patience, empathy, and a deep understanding of both technology and human factors.
The approach of this book is practical, not academic. It doesn’t aim to be a comprehensive guide on team formation and management, although I’ll make some comments on that. Instead, this book focuses on the fundamental concepts, principles, and lessons I’ve learned building secure, robust, scalable, and multi-tenant platforms.
With this book, I aim to surface the right questions and share an opinionated perspective on what I believe to be the foundations of building platforms. Other engineers may have taken different paths, and that’s perfectly fine. My goal is to provide a practical, experience-driven exploration that helps you craft the platform that fits your organization’s unique needs.
What You’ll Learn
The platform design presented in this book may be somewhat opinionated, and that’s intentional. However, many of the principles and practices described here are universal and applicable in any circumstance that requires building a platform. In the following pages, you’ll learn about:
- Historical context and internal developer platform (chapters 1 and 2)
- Segmentation (chapter 3)
- Capabilities: Infrastructure & Resources, CI/CD, Observability, Security and Compliance, and Developer Experience (chapters 4, 5, 6, 7 and 8)
What This Book Is Not
This book is not intended to be a deep dive into networking, cloud computing, infrastructure as code, CI/CD, observability, or security. There are many excellent books dedicated to each of these subjects, and they are referenced throughout the chapters when appropriate.
Instead, this book is about navigating the entire journey of building a platform from scratch — understanding the problems you’ll encounter, the questions you need to ask, and the decisions you’ll have to make. It’s about the big picture: how all these pieces fit together in the context of your organization.
For each major question or challenge, I provide an opinionated solution based on my experience. These opinions are not absolute truths — they’re starting points, proven patterns that have worked in real organizations. Your context may differ, and that’s expected. The goal is to help you understand why certain decisions matter, when to make them, and what the trade-offs are, so you can adapt them to your specific needs.
Think of this book as a field guide for platform builders, not an encyclopedia of technologies.
How to Use This Book
Each chapter is designed to be both reference and practical guide. I recommend reading the book in order, as some concepts build upon others. But once read, it can be used as a reference book. Code examples are available in the GitHub repository that accompanies the book.
Conventions
- Bold text for important concepts
Inline codefor commands and file names- Code blocks for extensive examples
Notes and Warnings
Throughout the book you’ll find different types of boxes:
Source Code and AI Agents
Originally, my plan was to accompany this book with a GitHub repository full of Terraform modules and infrastructure-as-code snippets. However, the rapid adoption of AI has reshaped how we build software and infrastructure. As platform engineers, we are becoming less hands-on with raw configuration and more focused on architecture, requirements, and refinements.
Therefore, this book and its companion repository take a dual approach. The book you are reading is aimed at professionals—humans—who want to understand the nuances of building a platform, the core architectural concepts, and key decisions. The companion repository, on the other hand, is built for AI agents.
Instead of a traditional codebase, the repository is a vendor-agnostic collection of AI artifacts for platform engineering: skills, commands, agents, hooks, and MCP servers. Skills encode reusable task guidance—how to design a segmentation strategy, scaffold infrastructure, audit security, and more. Commands wire skills into named workflows. Agents are specialized definitions with narrow scope. Hooks provide event-driven automation, and MCP servers expose domain-specific tools. If our future involves instructing AI agents to build what we want, we must ensure they do so with the quality and standards we expect. So, we are now writing technical knowledge for both people and machines.
You can access the companion repository at: github.com/craftingplatforms/ai
Bibliography
There is an appendix at the end of the book with a bibliography of the main references used throughout the chapters. You can find cites to these references in the text where appropriate. For example, [Skelton, 2019] discusses team structures for platform engineering.
I don’t recommend you to go and buy all the books listed. Instead, use the bibliography as a curate list of resources to explore specific topics in more depth as needed. Some references are there for completeness.
Statement on AI Use
I use AI throughout the entire workflow of this book—writing, editing, translating, and iterating on content. But let me be clear: the ideas, direction, opinions, and final reviews are entirely mine. AI doesn’t write this book autonomously on its own terms; it writes on mine, using my tone, my perspectives, and my designs. Every architectural decision, every opinionated stance, every story comes from my experience as a platform engineer. AI helps me get it on the page faster and keep all the moving parts—the book, the companion skills repository, and the Crafting Platforms Newsletter—up to date.
This approach lets me iterate much more quickly than I could alone. Because of that, I’m making a free HTML version of the book available online. If you’d like to support the project or prefer reading in other formats, you can purchase the ebook edition.
Contact
If you have questions, comments, or suggestions, you can subscribe to newsletter.craftingplatforms.com or contact me directly at my personal email: ezequiel@foncubierta.com
You can also follow me on:
- Substack: https://substack.com/@principiamachina
- BlueSky: https://bsky.app/profile/foncubierta.com
- Personal page: https://foncubierta.com