From ec0a4f6dd705c562ff076e3be2864b03ddad2cb4 Mon Sep 17 00:00:00 2001 From: PatternCatalyst Date: Thu, 22 Oct 2026 21:16:34 -0400 Subject: [PATCH 1/2] docs: add Bibliography page + nav, link For-deeper-coverage, consistent chapter wording Match the API-patterns sites' structure. - Top nav: "Start here" -> "Contents"; add "Bibliography" (Summary and Demos unchanged). - New bibliography.md (/bibliography/): linked tables of the reference books (verified publisher URLs from the hub reading list) and the primary docs the build uses. Nothing reproduced from them. - For deeper coverage: every book citation across all 13 chapters now links to its publisher page (docs were already linked). 43 links added. - 00-index: the chapters were called "pages", inconsistent with the prose that says "chapter" throughout; normalized to "chapter" and "## The chapters". Verified: 0 em-dashes, jekyll build clean, bibliography renders with links, forbidden-syntax + cross-references clean. --- _docs/00-index.md | 38 ++++++++++---------- _docs/01-concepts.md | 10 +++--- _docs/01-data-architectures.md | 8 ++--- _docs/02-kubernetes-substrate.md | 6 ++-- _docs/03-services-and-data-products.md | 6 ++-- _docs/04-contracts-and-catalog.md | 6 ++-- _docs/05-data-planes.md | 6 ++-- _docs/06-progressive-delivery-mtls.md | 8 ++--- _docs/07-elastic-and-resilient.md | 6 ++-- _docs/08-observability.md | 4 +-- _docs/09-anti-patterns.md | 8 ++--- _docs/10-summary.md | 8 ++--- _docs/11-running-on-openshift-crc.md | 2 +- _includes/header.html | 4 ++- bibliography.md | 49 ++++++++++++++++++++++++++ 15 files changed, 110 insertions(+), 59 deletions(-) create mode 100644 bibliography.md diff --git a/_docs/00-index.md b/_docs/00-index.md index 36ba244..c05a210 100644 --- a/_docs/00-index.md +++ b/_docs/00-index.md @@ -1,7 +1,7 @@ --- title: "The data mesh: start here" order: 0 -description: "The map: what this reference builds, the reading order, and a link to each page in the set. Start here." +description: "The map: what this reference builds, the reading order, and a link to each chapter in the set. Start here." duration: 5 min --- @@ -9,45 +9,45 @@ duration: 5 min By the end of this chapter you can: -- Name the four movements the reference set is organized into and which pages fall +- Name the four movements the reference set is organized into and which chapters fall into each one. - Pick the reading order that matches how you want to use the set: straight through, or jumping to one topic. -- Identify the three pages that cover the pattern's shape if you only have time for a +- Identify the three chapters that cover the pattern's shape if you only have time for a few. -- Locate the page that answers a specific question without re-reading the whole set. +- Locate the chapter that answers a specific question without re-reading the whole set. ## Why this matters -Page 2 names Dehghani's four principles. Page 3 takes the same four and maps each one +Chapter 2 names Dehghani's four principles. Chapter 3 takes the same four and maps each one to a Kubernetes primitive: namespaces, operators, RBAC. That's the shape of this whole set. A concept gets introduced, then you watch it land in a running piece of the -system a few pages later. This page is the map, nothing more: what the reference -covers, the order to read it in, and a link to each page. +system a few chapters later. This chapter is the map, nothing more: what the reference +covers, the order to read it in, and a link to each chapter. The reference builds one working system end to end. A data mesh of services that own their data as products, that talk over a deliberate mix of protocols, that evolve their contracts safely, that scale to demand, and that stay observable throughout. -Read it straight through the first time if you can. Each page picks up where the last +Read it straight through the first time if you can. Each chapter picks up where the last left off, and the cross-references assume you've seen the earlier material. If you're back here looking for one specific thing, the descriptions below point at the right -page. +chapter. ## How the set is organized -The eleven pages fall into four movements. **Conceptual grounding** (pages 1 to 3) +The eleven chapters fall into four movements. **Conceptual grounding** (chapters 1 to 3) covers the landscape of data architectures, what a data mesh actually is, and why -Kubernetes turns out to be a natural substrate for one. **Implementation** (pages 4 to +Kubernetes turns out to be a natural substrate for one. **Implementation** (chapters 4 to 9) builds the system: the services and their data products, the contracts and catalog that make them discoverable, the data planes they talk over, progressive delivery with mutual TLS, elastic scaling and recovery, and the observability to see all of it. -**Failure modes** (page 10) steps back to the conceptual and organizational +**Failure modes** (chapter 10) steps back to the conceptual and organizational anti-patterns that derail data-mesh efforts even when the technology is sound. The -**summary** (page 11) closes by reorganizing the same material by principle: for each +**summary** (chapter 11) closes by reorganizing the same material by principle: for each of the four, the value it delivers and the implementation pieces that realize it. -## The pages +## The chapters - [**1 · Data architectures**]({{ '/docs/01-data-architectures/' | relative_url }}): the landscape from pipelines to lakes to mesh, what each pattern is, the problem @@ -96,12 +96,12 @@ Start with [concepts & principles]({{ '/docs/01-concepts/' | relative_url }}). ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the full argument this reference implements, including +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the full argument this reference implements, including the history and the operating-model shifts this set only summarizes. -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: the data-systems foundations (storage, replication, consistency) that sit underneath every data product in this build. -- *Cloud Native Patterns* by Cornelia Davis: the platform patterns this reference's +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: the platform patterns this reference's self-serve tier draws on. -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: the Kubernetes-native building - blocks the implementation pages rely on throughout. +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: the Kubernetes-native building + blocks the implementation chapters rely on throughout. diff --git a/_docs/01-concepts.md b/_docs/01-concepts.md index bac8546..54eb977 100644 --- a/_docs/01-concepts.md +++ b/_docs/01-concepts.md @@ -138,14 +138,14 @@ Kubernetes primitives. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the primary source for the four principles and the +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the primary source for the four principles and the domain-ownership argument this page summarizes. -- *Learning Domain-Driven Design* by Vlad Khononov: the bounded-context thinking +- [*Learning Domain-Driven Design*](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) by Vlad Khononov: the bounded-context thinking behind domain ownership and why a data product maps to a domain, not a table. -- *Implementing Domain-Driven Design* by Vaughn Vernon: a deeper, implementation-level +- [*Implementing Domain-Driven Design*](https://www.informit.com/store/implementing-domain-driven-design-9780133039894) by Vaughn Vernon: a deeper, implementation-level treatment of the same domain boundaries. -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: the operational-versus-analytical data distinction from the systems side. -- *Cloud Native Patterns* by Cornelia Davis: the self-serve platform principle made +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: the self-serve platform principle made concrete in cloud-native infrastructure terms. diff --git a/_docs/01-data-architectures.md b/_docs/01-data-architectures.md index bef28b3..3b22589 100644 --- a/_docs/01-data-architectures.md +++ b/_docs/01-data-architectures.md @@ -237,13 +237,13 @@ the others produces a distributed mess rather than a mesh. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the full argument for why pipelines, warehouses, +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the full argument for why pipelines, warehouses, and lakes hit an organizational ceiling, and what the mesh changes. -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: the systems-level treatment of batch and stream processing, ETL/ELT, and the storage engines behind warehouses and lakes. -- *Cloud Native Anti-Patterns* by Gerald Bachlmayr et al.: common organizational and +- [*Cloud Native Anti-Patterns*](https://www.packtpub.com/en-us/product/cloud-native-anti-patterns-9781836200581) by Gerald Bachlmayr et al.: common organizational and architectural failure modes, including the centralized-ownership trap this chapter describes. -- *Cloud Native Patterns* by Cornelia Davis: the platform-level patterns a self-serve +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: the platform-level patterns a self-serve data platform draws on once the organizational shift is underway. diff --git a/_docs/02-kubernetes-substrate.md b/_docs/02-kubernetes-substrate.md index 68d5787..cdb7bb1 100644 --- a/_docs/02-kubernetes-substrate.md +++ b/_docs/02-kubernetes-substrate.md @@ -146,11 +146,11 @@ is published and reachable. ## For deeper coverage -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: the primitive-by-primitive +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: the primitive-by-primitive treatment (namespaces, operators, CRDs) this chapter's mapping draws on. -- *Platform Engineering on Kubernetes* by Mauricio Salatino: the self-serve platform +- [*Platform Engineering on Kubernetes*](https://www.manning.com/books/platform-engineering-on-kubernetes) by Mauricio Salatino: the self-serve platform principle built out as an operating model, not just a set of operators. -- *Cloud Native Patterns* by Cornelia Davis: the broader cloud-native platform +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: the broader cloud-native platform patterns this final project's shared infrastructure tier follows. - [Kubernetes documentation](https://kubernetes.io/docs/): namespaces, RBAC, CRDs, and admission control, straight from the source. diff --git a/_docs/03-services-and-data-products.md b/_docs/03-services-and-data-products.md index 96914e2..9f73656 100644 --- a/_docs/03-services-and-data-products.md +++ b/_docs/03-services-and-data-products.md @@ -218,8 +218,8 @@ themselves so others can find and trust them: contracts and the catalog. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the architectural quantum and why a data product's boundary should match a service's boundary. -- *Cloud Native Patterns* by Cornelia Davis: packaging and runtime patterns for services that double as data products. -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: container image and workload patterns behind the build-load-deploy sequence. +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the architectural quantum and why a data product's boundary should match a service's boundary. +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: packaging and runtime patterns for services that double as data products. +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: container image and workload patterns behind the build-load-deploy sequence. - [Kubernetes documentation](https://kubernetes.io/docs/): image pull policies and the kubelet's image lifecycle. - [FastAPI](https://fastapi.tiangolo.com/): the framework order-service and its siblings are built on. diff --git a/_docs/04-contracts-and-catalog.md b/_docs/04-contracts-and-catalog.md index c94d662..62bf236 100644 --- a/_docs/04-contracts-and-catalog.md +++ b/_docs/04-contracts-and-catalog.md @@ -129,7 +129,7 @@ and the asynchronous event backbone. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: data-as-a-product and federated computational governance, the two principles this chapter makes operational. -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris Riccomini: schema evolution and the compatibility guarantees a registry enforces. -- *Cloud Native Anti-Patterns* by Gerald Bachlmayr et al.: the proxy anti-pattern a mesh degrades into without a usable catalog. +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: data-as-a-product and federated computational governance, the two principles this chapter makes operational. +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: schema evolution and the compatibility guarantees a registry enforces. +- [*Cloud Native Anti-Patterns*](https://www.packtpub.com/en-us/product/cloud-native-anti-patterns-9781836200581) by Gerald Bachlmayr et al.: the proxy anti-pattern a mesh degrades into without a usable catalog. - Apicurio Registry documentation: contract versioning and compatibility rules across schemas, Protobuf, OpenAPI, and GraphQL SDL. diff --git a/_docs/05-data-planes.md b/_docs/05-data-planes.md index 4a8cf94..4fce7f0 100644 --- a/_docs/05-data-planes.md +++ b/_docs/05-data-planes.md @@ -134,8 +134,8 @@ the consumers depending on it. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: polyglot access and the synchronous/asynchronous planes a mesh runs on. -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris Riccomini: event-driven architecture and the derived-data reasoning behind the backbone. -- *Cloud Native Patterns* by Cornelia Davis: composing services at the edge versus internally. +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: polyglot access and the synchronous/asynchronous planes a mesh runs on. +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: event-driven architecture and the derived-data reasoning behind the backbone. +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: composing services at the edge versus internally. - [grpc.io documentation](https://grpc.io/docs/): gRPC for internal, low-latency service-to-service calls. - [Strawberry GraphQL](https://strawberry.rocks/): the library behind the gateway's composed graph. diff --git a/_docs/06-progressive-delivery-mtls.md b/_docs/06-progressive-delivery-mtls.md index 1537091..2b1035e 100644 --- a/_docs/06-progressive-delivery-mtls.md +++ b/_docs/06-progressive-delivery-mtls.md @@ -138,7 +138,7 @@ match demand, including down to zero, and recovering when things fail. ## For deeper coverage - [Istio documentation](https://istio.io/latest/docs/): `DestinationRule`, `VirtualService`, `Gateway`, and automatic mutual TLS between sidecars. -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: the Sidecar pattern and the trade-offs of attaching one to every workload. -- *Platform Engineering on Kubernetes* by Mauricio Salatino: treating mesh injection as a platform policy decision rather than a blanket default. -- *GitOps and Kubernetes* by Billy Yuen et al.: progressive delivery workflows for shifting traffic between versions. -- *Cloud Native Anti-Patterns* by Gerald Bachlmayr et al.: the failure modes of meshing workloads that don't belong in the mesh. +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: the Sidecar pattern and the trade-offs of attaching one to every workload. +- [*Platform Engineering on Kubernetes*](https://www.manning.com/books/platform-engineering-on-kubernetes) by Mauricio Salatino: treating mesh injection as a platform policy decision rather than a blanket default. +- [*GitOps and Kubernetes*](https://www.manning.com/books/gitops-and-kubernetes) by Billy Yuen et al.: progressive delivery workflows for shifting traffic between versions. +- [*Cloud Native Anti-Patterns*](https://www.packtpub.com/en-us/product/cloud-native-anti-patterns-9781836200581) by Gerald Bachlmayr et al.: the failure modes of meshing workloads that don't belong in the mesh. diff --git a/_docs/07-elastic-and-resilient.md b/_docs/07-elastic-and-resilient.md index de4ef27..6227661 100644 --- a/_docs/07-elastic-and-resilient.md +++ b/_docs/07-elastic-and-resilient.md @@ -130,7 +130,7 @@ products. ## For deeper coverage -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: autoscaling and self-healing patterns on Kubernetes. -- *Cloud Native Patterns* by Cornelia Davis: elasticity and recoverability as platform-provided properties. -- *Platform Engineering on Kubernetes* by Mauricio Salatino: self-serve platform capabilities and what domains should and shouldn't operate themselves. +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: autoscaling and self-healing patterns on Kubernetes. +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: elasticity and recoverability as platform-provided properties. +- [*Platform Engineering on Kubernetes*](https://www.manning.com/books/platform-engineering-on-kubernetes) by Mauricio Salatino: self-serve platform capabilities and what domains should and shouldn't operate themselves. - [KEDA documentation](https://keda.sh/docs/): scalers, `ScaledObject`s, and the HTTP add-on used in this chapter. diff --git a/_docs/08-observability.md b/_docs/08-observability.md index 4aac032..417de53 100644 --- a/_docs/08-observability.md +++ b/_docs/08-observability.md @@ -136,7 +136,7 @@ sound. ## For deeper coverage -- *Designing Data-Intensive Applications, 2nd ed.* by Martin Kleppmann & Chris Riccomini: reasoning about the behavior of distributed systems built from independently-owned parts. +- [*Designing Data-Intensive Applications, 2nd ed.*](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) by Martin Kleppmann & Chris Riccomini: reasoning about the behavior of distributed systems built from independently-owned parts. - [OpenTelemetry documentation](https://opentelemetry.io/docs/): the metrics/traces/logs signal model this chapter applies to a mesh. - [Grafana documentation](https://grafana.com/docs/): Tempo for traces, Mimir/Prometheus for metrics, and correlating the two. -- *Cloud Native Patterns* by Cornelia Davis: observability as a platform-provided concern rather than a per-service add-on. +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: observability as a platform-provided concern rather than a per-service add-on. diff --git a/_docs/09-anti-patterns.md b/_docs/09-anti-patterns.md index c41b96b..e4af841 100644 --- a/_docs/09-anti-patterns.md +++ b/_docs/09-anti-patterns.md @@ -205,7 +205,7 @@ single-node cluster rather than to data mesh as an idea. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the four principles and the failure modes that appear when each is skipped. -- *Cloud Native Anti-Patterns* by Gerald Bachlmayr et al.: recognizable failure shapes in cloud-native platform adoption generally. -- *Learning Domain-Driven Design* by Vlad Khononov: bounded contexts and why fuzzy domain boundaries cascade into mesh failures. -- *Implementing Domain-Driven Design* by Vaughn Vernon: the ownership and autonomy a real data product needs to avoid the "dumb data product" trap. +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the four principles and the failure modes that appear when each is skipped. +- [*Cloud Native Anti-Patterns*](https://www.packtpub.com/en-us/product/cloud-native-anti-patterns-9781836200581) by Gerald Bachlmayr et al.: recognizable failure shapes in cloud-native platform adoption generally. +- [*Learning Domain-Driven Design*](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) by Vlad Khononov: bounded contexts and why fuzzy domain boundaries cascade into mesh failures. +- [*Implementing Domain-Driven Design*](https://www.informit.com/store/implementing-domain-driven-design-9780133039894) by Vaughn Vernon: the ownership and autonomy a real data product needs to avoid the "dumb data product" trap. diff --git a/_docs/10-summary.md b/_docs/10-summary.md index 7091f0d..d8d0fd7 100644 --- a/_docs/10-summary.md +++ b/_docs/10-summary.md @@ -264,7 +264,7 @@ explicit enough about its choices to be portable. ## For deeper coverage -- *Data Mesh* by Zhamak Dehghani: the four principles this closing page reorganizes the reference by. -- *Cloud Native Patterns* by Cornelia Davis: the platform patterns (self-serve, federated governance) behind this summary's implementation pieces. -- *Kubernetes Patterns* by Bilgin Ibryam & Roland Huß: the operator and CRD shapes that make each principle self-serve. -- *GitOps and Kubernetes* by Billy Yuen et al.: reproducing the whole mesh from a Git repository, the practice Principle 03's GitOps piece rests on. +- [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) by Zhamak Dehghani: the four principles this closing page reorganizes the reference by. +- [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) by Cornelia Davis: the platform patterns (self-serve, federated governance) behind this summary's implementation pieces. +- [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) by Bilgin Ibryam & Roland Huß: the operator and CRD shapes that make each principle self-serve. +- [*GitOps and Kubernetes*](https://www.manning.com/books/gitops-and-kubernetes) by Billy Yuen et al.: reproducing the whole mesh from a Git repository, the practice Principle 03's GitOps piece rests on. diff --git a/_docs/11-running-on-openshift-crc.md b/_docs/11-running-on-openshift-crc.md index e05d545..ee1f45c 100644 --- a/_docs/11-running-on-openshift-crc.md +++ b/_docs/11-running-on-openshift-crc.md @@ -839,4 +839,4 @@ top of a resized instance and re-capturing the same evidence files under - [Strimzi documentation](https://strimzi.io/documentation/): the Kafka-on-Kubernetes operator model that AMQ Streams, referenced throughout this appendix, is built on. - [Istio documentation](https://istio.io/latest/docs/): mTLS and the `VirtualService`/`DestinationRule` traffic shaping the platform tier's mesh section uses. - [KEDA documentation](https://keda.sh/docs/): the upstream API the Custom Metrics Autoscaler operator packages. -- *Platform Engineering on Kubernetes* by Mauricio Salatino: operator-based platform capabilities (OperatorHub/OLM) and SCCs as policy, the pattern this appendix's chart is built around. +- [*Platform Engineering on Kubernetes*](https://www.manning.com/books/platform-engineering-on-kubernetes) by Mauricio Salatino: operator-based platform capabilities (OperatorHub/OLM) and SCCs as policy, the pattern this appendix's chart is built around. diff --git a/_includes/header.html b/_includes/header.html index 79303bb..4b92fee 100644 --- a/_includes/header.html +++ b/_includes/header.html @@ -6,10 +6,12 @@ diff --git a/bibliography.md b/bibliography.md new file mode 100644 index 0000000..d845f2b --- /dev/null +++ b/bibliography.md @@ -0,0 +1,49 @@ +--- +layout: default +title: "Bibliography" +permalink: /bibliography/ +description: "The reference works this site's coverage and rigor draw on. Nothing here is reproduced from them." +--- + +# Bibliography + +This reference's chapter arc and its level of rigor draw on a short list of books +and primary documentation covering data mesh and the cloud-native platform it runs +on. They're reference works, not sources. No text or code from any of them is +reproduced in these chapters or the runnable examples. When a chapter is useful to +you, these are where to go deeper. + +## Books + +| Title | Author(s) | Publisher | Focus | +|---|---|---|---| +| [*Data Mesh*](https://www.oreilly.com/library/view/data-mesh/9781492092384/) | Zhamak Dehghani | O'Reilly | The four principles, the data product as architectural quantum, federated governance | +| [*Designing Data-Intensive Applications*, 2nd ed.](https://www.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/) | Martin Kleppmann & Chris Riccomini | O'Reilly | Reasoning about distributed systems built from independently-owned parts | +| [*Cloud Native Patterns*](https://www.manning.com/books/cloud-native-patterns) | Cornelia Davis | Manning | Packaging, runtime, and platform-provided concerns for services that double as data products | +| [*Cloud Native Anti-Patterns*](https://www.packtpub.com/en-us/product/cloud-native-anti-patterns-9781836200581) | Gerald Bachlmayr, Aiden Ziegelaar, Alan Blockley & Bojan Zivic | Packt | The failure modes the anti-patterns chapter maps | +| [*Kubernetes Patterns*](https://www.oreilly.com/library/view/-/9781098131678/) | Bilgin Ibryam & Roland Huß | O'Reilly | Container image and workload patterns behind the build, load, and deploy sequence | +| [*Platform Engineering on Kubernetes*](https://www.manning.com/books/platform-engineering-on-kubernetes) | Mauricio Salatino | Manning | The self-serve platform principle built out as an operating model | +| [*GitOps and Kubernetes*](https://www.manning.com/books/gitops-and-kubernetes) | Billy Yuen, Alexander Matyushentsev, Todd Ekenstam & Jesse Suen | Manning | Declarative delivery for the platform tier | +| [*Learning Domain-Driven Design*](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) | Vlad Khononov | O'Reilly | Bounded contexts and domain ownership behind the service boundaries | +| [*Implementing Domain-Driven Design*](https://www.informit.com/store/implementing-domain-driven-design-9780133039894) | Vaughn Vernon | Addison-Wesley | Aggregates, events, and context mapping in code | + +## Primary documentation + +| Project | Link | Used for | +|---|---|---| +| FastAPI | [fastapi.tiangolo.com](https://fastapi.tiangolo.com/) | The REST framework the services are built on | +| Strawberry GraphQL | [strawberry.rocks](https://strawberry.rocks/) | The GraphQL gateway's schema-first API | +| gRPC (Python) | [grpc.io/docs](https://grpc.io/docs/languages/python/) | The inventory-service synchronous contract | +| OpenTelemetry | [opentelemetry.io/docs](https://opentelemetry.io/docs/) | The metrics, traces, and logs signal model | +| Grafana | [grafana.com/docs](https://grafana.com/docs/) | Tempo for traces, Mimir/Prometheus for metrics | +| Apicurio Registry | [apicur.io/registry/docs](https://www.apicur.io/registry/docs/) | The schema registry for Avro contracts | +| OpenMetadata | [docs.open-metadata.org](https://docs.open-metadata.org/) | The catalog, discovery, and lineage | +| Istio | [istio.io/latest/docs](https://istio.io/latest/docs/) | The service mesh, mTLS, and progressive delivery | +| KEDA | [keda.sh/docs](https://keda.sh/docs/) | Event-driven and lag-based autoscaling | +| Strimzi | [strimzi.io/docs](https://strimzi.io/docs/) | The Kafka operator for the async backbone | +| Kubernetes | [kubernetes.io/docs](https://kubernetes.io/docs/) | Namespaces, RBAC, CRDs, admission control | +| minikube | [minikube.sigs.k8s.io/docs](https://minikube.sigs.k8s.io/docs/) | The local cluster, docker driver, containerd runtime | +| OpenShift Local (CRC) | [crc.dev](https://crc.dev/) | The OpenShift appendix | + +These titles inform this site's coverage and rigor only. Nothing in these chapters +or the runnable examples copies text or code from them. From 58a1709ea6b3862f7f8c2c8f2c088454f6f77aa1 Mon Sep 17 00:00:00 2001 From: PatternCatalyst Date: Thu, 22 Oct 2026 21:18:04 -0400 Subject: [PATCH 2/2] docs: remove internal tracking codes (DRA-*) and _plans references from reader-facing chapters --- _docs/06-progressive-delivery-mtls.md | 2 +- _docs/10-summary.md | 6 +----- _docs/11-running-on-openshift-crc.md | 8 ++++---- 3 files changed, 6 insertions(+), 10 deletions(-) diff --git a/_docs/06-progressive-delivery-mtls.md b/_docs/06-progressive-delivery-mtls.md index 2b1035e..8c28fd4 100644 --- a/_docs/06-progressive-delivery-mtls.md +++ b/_docs/06-progressive-delivery-mtls.md @@ -50,7 +50,7 @@ environment toggle and a different `version` label, rather than two images from commits. That keeps the demo focused on the traffic-management mechanism rather than an image pipeline, and the Istio mechanics are identical either way. And traffic enters through the ingress gateway (reached on its NodePort, published to -127.0.0.1:8088 when the profile is created, DRA-017) rather than from a meshed client, +127.0.0.1:8088 when the profile is created) rather than from a meshed client, so no client needs to join the mesh for the canary to work. This was verified end to end: with the split set to 90/10, a run of 100 requests diff --git a/_docs/10-summary.md b/_docs/10-summary.md index d8d0fd7..5a636fd 100644 --- a/_docs/10-summary.md +++ b/_docs/10-summary.md @@ -247,11 +247,7 @@ your own data mesh on Kubernetes, the pattern is: 2. **Run the example tree** to see the cross-product behaviors live: the trace tree across three products, the canary contract evolution under live traffic, the autoscaler reacting to a Kafka backlog. -3. **Use the decision log** at `_plans/archive/final-project-decisions.md` - to understand the *reasoning* for each implementation choice, not - just the choice itself. The rejected alternatives are where the - institutional memory of the build lives. -4. **Adapt to your runtime** by swapping the substitutions: namespace +3. **Adapt to your runtime** by swapping the substitutions: namespace for Project, PodSecurity for SCCs, `helm install` for OperatorHub. The reference's chart structure is set up to make this tractable; the bootstrap script is one of the natural places to fork. diff --git a/_docs/11-running-on-openshift-crc.md b/_docs/11-running-on-openshift-crc.md index ee1f45c..8ef8aff 100644 --- a/_docs/11-running-on-openshift-crc.md +++ b/_docs/11-running-on-openshift-crc.md @@ -84,7 +84,7 @@ This appendix uses podman (and `oc`) on the host to build and push to the integr This is the sizing the **full platform tier** actually needs: Istio sidecars on every app pod, the otel-lgtm observability backend, KEDA's operands, and Prefect's and OpenMetadata's dependencies, all on top of the live core (see "The full platform - tier, live" below, and DRA-008 in `_plans/decisions.md`). If you only want the **live + tier, live" below). If you only want the **live core** (the seven services, Postgres, Kafka, and Apicurio, with none of the platform tier applied), the smaller footprint this chart originally shipped with still works: @@ -787,7 +787,7 @@ endpoint. The full capture is committed at cooldown once the backlog cleared. (`examples/lgtm-datamesh/openshift/evidence/keda-verification.txt`) - **Observability**: grafana/otel-lgtm all-in-one under the `anyuid` SCC, root with no - seccomp profile or capabilities (see DRA-016): Grafana reports `"database": "ok"` + seccomp profile or capabilities: Grafana reports `"database": "ok"` through its Route, and Tempo is ingesting per-service traces from `graphql-gateway`, `order-service`, `inventory-service`, and `notification-service`. (`examples/lgtm-datamesh/openshift/evidence/observability-verification.txt`) @@ -815,8 +815,8 @@ endpoint. The full capture is committed at (`postgres:16-alpine`, `kafka:3.8.0`, Apicurio 3.2.4, otel-lgtm 0.8.1, Prefect `3-latest`, OpenMetadata 1.12.8). On 2026-10-09 the pins moved to the newest stable tags (`postgres:18.6-alpine`, `kafka:4.3.1`, Apicurio 3.3.3, otel-lgtm - 0.36.0, Prefect 3.8.8-python3.14, OpenMetadata 2.0.5 with OpenSearch 3.4.0; - DRA-020); they have + 0.36.0, Prefect 3.8.8-python3.14, OpenMetadata 2.0.5 with OpenSearch 3.4.0); + they have not been run on CRC yet. Postgres 18 cannot open a 16 data directory, so an existing install needs a fresh PVC. The operator CSVs (Service Mesh 3, Custom Metrics Autoscaler) and the OSSM3 Istio version can't be resolved without a