Glauber Costa

🚀 Bare metal is making a serious comeback, especially for Kubernetes! But when is ditching the VMs for raw hardware really the right move for your K8s clusters? 🤔 It's a hot topic, and many are surprised by the clear advantages in specific scenarios. If you're nodding along, here’s a quick breakdown: 🎯 𝗕𝗮𝗿𝗲 𝗠𝗲𝘁𝗮𝗹 𝗦𝗵𝗶𝗻𝗲𝘀 𝗪𝗵𝗲𝗻: → 𝗠𝗮𝘅𝗶𝗺𝘂𝗺 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗶𝘀 𝗮 𝗠𝘂𝘀𝘁: Direct hardware access means minimal hypervisor overhead and no noisy neighbors hogging resources. Your critical tasks get full infrastructure capacity. → 𝗬𝗼𝘂 𝗡𝗲𝗲𝗱 𝗟𝗼𝘁𝘀 𝗼𝗳 𝗜𝗻𝗳𝗿𝗮 𝗙𝗹𝗲𝘅𝗶𝗯𝗶𝗹𝗶𝘁𝘆: Got specialized, too new, or too old hardware? Bare metal handles it. Access different kernels and fully leverage unique hardware capabilities (like specific network cards) → 𝗬𝗼𝘂 𝗪𝗮𝗻𝘁 𝗙𝘂𝗹𝗹 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗼𝗳 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Single tenancy reduces the attack surface. No hypervisor vulnerabilities to worry about, plus you control kernel updates, encryption, and can use hardening frameworks like SELinux/AppArmor. → 𝗬𝗼𝘂 𝗡𝗲𝗲𝗱 𝗠𝗮𝘅𝗶𝗺𝘂𝗺 𝗡𝗲𝘁𝘄𝗼𝗿𝗸 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲: Fewer abstractions mean better network speeds. Tools like CNI, flannel, and Calico make setup and routing smoother, and troubleshooting is often simpler. → 𝗬𝗼𝘂 𝗪𝗮𝗻𝘁 𝘁𝗼 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗖𝗼𝘀𝘁𝘀: Optimal resource utilization and predictable scaling costs can lead to significant savings-up to 30% TCO reduction in some cases! Plus, no hypervisor licensing fees. 🚧 𝗕𝘂𝘁, 𝗜𝘁'𝘀 𝗡𝗼𝘁 𝗔𝗹𝘄𝗮𝘆𝘀 𝗦𝗺𝗼𝗼𝘁𝗵 𝗦𝗮𝗶𝗹𝗶𝗻𝗴. 𝗧𝗵𝗲 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀: → 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗖𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆: Forget "click-and-go." Provisioning, updates, networking, DNS, storage, and scaling are all on you. OS patching and certificate management? Your responsibility. → 𝗢𝗽𝘁𝗶𝗼𝗻𝗮𝗹𝗶𝘁𝘆 𝗢𝘃𝗲𝗿𝗹𝗼𝗮𝗱: The "blank slate" can be daunting. Choosing and ensuring compatibility for OS, interfaces, and hardening solutions requires careful planning and dedicated team resources. Choosing bare metal for K8s isn't a decision to take lightly, but for the right workloads, the benefits are undeniable! Learn more in my post here: https://lnkd.in/gqFduUsN

24

Raw telemetry can overwhelm more than it informs. That’s why organizations are leaning on PacketRanger to make SNMP and NetFlow practical, cost-effective, and compatible with modern monitoring tools. Three ways PacketRanger helps: 🔹 Filter Before You Forward – Keep dashboards meaningful and reduce data costs. 🔹 Translate for Compatibility – Convert SNMP traps into syslog for SIEMs and aggregators. 🔹 Spot Anomalies at the Source – Catch misconfigurations and outages in real time. When SNMP and NetFlow are implemented intentionally, they become powerful tools for clarity and control.

3

So the first time I saw 'Diskless Kafka' advertised at a conference I was suspicious. My mind went straight to 'Serverless' Compute... which despite the name seemed to require a whole lot of servers. Yes, I know, just not ones you manage yourself. But still. Well I've finally dug into 'Diskless' Kafka and it's actually well named! The brokers genuinely offload storage to object stores like S3, which changes the economics and operational overhead pretty dramatically. This article by Abhay Soni lays out the basics clearly with a nice comparison chart to boot. What catches my eye: tiered storage isn't just a cost play. It fundamentally changes how you think about retention and replay. That's a big deal. Curious what others are seeing in the wild with tiered storage adoption?? https://lnkd.in/eXJUdmJF

34

3 Comments

Multi-cloud scale needs an entirely different approach to connectivity. Relying on sidecar-heavy setups to bridge Kubernetes deployments and legacy data centers introduces unnecessary latency and management overhead. The "mesh tax" is real, but it is no longer a requirement for enterprise security and routing. True scale requires centralized orchestration. Universal Mesh replaces complex sidecar fleets with strategic Edge Gateways. It provides a single, unified layer to seamlessly connect modern and legacy environments without the performance penalty. Jakub Suchy and Ron Northcutt are hosting a live session to demonstrate this architecture in action. Join them as they cover how to dynamically route around overlapping IP conflicts, unify your infrastructure, and eliminate the mesh tax from your operations. Sign up here: https://lnkd.in/e2uRT5Rt HAProxy Technologies

