Randall Hunt

There's been some talk around storage unification and zero-copy lakehouse integrations recently, and I wanted to better define these terms as well as look at ways we should evaluate different design decisions in this space. So I’ve published a new post: A Conceptual Model for Storage Unification Storage unification isn't about “one storage format to rule them all,” but virtualizing them into a unified logical model. In this post, I lay out a conceptual framework for thinking about storage unification (aka data virtualization). I explore: 🔹 Internal vs. shared tiering (and why shared tiering is so tricky). 🔹 When materialization makes more sense. 🔹 Client vs. server-side stitching. 🔹 Lifecycle and schema management across evolving formats. 🔹 Seven key considerations for evaluating different approaches. This is the groundwork for a set of posts where I’ll dig into how some real-world systems deliver storage unification, primarily about unifying real-time and historical data. https://lnkd.in/dBiS2kxJ

45

Maintaining an open source project is hard. Most maintainers are managing globally distributed contributors who are largely working for free, while companies build products and profit on top of their work. At the same time, those same companies expect bug fixes, features, and security updates on timelines that work for them, not for us. When something goes wrong, the blame usually lands on the maintainers. If your business relies on open source, helping maintain it isn’t optional. It isn’t charity. It’s part of a secure software supply chain. The health of these projects doesn’t just affect maintainers, it affects every company and product that depends on them. I spend a lot of my time at work contributing upstream as a Kubernetes maintainer and supporting the broader ecosystem. I’m very lucky to work at Minimus, a company that recognizes the importance of that work and considers it a large part of my job as a Developer Advocate. It’s so rare to see that in a smaller company. I wrote more about this here: https://lnkd.in/geZBAVXV

215

7 Comments

Yasmin COO at StormForge discusses how teams often copy and paste resource configurations from existing applications without considering if they match their needs. She explains how resource management becomes an afterthought in the deployment process, with teams prioritizing speed over the proper configuration of CPU and Memory requests and limits in Kubernetes. Watch the full interview: https://ku.bz/Bs49B8sYG This interview is a reaction to Alexandre's episode https://ku.bz/z2Vj9PBYh

15

As LLMs continue to show up across the federal space, one thing matters more than model size or hype: control. AWS quietly made an important move by adding response streaming support to Amazon API Gateway, and it directly addresses a challenge many of us hit when deploying AI in the federal arena. Streaming responses mean APIs no longer have to wait for a full LLM output before responding. Users can see results as they are generated, which improves perceived performance and reduces impatience waiting for a response. With streaming, teams gain: - More control over how quickly responses are delivered, including intentionally slower or paced outputs when overuse is detected. - Better user experience without bypassing security, logging, or gateway controls that come from workarounds. - Support teams that want to stay serveless and keep their architecture simple. The ability to shape how an AI responds is just as important as what it responds with. Serveless infrastructure is finally catching up to how LLMs are actually being used in production. https://lnkd.in/gxe_tkrp

9

4 Comments

AI is no longer just for developers. Tools like Cowork are automating everyday, non-technical work. Developers get the edge by focusing on architecture, logic, and real problem-solving. https://lnkd.in/g4aNhDDe

11