Platform

TL;DR The self-hosted vs managed decision in 2026 is genuinely different from the same decision in 2022. The math has shifted in three directions: cloud egress costs, AI workload economics, and self-hosted tooling maturity. Managed remains the right default for most teams. The thing that has changed is that the threshold at which self-hosting becomes worth considering has dropped. Workloads that were obviously managed in 2022 are genuine 50/50 calls in 2026. The most important shift is that self-hosting is no longer synonymous with on-premises. Modern self-hosting often means renting bare-metal in a colocation, running your own clusters in a hyperscaler, or using sovereign cloud providers - all with different economics. For specific categories - AI inference at scale, data egress-heavy workloads, predictable steady-state compute, regulated environments - self-hosting now wins on cost more often than people assume. The honest framing: managed is the right default; self-hosting is the right minority case; the minority is bigger than it used to be. Why This Decision Got Harder For most of the 2010s the answer was easy. Managed services were cheaper than self-hosting once you priced in operational overhead. The cloud providers competed aggressively. Self-hosting was for the regulated, the eccentric, and the very large. ...

TL;DR eBPF is the technology that lets you run safe, sandboxed programs inside the Linux kernel without writing kernel modules. In 2026 it is the foundation under most serious observability, networking, and runtime security tools. The interesting story is not the technology itself - it is the wave of products built on top of it: Cilium for networking, Tetragon for runtime security, Pixie, Parca, and Coroot for observability, plus a long tail of vendor offerings using eBPF under the hood. For platform engineers, eBPF is not “a thing you have to learn to write.” It is a thing you have to know about so you can choose tools intelligently and understand what is happening on your nodes when those tools cause problems. The most important shift eBPF has enabled is observability without instrumentation. You can see what is happening on a system without modifying the application, without restarting it, and with low overhead. That is genuinely new. What eBPF Actually Is eBPF stands for “extended Berkeley Packet Filter,” which is historical and confusing because eBPF has long since outgrown packet filtering. The simple version: ...

TL;DR Kubernetes won the orchestration argument years ago. The question is no longer “should we use Kubernetes.” It is “should this particular team, with this particular workload, with this particular budget, pay the operational tax.” For genuinely large, multi-tenant, multi-region platforms with dedicated infrastructure teams, the answer is still mostly yes. The ecosystem maturity is unmatched and the alternatives lose at scale. For mid-sized engineering organisations, the answer in 2026 is probably not, and increasingly not. Managed serverless, container platforms like Fly and Railway, and the new generation of platform-as-a-service offerings are competitive in ways they were not three years ago. For startups and small teams, the answer is almost always no, and stop pretending otherwise. The honest read in 2026: Kubernetes is the right answer to fewer questions than it used to be, and being honest about that is now a competitive advantage rather than a heresy. How We Got Here Kubernetes was the right idea at the right time. By the late 2010s, every serious engineering team needed an answer to “how do we run containers in production.” Kubernetes provided one, it was open, it was backed by a credible foundation, and the cloud providers all blessed it. Within five years it was the default. Within ten years it was the assumption. ...

Good engineering blogs are one of the cheapest forms of mentorship available. The posts below are from teams and individuals I return to when I want to see how real organisations solve real problems - outages, scaling walls, migrations, and the occasional cultural mistake. Vendor and Platform Blogs These blogs publish architectural deep-dives and reference implementations. They are partly marketing, but the engineering detail is usually genuine. Atlassian DevOps Blog - practitioner posts on pipelines, incident response, and team topology AWS DevOps Blog - pipeline patterns, CDK/CodePipeline how-tos, and multi-account guidance Google Cloud Blog - the SRE-flavoured material that originated at Google Microsoft DevOps Blog - Azure DevOps, GitHub Actions, and developer platform posts GitLab Blog - CI/CD and platform engineering content from the GitLab team HashiCorp Blog - Terraform, Vault, Consul, and Nomad in production Individual and Community Voices Ricard Bejarano - SRE at Cisco with sharp posts on minimal container images and infrastructure hygiene Charity Majors - co-founder of Honeycomb, writing extensively on observability and on-call culture Julia Evans - illustrated explainers on Linux, networking, and debugging fundamentals Gergely Orosz - The Pragmatic Engineer - deep dives into how large engineering organisations actually operate High Scalability - architecture breakdowns of well-known systems SRE-Specific Reading Google SRE Books - the foundational texts on SRE as a discipline Increment Magazine - long-form essays on on-call, incident response, and reliability Everything DevOps (Reddit) - less polished, but a useful pulse on what practitioners are struggling with this week How I Use This List Blog posts age quickly. A Kubernetes best-practices post from 2019 may actively mislead you in 2026. When I read any of these, I check the date first and treat anything older than three years as historical context rather than current guidance. ...