Shipped 60 percent of the book
A quick update on the progress of the book and what's coming next
Last weekend, I released a big update of the book, which included four new chapters:
Chapter 3: Platform Notation
Chapter 4: Segmentation
Chapter 5: Identity and Access Management
Chapter 6: Infrastructure
Let’s dig into the details of this update and what it means for the project.
Platform Notation
One of the biggest challenges I faced while writing this book was keeping it as agnostic from specific cloud providers as possible. Every provider—whether AWS, Azure, or GCP—has its own jargon and subtle behavioral differences (like Accounts vs. Subscriptions vs. Projects). To solve this, I decided to abstract the terminology we will use throughout the book by introducing a Platform Notation.
I explicitly didn’t want to use Terraform or other configuration languages because I want to abstract the reader from such complexities. You shouldn’t need to understand Terraform, Helm, or the like to read this book end-to-end. Instead, this notation is loosely based on the Golang type system, which I find simple and easy to read without all the boilerplate. Anyone familiar with a typed language will understand it quickly.
The notation is built on primitives like Types and Coordinates. For example, a type uses a functional syntax like Name(Parameters):
Group(Tenant = “payments”, Tier = “live”, Role = “admin”)Using positional inference, this becomes even cleaner:
Group(”payments”, “live”, “admin”)
The most important concept introduced in this chapter is the coordinate. A coordinate acts as an address for every resource in the platform, expressed as a tuple. Since every resource needs to land somewhere, this coordinate system will become extremely relevant in the next chapter (Segmentation) and will be used everywhere to define boundaries and placements. For example:
(”ecommerce”, “live”, “eu01”, “payments”)— A fully resolved address.(”platform”, “live”, _, _)— An address that ignores the regional and tenant dimensions.
I’m still figuring out the Associations part of the notation (how we express relationships between resources). As I write the book and start relating more resources, I’ll see what symbols are easiest to read. For now, we are experimenting with simple operators like in for hierarchy or <→ for connectivity (e.g., Spoke(...) <-> Hub(...)).
Segmentation
Segmentation is actually the reason why I started writing this book. When you read about platform engineering, there isn’t much written about this topic—you usually have to figure it out yourself. In my opinion, it is one of those things you need to put on the table from day one, even if you don’t implement it fully right away. Migrating to a different segmentation model later on is extremely costly, and you want to avoid that pain. You don’t need to over-engineer it, but you absolutely need to design around it as soon as possible.
Segmentation solves critical problems in modern infrastructure: it drastically reduces the blast radius of failures, lowers cognitive load by giving developers a narrower environment to think about, ensures security and compliance, and allows you to apply different rules for different contexts.
In the book, we configure segmentation across four primary dimensions: Sector, Tier, Region, and Tenant. You can mix and match these, or expand them to better align with your organization, but I’ve found these four give enough flexibility for most companies. For example, you might have an internal Sector(”platform”) and a business Sector(”ecommerce”), separated into Tier(”sandbox”) and Tier(”live”) environments.
The key takeaway is that by using these dimensions, we create clear boundaries (what the book calls Core Space and Tenant Space). Everything we build in the following chapters will rely on these boundaries, meaning our platform is segmented by design. We will discuss segmentation and the nuances of these dimensions in more detail in dedicated articles in the near future.
Identity and Access Management
This chapter is still a work in progress, but it already covers the essential building blocks for protecting platform resources. While I’ve left out general user management (which typically falls under the IT team’s responsibilities), I’ve focused on what’s critical for platform engineering: Groups, Roles, and Federated Identity.
To keep things simple and secure, I’ve standardized on four basic roles:
Role(”reader”): The default standing access for everyone—enough for 90% of daily troubleshooting.Role(”contributor”): Used for active troubleshooting or manual operations.Role(”admin”): High-privilege access for emergency situations or initial setup.Role(”operator”): Reserved exclusively for automation and CI/CD runners (no human members).
A key highlight of this chapter is the Just-in-Time (JIT) access process. We’ve moved away from “standing privileges” where people have permanent write access. Instead, everyone is a “Reader” by default. When you need to escalate your privileges to a Contributor or Admin role, you do so for a limited time window with a mandatory justification. This ensures every elevated action is properly audited and significantly reduces the attack surface of the platform.
We also dive into Federated Identity, which allows our CI/CD runners and applications to authenticate without using long-lived, static API keys. By using short-lived, cryptographically-proven tokens, we eliminate the risk of leaked secrets sitting in your GitHub or GitLab variables for years.
Infrastructure
Finally, the infrastructure chapter. This one is also still a work in progress, but it tackles how we actually land our workloads in the cloud. We focus on using cloud primitives—like Accounts, Subscriptions, and Projects—to create hard isolation boundaries that align perfectly with our Sector, Tier, and Tenant dimensions.
A big part of this chapter is dedicated to Networking. We dive into multi-region setups using the Hub and Spoke model. This architecture ensures that different networks remain isolated by default, while providing a centralized place to route traffic only when absolutely necessary—without having to manage a mess of sophisticated routing tables or brittle firewall rules.
When it comes to Compute, I make a strong case for using Kubernetes as the primary abstraction layer. It provides a well-defined, industry-standard interface that prevents you from “reinventing the wheel” while abstracting away the specifics of your cloud provider. That said, Kubernetes isn’t mandatory; if your organization prefers ECS, ACA, or even Virtual Machines, that’s fine too. The most important thing is that whatever compute model you choose, it must be properly standardized and abstracted so your development teams can focus on building products, not managing servers.
What’s Next?
With 60% of the book completed, the foundation is now solid. We have our notation, our segmentation strategy, our identity layer, and our core infrastructure. In the coming weeks, I’ll be finishing up these chapters and moving into:
Chapter 7: CI/CD
Chapter 8: Observability
Chapter 9: Security and Compliance
Chapter 10: Developer Experience (DevEx)
That’s all for now!
If you have come this far, here is a gift: book.craftingplatforms.com. You can still purchase the early access to get the ebook, but I am publishing an online version too for everyone to read. Early access buyers will get exclusive Crafting Platform content. This will be announced next week.