14

C/C++ is still improving, & ideally there will be a simplified subset with limited additions for memory safety etc., along with easy interop with legacy code: https://lnkd.in/exA-wi9m https://lnkd.in/e5YnTQk8 https://lnkd.in/eTvWiZ-C Why bother when there's Java, C#, Go, & Rust? While the first 3 are slower & have more bloated runtimes, Rust is similar in performance, but can also have a bloated runtime, and the language itself may not be very appealing to C/C++ developers. Additionally, the culture around Rust has been somewhat toxic, perhaps driven not just by egos (all sides) but due to the fact influencers are being paid to promote Rust, which can be detected by others as disingenuous, creating a conscious or even subconscious aversion to the language. With US Gov and BigTech pushing Rust, this can also rub some people the wrong way as a reduction of freedom of choice. I learned & used Rust on a fairly large commercial cybersecurity project, where Rust was a good fit for the product. While Rust was fun at first, as learning new things is part of the enjoyment of development, over time Rust compiler bugs, Cargo issues, very slow compilation times (large project), and the unfortunate insane complexity of the language in order to promote safety left me eager to get back to C++ for max performance projects. On a subsequent project with another company, a team member wanted to use Rust, & I shared my experiences, noting that while it was fast & stable as promised, & Cargo when it worked correctly was pretty cool, it wasn't the best choice for creative work, & some people are really going to hate it. This team went with Rust for this project, and sure enough, some loved it, some hated it. I've never seen this level of divisiveness before with any other language (there were similar events when Java, C# were promoted/pushed on devs by their respective corporations trying to expand marketshare, but not the level of hate directed toward the languages themselves as with Rust). Most human beings love freedom, & this may be part of the push-back on the Gov/BigTech to force Rust on everyone. For those who use & love Rust, all good. Others who don't like Rust can use Java/C#/Go (say 1.5-2.x slower with some GC spikes) along with small amounts of C/C++ for critical high performance elements, providing Rust level of performance, safety, & a much larger talent pool for developers vs. Rust, without the drama. I agree C/C++ is too large & complex, like Rust, though some of the complexity is optional in C++, & ideally the future Safe C++ will be simplified such that safety will be provided while the language looks as clean & simple as C# or simpler, with no loss in performance (possibly faster due to improved language design & modern language tech). Want to keep using C/C++? Politely & professionally, speak up, get involved, & help shape the future of tools.

2

1 Comment

Symbolic logic is eating LLM outputs. I've watched this shift happen in real time over the last year—developers are moving past "trust the model" and building deny-by-default architectures where policies, not prompts, control what agents actually do. OPA Rego, circuit breakers, cryptographic audit trails. The pattern is almost boring now because it's so consistent across different domains. Clinical agents, financial workflows, autonomous systems. They all converge on the same shape: symbolic layer on top, LLM inference constrained underneath. The hard part isn't the architecture. It's that this requires thinking about governance before you ship the agent, not after it breaks something. Most teams still don't do that. They layer it on like a band-aid. The ones that get it right treat the policy framework as foundational—part of the kernel, not middleware. That distinction matters because it changes how you debug, audit, and scale. Built it into Prefactor because I got tired of watching teams bolt controls onto agents that were never designed to be controlled.

1

🎉 Great tutorials on deploying a minimal vLLM production stack on an H100 machine using Kubernetes CRDs — a solid starting point for anyone building scalable LLM inference infrastructure.

29

LLVM IR is often seen as just an internal detail, but it’s actually a powerful runtime execution surface with real-world impact. Our latest article dives deep into LLVM IR–based JIT execution, practical debugging techniques for the whole pipeline, and advanced strategies for detecting IR-based payloads in live environments. This piece is a must-read for defenders, reverse engineers, and anyone working close to runtime behavior. Whether you’re looking to strengthen your understanding or enhance your detection capabilities, don’t miss out! Check out the article and elevate your knowledge of LLVM IR today. Munaf Shariff Read more here: https://lnkd.in/guY2umR5

24

ClickHouse doesn't have built-in schema migration support. In 2026. For a database used in production by thousands of companies. https://lnkd.in/gCU-4Fry That's not a niche edge case. Schema changes are one of the most common operations in any production database. And in ClickHouse, what looks like a simple column addition can trigger a full table rewrite when you're streaming hundreds of megabytes per second. Tinybird's own migration story is telling. Their first approach to handling materialized view changes was, in their words, "bulletproof but brutally inefficient." Touch just one materialized view and you'd migrate terabytes of upstream data. For a 14TB Kafka table, that meant days-long deployments. Every database has tradeoffs. ClickHouse is genuinely fast for narrow analytical queries. But if your workload evolves (and it will), the operational cost of that evolution is worth understanding before you're 14TB deep. What's the most painful schema migration you've dealt with?

7