Category
Pragmatic software architecture: decisions, trade-offs and patterns that scale.
Kubernetes 1.35 GA consolidates three releases of work: native sidecars with full lifecycle management, generalised DRA for FPGAs and NPUs, and a scheduler that cuts resource waste by 15-25% in heterogeneous clusters. An operations-side balance sheet: what to enable now, what to watch before migrating, and what path to follow from 1.30.
The Model Context Protocol, proposed by Anthropic in late 2024 and adopted through 2025-2026 by Anthropic, OpenAI, Google, and the open-source community, already has proven operational patterns: separating generic servers from custom ones, explicit per-tool policies, credentials kept outside the model, prefixed composition, and contract tests. This is the state of the art in 2026.
Hybrid RAG in 2026 combines dense and lexical search fused with RRF, cross-encoder reranking over the top-50 candidates, structure-aware chunking, and continuous evaluation with Ragas or TruLens. It is the pattern that survives in serious production systems three years after the initial embeddings boom.
After years of promising an open lakehouse, Apache Iceberg with REST catalogs plus dbt on top has jelled in 2025 into the reference stack. I break down what it solves, where it still hurts, and why the clean split between table, engine and transformation matters more than it looks.
The term Agent OS has spent a year gaining traction across research and product circles. It describes a layer that goes well beyond an agent library: request scheduling, context management, persistent memory, and isolation. A look at the real state of that concept.
Kubernetes 1.34 ships with Dynamic Resource Allocation (DRA) graduating to stable, scheduler improvements, and CEL-based mutating admission policies that replace webhooks. A practical rundown of what is safe to upgrade now, what can wait, and what actually changes for teams running production clusters.
Redis 8.2 ships vector search as a native data type. The real question is whether it replaces a dedicated engine like Qdrant, Weaviate, or pgvector on workloads with millions of vectors and tight latency budgets, or only works as a bonus on top of the cache you already run.
Kubernetes 1.32 Penelope shipped in December and has been running in clusters for several months. It is a good time to look at which changes have aged well, which created extra work, and what lessons to carry into the jump to 1.33.
cAdvisor is still embedded in kubelet and covers surface metrics, but falls short for production Kubernetes. The modern minimum stack pairs it with kube-state-metrics, node-exporter, Prometheus, and Grafana as a base, eBPF for deep network and syscall visibility, and OpenTelemetry for application context.
Cilium Service Mesh replaces Istio or Linkerd sidecars with eBPF in the kernel: it handles policy, WireGuard encryption, and Hubble observability without a per-pod proxy, cutting memory overhead from roughly 100 GB to about 5 GB in a 100-node cluster. It suits large clusters with teams comfortable with eBPF.
An Internal Developer Platform (IDP) centralises service discovery, provisioning and observability in a single portal, so developers stop depending on stale wikis and Slack channels. Backstage, Port and Cortex dominate the market: Backstage is open source with a dedicated team, Port is fast low-code SaaS, and Cortex focuses on scorecards for measurable technical discipline based on team size.
SQLite and DuckDB are both embedded databases that work from a single file, no server needed. Their architecture differs: SQLite stores rows and excels at short transactions (OLTP); DuckDB stores columns and shines at large-scale analytics (OLAP). Choosing the right one, or combining both, delivers a genuine technical edge.
A service mesh adds mTLS, uniform observability, and traffic management between microservices without modifying application code. The ecosystem has consolidated: Istio is the most complete and complex, Linkerd prioritises simplicity with Rust proxies, and Cilium delivers sidecarless service mesh via eBPF.
Kubernetes 1.27 ("Chill Vibes"), released in April 2023, makes SeccompDefault stable so pods get safer syscall defaults automatically, moves KMS v2 to beta with rotatable encryption keys for etcd secrets, and stabilises scheduling gates. It also removes PodSecurityPolicy for good: without migrating to Pod Security Admission first, the upgrade is blocked entirely.
Apache Kafka has consolidated in 2023 as the enterprise event backbone thanks to KRaft, now GA and removing the ZooKeeper dependency. The most mature patterns are CDC with Debezium, event sourcing, and stream processing with Kafka Streams or Flink, while Redpanda and Pulsar compete as real alternatives depending on the case.
OpenTelemetry is the CNCF project, graduated in May 2026, that unifies logs, metrics, and traces under one SDK and the OTLP protocol, without locking you into a single backend. Traces have been stable since 2021 and metrics since 2023; logs are still maturing, but already worth adopting on new projects.
Cilium replaces iptables with eBPF programs loaded directly into the Linux kernel, substituting O(n) linear chains with O(1) hash lookups. Documented benchmarks show up to 50% lower p95 latency, 2-3x more throughput, and 70% less kernel CPU in large Kubernetes clusters.
Kafka gets the headlines as the byword for modern messaging, but RabbitMQ remains the better choice for task queues with retries, asynchronous RPC, and pub/sub with complex routing. This guide compares both against NATS, walks through classic patterns and production mistakes, and helps you decide based on the actual use case rather than the trend.
Kubernetes 1.28 introduces native sidecar containers in alpha via KEP-753: adding restartPolicy Always to initContainers ensures correct startup and shutdown ordering. It fixes Jobs that never terminate. Istio, Linkerd, and observability agents like Fluent Bit are the primary beneficiaries.
Choose modular architecture when your team has fewer than ten people and ships the system as a single unit; choose microservices when separate teams need to deploy independently or when specific components require very different scaling, in exchange for higher operational complexity.
