 Hi, this is Saptil Bhartya and welcome to 3-3-M, topic of this month is observability. And today we have with us Yarden Life and Health, software engineer from Rookout. Yarden is great to have you on the show. Hi, it's great to be here. Yeah, before we jump into this discussion, I would like to hear from you. How would you define observability from Rookout's perspective? For Rookout, observability is helping developers get insight to what's happening in their production or staging or running environments in general. It's a really big issue, especially as we go into microservices and stuff like that, to know what's happening and where at every second. And so that's what we see as our goal and that's also how we see observability. We try to observe what's happening while our code is running. If you look at the early days of observability and today, how you have seen it evolved and also what kind of teams it touches, you know, of course, we can talk about DevOps, DevSecOps, developers. I really think that we've done a 360 in the observability world because I think we started out with logs. Like, I know for a fact that with myself, before I even heard the term observability, I was writing logs everywhere. And so when I heard of observability, that was the first thing that came to mind. How do I know when things, what things are happening? I just write a log and that will record it. And so we've started with really focusing on developers and how we can get that insight for developers. And then we've kind of veered away from that and seen how with, like, production data, we can help SREs or ops people to see what's going on and diagnose issues, maybe. And now we're kind of coming back to being developer-centered and coming back to how can observability help developers and how can developers use observability to their advantage. How have you seen the scope of observability it has evolved over the initial idea? So I think that, like, also we're letting in a lot of teams on this. A lot of teams are collaborating, like, I don't know, once it used to be developers writing logs, now it's DevOps people integrating certain other tools into it. And then, as I said, ops and SREs, looking at the data, looking at metrics to see if we have some sort of spikes or something we should kind of look into. And then that goes back to the developers using other observability tools to see what was wrong there. So the scope has gone from developers to developers and SREs and ops to almost every, like, R&D team out there. What does observability mean for developers? I think that once I deploy something, I'm kind of lost. Like, I don't know what's going to happen next. I've tested it as best as I can on my side. It's run through CI, CD, but now it stands to test in reality. And for, like, user edge cases and stuff like that. And that's where I think observability gives me confidence. I'm not just looking when there's a bug, but I'm looking when there isn't, too. Like, I'm just trying to figure out if my code is working out as expected under real-life circumstances. When it comes to observability, how much, you know, it's helping developers, how much developers are realistically being able to take advantage of it. So I think it kind of depends which observability tools you're using. A lot of observability tools are to monitor. I think that the base of observability is monitoring. And so that's less where developers see the value of it. But then when we get into, I think the value of logs is pretty clear to any developer just to see what's going on. And then we get into the more advanced tooling, like Rookout, like other tools out there. And we see a lot of value because these tools help us see what's happening in places that used to be this black box. If we're deploying to a remote environment, the only way you can really know what's going on there is maybe to SSH over and kind of start probing it. But other than that, and the logs that I've written ahead of time, I don't know anything. And so what we're doing is trying to make it more dynamic and trying to say, okay, maybe there's something that you didn't know you need ahead of time and now we can help you get it dynamically without you having to redeploy. And so that's Rookout's way of helping developers take advantage of observability. And I know there are a lot of other tools that are also stepping into this kind of proactive mindset, I guess you could say, of you might not know everything ahead of time. Let's help you while everything is running. What kind of culture shift you're seeing in terms of observability where, as you said, developers, it's mostly it's about logs, but a lot of things are mostly for the ops teams. What kind of culture shift you're seeing in terms of observability to help developers? I think this is a process or even maybe there's some sort of learning curve here. Developers aren't used to these kinds of tools. They are used to that black box mindset of I deploy something and it just happens. And so in order to even start thinking about, wait, I can actually get data from what's happening there or I can look at metrics or I can look at something a little bit more advanced, it really is trying to change the way we work, trying to change our day to day. And I think that's like one of the biggest challenges of this shift left in observability. But I do think that we're getting there. And I do think that the need for this is coming from developers. Like they might not think of the actual product. It's hard to do that jump. But at the end, when I get to talk to people who are using workout or just hearing about it for the first time, it's this sigh of relief. You know, it's this, oh my God, I've been waiting for this and they don't even know it. And then from that moment, it's still not an easy road to take. It's still not just like, oh, now that I know that it exists, I'll use it whenever I need it. But I do think the shift left mindset is there and developers are realizing why it's good and why we should use it more. We should be shifting left. And I said, you know, it's a process practice. Of course, sometimes a lot of cultural shift, it leads to adoption of a lot of tools and technologies. At the same time, a lot of tools, they kind of become catalysts to a lot of cultural changes. How is Rookout helping, you know, developers with this whole shift left movement in the context of observability? So I think that we're trying to stay in the developer comfort zone. And so I think there are very specific things that developers are comfortable with and kind of feel at home with. One of the main ones being, for instance, their IDE. I know that about me, like I know all the features of my IDE, all the features that I need and I'm very efficient with it. And so what we're trying to do is bring observability to the IDE. And so stay in that environment that we're really comfortable with and stay with the same terminology even if we're talking about a debugger and now we're talking about a live debugger. And so we used to put breakpoints in our local environment and now we're putting breakpoints in production. And so we're trying to bring the observability to the developer environment and not bring the developer environment to support observability. We are talking a lot about generative AI these days. And now generative AI can be seen in two ways. One, as a workload, as companies are running a lot of generative AI workloads to offer whatever services. At the same time, generative AI can also help improve observability. How do you look at generative AI from both contexts? So as a developer, and I'm not an AI developer, so to attest to the workload part of that question, I think that most observability tools and or depth tools are wanting to be veering into how can we help those AI workloads. I think that we're going to see a lot of AI experts in the observability world who can offer their advice and assistance on that to see how we can bring observability to that space. Also, because I think AI, if I was talking about our production code being a black box before, then here AI is even a bigger black box because we don't even know the neural pathways going there. We don't know why it's making those decisions. And if we could bring observability to that, that would be amazing. But I think we are going to see it later in the steps where it's made the decision and then how that will affect the flow later on with code. So that's about the workloads and about implementing AI in existing tools. I also think that's something we're going to see a lot. Like, I think that if we can give AI the context of our code and then show it what's going on in production, it might be able to maybe even word out a paragraph about what's going on or maybe even be the one that alerts us if it thinks something is wrong. And so we're going to... I think there's going to be a lot of exciting things there. I'm looking forward to it. As you were earlier talking about, you know, that folks are embracing it. But there's always, you know, a lot of folks who are ahead of the curve. They embrace these practices at the very least stage. And then there are a lot of folks who are still evaluating. Can you talk about the importance of observability for organizations? Or, you know, as we're talking mostly about developer steam, then why they should embrace these observability practices? I think, first of all, I'll say that most observability tools, especially, you know, SaaS-based ones, are pretty easy to implement. Most ones that I've encountered, including Rookout, are such a small change to your code, maybe even don't have to change your code. Necessarily that it's worth the risk of it not working out in the end. So I'd say, like, take that first step. That's the first thing. And then after that, it's a matter of, I think there's almost instant value. Because I think that we all have issues in production. And I'm not going to say bugs because there are other issues as well, like performance issues or memory issues or stuff like that. And observability tools help basically, like, across all of these. And, like, I think the best way to answer that is to just say, like, if you're not deploying an observability tool now, the next time that something goes wrong, the next time that you have a bug and it's not just like on your local feature branch, take a look at the observability tools out there and see which one could have helped you if you had it deployed earlier. And I think pretty soon people will be realizing that these tools are very, very valuable. As a developer once again, what is your advice to these teams so that they can, when they get started, they have the right practices in place when they are embracing observability practices or adopting some of these tools? So I think it depends on the tool. I don't think there is, like, a big answer for all tools, for how to use them. But I do think that a lot of, there are a lot of success stories out there. A lot of times we like to hear about bugs and how people solve them. And lately, a lot of these stories where we hear at conferences or talks like this one will have observability tools in them. It's like how I use this observability tool to fix this problem. And I think we can learn a lot from those along with just like documentation and kind of reaching out for help from my experience. And also I'll say as myself, observability people are nice and they like to help. Also, there's a lot of open source tools out there. And so there's a really big community. So it's, you know, learn from the docs, talk to the community, and then learn from success stories of other people. Initially, we were talking about the evolution of observability. We were talking about the scope. Where do you see observability is heading? Where is it going? Because you folks have very good, you know, picture of trends, going use cases where you say, hey, this is where observability heading from the original idea. This is what we should be preparing for. This is what we should be planning for. This is just my opinion. But I think we're going to be seeing a lot more invasive observability. I think that Rookout and other tools like it have been the first to take a step in that direction of really not even asking the developer in some sense. Like I know OpenTelemetry has auto instrumentation, stuff like that. It will tell you what you need before you even know you need it. So I think we're going to see a lot in that direction of, also if we've spoken of AI, it's also going to come from that direction, I think, of will tell you what you need before you even need it. I think that's a really, really interesting direction that the observability world will go in. Yaran, thank you so much for taking time out today and share your insights about observability. And I would love to chat with you again. Thank you. I would love to too. Thank you for having me.