DevOpsLinks

When Moore Met Eroom

Moore's Law shaped modern tech: smaller transistors meant more performance. The same code ran faster on newer machines. For decades, progress was almost automatic. That assumption is now breaking down.

Do you know Eroom's Law?

🤔 Eroom's Law - the inverse of Moore's Law - observes that despite better tools, productivity declines because complexity rises. Each improvement exposes harder problems and increases the effort needed to make progress. That same pattern is now visible in software, infrastructure, and operations:

• In the 1990s, faster CPUs and better compilers delivered real speedups. Systems were simpler. Teams were small. Codebases were manageable.
• In the 2000s, better languages, frameworks, and early cloud VMs made building and shipping software faster. Startups scaled with lean teams.
• In the 2010s, containers, microservices, and serverless improved flexibility and scalability. Products matured, and teams grew alongside them.
• In the 2020s, cloud platforms offer near-infinite primitives, but operating production systems now involves Kubernetes, service meshes, IAM, observability stacks, cost controls, layered security and moore!

More tools = more coupling = more operational overhead. The distinction matters at this scale: Moore's Law works when scale is additive.

Eroom-like dynamics appear when scale becomes multiplicative in complexity. This is where many tech narratives fall short. They announce new tools and promise productivity gains, while hiding or probably ignoring the complexity those tools introduce.

Understanding modern tech now requires systems thinking. Progress is no longer just about adopting new tools. It's about managing complexity today!

Have a great week!
Aymen

From minimal Ubuntu that boots faster with real compliance, to an SRE agent that actually thinks, to the quiet art of keeping secrets out of logs, this one is about speed without shortcuts. If PQC deadlines, IPv4 contortions, bare metal APIs, and resolver quirks are on your mind, the deeper threads below are worth your time.

🐧 Canonical Introduces Minimal Ubuntu Pro: Smaller Images and Secure Cloud Workloads at Scale
📊 Go Developer Survey Is Out: What 5,379 Go Developers Actually Want Next
🔎 How we built an AI SRE agent that investigates like a team of engineers
🔐 Keeping Secrets Out of Logs
🧮 Preparing for Post-Quantum Cryptography
🖧 SSH has no Host header
🛠️ The best tools for bare metal automation that people actually use
🌐 What came first: the CNAME or the A record?

Ship smarter, sleep better.

Cheers!
FAUN.dev() Team

The 2025 Go Developer Survey is in - and AI’s gaining ground. Devs are leaning on it for unit test scaffolding, autocompletion, and similar grunt work. But trust? Still shaky. Quality’s not there yet.

Elsewhere, they’re bumping into old problems: core tools still hard to navigate, non-idiomatic code patterns still causing trouble, and a rising call for clearer best practices and better trust signals in modules.

Canonical dropped Minimal Ubuntu Pro onto AWS, Azure, and Google Cloud. Half the size. Boots 40% faster. Baked in with Ubuntu Pro-level hardening.

You still get long-term CVE patching, FIPS 140-3 crypto, and compliance checks for FedRAMP, NIST, HIPAA - just in a stripped-down shell.

System shift: Leaner images with enterprise teeth. It’s the new normal for CI/CD and DevSecOps pipelines chasing speed and compliance in one hit.

Bare metal ops aren’t what they used to be. The game’s gone full stack: API-driven provisioning, declarative workflows, and config convergence now run the show.

Tools like MAAS, Foreman, Ironic, and Tinkerbell treat physical servers as programmable units. Real hardware, real APIs. Meanwhile, Kubernetes-native models bring physical gear into the cluster fold using Custom Resources (see: Bare Metal Operator). It’s a weirdly elegant mashup - metal meets manifest.

A new writeup lays out a layered plan to keep secrets out of logs, no silver bullets here, just ten solid "lead bullets" that actually stack. Think of it as defense in depth for log hygiene.

Highlights include:
Type-safe domain primitives for secrets,
Taint-based static analysis,
Read-once secret wrappers,
and smart log preprocessors (like Vector) that redact and sample before anything hits disk.

A dev built a custom SSH proxy that punches through IPv4 limits without handing out public IPs like candy. Their trick: shared IPv4s with per-user relative IP mapping.

It maps incoming SSH traffic to the right VM using the source IP and public key combo. No Host header? No problem. They sidestep that hole cleanly.

A recent change to 1.1.1.1 accidentally altered the order of CNAME records in DNS responses, breaking resolution for some clients. This post explores the technical root cause, examines the source code of affected resolvers, and dives into the inherent ambiguities of the DNS RFCs.

NIST locked in its Post-Quantum Cryptography (PQC) standards in August 2024. The countdown’s on: U.S. federal systems need to make the leap by 2035.

Wiz jumped early with a PQC Security Framework. It scans for shaky encryption, maps your crypto assets, and flags what’s PQC-ready, all cloud-wide, using hybrid cryptography and metadata sleuthing.

Datadog just dropped Bits AI SRE, an autonomous agent that thinks more like an SRE than a chatbot. It doesn't just regurgitate summaries - it investigates. It builds hypotheses, tests them against telemetry, and chases down actual root causes.

Older tools leaned hard on LLMs to summarize alerts. That got noisy fast. Bits AI SRE flips the script. It crawls through evidence step by step, like a real engineer, connecting dots across services to isolate the real issue.

Comprehensive Python Cheatsheet

Darwin/macOS emulation layer for Linux

A curated, actionable checklist for securing CI/CD pipelines and Kubernetes clusters in 2026.

Real-time monitoring, slowlog analysis, and audit trails for Valkey and Redis

Lightweight server monitoring hub with historical data, docker stats, and alerts.

Did you know that etcd v3’s default quota-backend-bytes is just 2 GB, and once any member hits that limit it starts returning “etcdserver: mvcc: database space exceeded”? etcd uses an MVCC history for every change, so frequent object churn inflates storage even if your current keyspace is small, and without compaction the database keeps eating space. Simply compacting removes old revisions, but doesn’t shrink the file on disk; only running etcdctl compact then etcdctl defrag frees space and clears the quota alarm so writes can proceed. You can avoid outages by enabling auto compaction (--auto-compaction-retention) or increasing the quota, but bigger quotas also slow snapshots and restarts due to larger on-disk files.

"In cloud systems, the bottleneck isn't compute; it's quotas, IAM edges, and backoffs that synchronize. DevOps distributes responsibility until the incident picks a single owner: whoever holds the pager and the budget. SRE isn't about preventing failure; it's about choosing which failures to fund and which to tolerate."
SenseiOne

Quietly build the habit of tracing every recurring incident back to one specific decision you could have made earlier in the lifecycle, then update a concrete artifact you own (a runbook entry, an alert rule, a Terraform module) so you never rely on memory alone next time. Over years of rotations, this slow accretion of small, written corrections is what separates people who’ve simply "seen a lot" from people whose systems actually stop failing in the same way twice.

This week, we’re highlighting Yusuf Aytaş, Senior Engineering Leader at Workday, who has led SRE, data science and engineering, backend, and platform engineering teams across EMEA, APAC, and North America. He writes the Software Engineering Handbook and lectures at Dublin Business School, distilling lessons from running systems on AWS, GCP, Azure, Kubernetes, Kafka, Spark, PostgreSQL, and Cassandra.