The 2020 book had a chapter on Blockchain. It built a private Ethereum network on Kubernetes, miners and all, and it was one of the more involved chapters in the book. This rebuild does not have that chapter, and rather than quietly drop it, I want to account for why, because the reasons are a useful lesson in betting on technology and in telling the difference between a capability and a fashion.
This series rebuilds my 2020 Apress book, Advanced Platform Development with Kubernetes, for 2026. The approach behind it comes from building and running data platforms in production for more than twenty years.
§The 2020 Bet
In 2020, blockchain was on every enterprise roadmap and in every innovation budget. A book about building an advanced platform that ignored it would have looked incomplete, and the technology was a genuinely interesting thing to run on Kubernetes. So the chapter built a private Ethereum proof-of-work network: bootnodes, a registrar to discover them, mining nodes, transaction nodes, a stats dashboard, and a Jupyter environment talking to it all through web3.
Here is the part I will give the 2020 book full credit for: it never claimed blockchain needed Kubernetes. The chapter’s own summary said, in as many words, that this was an example where the technology itself did not require any of the functionality Kubernetes provides. The point of the chapter was to demonstrate that the platform could glue together wildly different workloads, a blockchain, a serverless function, a notebook, into one system. Blockchain was the demonstration, not an endorsement of it. That candor held up better than the technology did.
§The Reckoning
What did not hold up was the stack underneath it, and the way it failed is instructive. The chapter ran Ethereum in proof-of-work mode, with mining nodes generating a DAG and racing to produce blocks. In September 2022, Ethereum’s Merge eliminated proof-of-work entirely and moved to proof-of-stake. The entire mining model the chapter taught is gone from real Ethereum.
It gets more thorough than that. The chapter leaned on third-party pieces, a bootnode registrar and a stats dashboard, that came out of a Microsoft Azure blockchain effort. Azure Blockchain Service was shut down in September 2021. Those images are abandonware. The Kubernetes Ingress API the chapter used was removed from Kubernetes in 1.22, so the manifests would not even apply to a current cluster. This is the most dated chapter in the book: its consensus model was invalidated, its supporting tools were abandoned, and its Kubernetes resources were removed, all within a few years of publication. Updating it is not worth the effort, because there is nothing underneath worth standing back up.
§What Was Actually Valuable
The chapter touched one valuable idea worth separating from the technology that carried it. The durable need is tamper-evidence: a record you can trust has not been quietly altered, an append-only history, the ability to prove where a piece of data came from and who changed it. Audit trails, data lineage, and supply-chain integrity matter more every year.
The mistake of the era was thinking that need required a blockchain. It does not, and it almost never did. A blockchain is an expensive way to get tamper-evidence in the specific case where you do not trust any single party to hold the record, the trustless, decentralized case. Inside your own platform, where you do control the systems, you get the same tamper-evidence and provenance from simpler tools.
§Where Provenance Lives in 2026
The tamper-evidence and provenance the blockchain chapter gestured at are not absent from this rebuild; they are spread through it, done by tools built for the job. The DataHub catalog records column-level lineage, the verifiable history of where every number came from and what transformed it, which is exactly the provenance question, answered for the data platform. The Iceberg lakehouse keeps an immutable snapshot of every table on every write, so the history of a table is an append-only sequence you can query and time-travel through, an audit log by construction. Content-addressed storage gives you integrity by identity, where the address of an object is derived from its contents, so a changed object is a different object.
And for the supply chain, the integrity question for the software itself, the answer is cryptographic signing and attestation: cosign signatures and SBOMs, which I have written about and which the platform’s CI produces. That is real tamper-evidence, a signed, verifiable claim about what an artifact is and where it came from, with none of the cost of running a chain. The need survived, but the blockchain was never the right way to meet it inside a platform you own.
§The Slot Goes to AI
The energy the 2020 book spent demonstrating that Kubernetes could glue together exotic workloads is, in 2026, spent on the workload that pays that demonstration off: AI. Giving a frontier model governed access to the whole platform, the MCP gateway that caps this series, is the modern version of “look what this platform can connect,” except this time it is a capability that changes the economics of running everything else rather than a fashion. The chapter that taught a private Ethereum network became the chapters that make the platform legible to AI.
§What You Have
The blockchain chapter is cut because its technology was invalidated, its tools abandoned, and its real value, tamper-evidence and provenance, is better delivered by lineage, immutable snapshots, content addressing, and signed attestation, all already in this platform. Betting on a fashion is how you end up maintaining abandonware. Betting on the underlying need, in this case provenance, is how you stay current, and the platform has it.
The series has two pieces of icing left, both about reaching beyond a single cluster: a hybrid Kubernetes cluster spanning clouds and your own hardware, and the on-prem GPUs that make self-hosted AI affordable.