1:10 Hello, and welcome back to the Rawkode Academy. I am your host, David Flanagan, also known across the Internet as Rawkode. And today is an episode of Rawkode Live, the show where we take a look at all the latest and greatest open source cloud native projects. And today is no exception. We are taking a look at a project called Preak, as you may have gathered from the intro music. It's gonna help us build and run more reliable software. And our guest and host for today is Tony. Hey, man. How's it going? Listen. I don't think I'm blown away by that

1:43 song. Like, I think we should just put that on a loop and make that the lifestyle. That's incredible. I'm doing great. This was like, that that was amazing. That was hilarious. That was awesome. Should we just quickly go ahead? I mean, you know, that's that was amazing. AI today in 2025. What time? Like, the fact that that song can be put together, and I don't even need to know how to play a guitar or anything. So It's a real no. It's a real band. That's the community put that together. Can we Oh, yeah. Yeah. Yeah. For

2:12 sure. Yeah. Yeah. Cool. No. It's awesome to be here. I your your podcast is amazing. We were just talking earlier about the WASM the WASM podcast you did a couple of days ago or weeks ago. It was awesome to be here. Thank you for your time. Yeah. Thank you for joining me. So for anyone who's not familiar with you and your work, please take a little bit of time just to say hello and tell them what you've been up to. Yeah. So my name is Tony. I'm a CTO at a company called Prequel and a maintainer of a tool called Preak.

2:40 Quick background from me is I spent my first ten years of my career doing vulnerability and exploit development here in The US at a place called the National Security Agency. So I loved working there. The mission was really fun, really humbling experience. You jump into the deep end, and it's a very hard, job and but a fun mission. But, you know, I don't know if this is, known widely, but the government can sometimes be, this, you know, big bureaucratic organization that moves slow sometimes. So I ended up leaving in 2014 to join a startup, so, the opposite end

3:18 of the spectrum. And it was a company called Endgame, where we were building an endpoint security product. So I was there for for a while as VP of engineering, and we ended up selling that business to a company called Elastic, the makers of Kibana and Elasticsearch. Really big in open source, and that's kind of how I got my first introduction into working with open source communities. So I was there for quite a while doing a VP of engineering, but I still would find every excuse to cancel a meeting, go jump on an incident or not. I should go chase the bug. I

3:49 think it was probably chasing the first ten years of my career. I've always sort of been haunted by problems in software and bugs and curious to I think the best way to understand software is when it breaks. And so we ended up building a product to kind of help practitioners, engineers figure out when their software breaks, that's how we ended up on Preak. Awesome. Yeah. Lots of love there. I've skipped over the government, alright. Okay. You know, working on security is obviously gonna teach you a lot. Working with bugs, of course. I love that you

4:21 mentioned that, you know, software does break and people are human and people introduce bugs every single day and things go wrong. And one of my shows called clustered that I haven't done in a long time, but I'd love to bring it back. People always said, oh, the breaks are too contrived, and the premise of the show was live debugging. And I'm like, yeah. But people shouldn't have to know this stuff. But when you do, you do. Right? And it's like when things go wrong, when things are broken, when shit really hits the fan, that has been

4:48 you learn all these little tiny nuggets of knowledge that you would never learn under any book or other circumstance than when things are on fire. And I think that is a great way. And people should embrace failures and bugs and all of this stuff. But we have this not that I wanna try and solve software engineering as a community or anything. Right? But there's a stigma, and we need to kinda get past that and be vulnerable and be willing to make mistakes in public. And, yeah, I wish more people would do that anyway. Yeah. Yep. Totally agree. That's why I think

5:15 it's really cool that we're taking a look at Preak by Prequel founded by yourself on this show. So what is Preak? Yeah. I guess there's you know, the short version is like, if you've ever written software or even, you know, used it, and and this could be, you know, SaaS software or it could be Ubuntu, whatever it is, You know, like we just said, it inevitably breaks. You know, all too often, you know, especially if you're, you know, a maintainer or engineer that has to support that software, even if you're in customer success and you've, you know,

5:50 got a bunch of known issues with older versions of software, know, when it breaks, you often go on this hunt, and you're looking through all of this data. You you start with your investigation, you know, hours, sometimes days later, you'll end up like, oh, here's a known issue with a bunch of other people that have run into the same thing, and here's what they did to fix it. And, oh, let me try that. Okay. Cool. That fixed it. Now let me put a detection in place. And that I don't like that world. That world's not fun to live in. I mean, look.

6:18 I love doing investigations. I love it when software breaks, but it's always that bittersweet moment whenever you find that issue that other people have seen. I think Preak is sort of our our vision is to kind of create a world where if someone in the world has seen this problem before, that should be the last time. That first time should be the last time. And then we should start with that detection and share that knowledge. Kind of we call it reliability intelligence, common reliability enumerations. But I think that's that's the goal of Preak is how do you come up with

6:49 a way where you can start with a detection first that actually shows you the problem and the mitigation? Like, here's what the rest of the community has done when they've seen this problem. Yeah. I love that. You're building a library, a collective knowledge, if you will, of things that go wrong in software and allowing people to detect that early upfront, a shift left if you wanna throw in a corporate buzzword. Right? That is a a good mission, a very noble mission indeed. Yeah. We're giving Sorry. I was just gonna say it's like we're it's it's sort of a new idea

7:21 and reliability, but it's also an approach that has worked really well in security for twenty years because it was a similar situation in the early 2000s where you would have individuals chasing problems, but those problems were security problems