Liran Haimovitch, Rookout | Yalla DevOps 2022
At Yalla DevOps 2022, Alan spoke with Liran Haimovitch, co-founder and CTO of Rookout, about the shift left movement and refining DevOps. Alan and Liran also discuss how improving visibility and observability is vital in today’s industry, and how Rookout has prioritized this in its offerings.
Transcript
This is texturung TV. All right. Hey, we're back here at yalla.
You know the noise is building up. Which means I don't know. Maybe it's coffee time or something.
But we've got people here. Our next guest is someone who we've had on on Zoom Tech strong TVs many times. Did we end up?
I thought we interview you maybe 2019 before the world went to four. Yeah. Yeah, maybe was La were you and cute con Los Angeles either Seattle was the last one was San Diego, San Diego was also yeah and Diego was the last one before covid.
Yeah. So proudest San Diego. Okay fair enough, not Valencia recently.
I haven't been to Valencia weekly forecast but I couldn't go for that was actually a good show. Yeah. Yeah beautiful town I loved but let's see you too.
Yeah, right. It was the people were very nice a beautiful beautiful city great food. But you got to eat late.
Yeah, we'll talk. But anyway, so for those who don't know Leo hi i'movich is with Rook out. He's actually one of the co-founders of workout, right?
Yeah. I'm still and I guess that begs. The question is workout.
What do they do? So Rook out is alive debugging in anomic observability platform. What we do is we bridge the gap between engineers and their code.
I mean as Engineers we're so used to having our code at our finger fingertips when you are walking locally on our laptops. You can just pause we can start we can edit we can change but once the code moves far away to production to the clouds to serverless. We have all those steps in the way, you know cicd or factory by Jay frog and those are super important components, but there are also barriers that prevent us from actually observing our code and with the shift left Movement.
We expect Engineers to own. Their code through all the software development type cycle and especially in production, but they're blind they can't see how their code is behaving. They can't see what gets executed.
They can't see the same stuff that they're used to and workout is all about bridging that Gap. It's about bringing the developers the observability. They need the debugging capabilities.
They need to own their code and to end. Yeah and you know when you're saying and I'm saying to myself of course, but the fact is I think when we look at the whole devops mentality of cicd, you know is bringing ups and death together with getting developers to be more involved in the ciciency broadcast to deploying the software, but there wasn't it's not a shift left in my mind. It's almost the shift, right?
Yeah. Exactly. I think we keep it developers, right?
We keep calling it shift left because supposedly we're moving responsibilities onto the developer. We're giving Responsibility of a quality but you're not giving them visibility. Yeah, we're giving them their responsible quality the responsible for security the responsible for performance by the end of the day.
It's not really shift left because those components aren't going away. They're staying right there where they are on the right side of the map, right but developers now own them now developers have to own production performance. They have to own production quality.
So essentially we're moving developers right rather than Shifting the workflow left, but it's worth but your shifting their responsibility, right, but you're not giving them up until now which is why I guess you need like a workout you're not giving them the visibility they need but you have to because how can they only giving them the tools you're not trying come from the security world in the security world. We had this for a long time. The security people will responsible for security.
Well, thanks, but we had no visibility or responsibility Creed deployment. To see if that code was good or not. So we would I mean think about the the nonsense of the idea of that how much software was never scanned for security before production and then all of a suddenly you're right now it's like hey don't you know, this thing has a buffer overflow or a cross-site scripting era.
What do you want from me? I didn't see it till went up on the web and I scanned it from the internet, right a third party. Yeah, and now in softer security you can't you it's well, it's become common.
You should supposedly she's left. You can't everything you do all the checks from the get go. Yeah and security people are more in charge of the policy while Engineers are more responsible over there execution.
Really? Yeah, and if you want Engineers to all execution for quality for security, you need to get into they need and their tools. Well, it's great to give them some tools around security sometimes around ITN cloud and compute first and foremost they care about the code do they need to see how their code is behaving in the real environment in production?
Because you don't want to hear from your engineers. It works on my machine because nobody cares I absolutely now. It makes perfect sense that if we did this for the security people we should do it for the developer as well.
But at the end of the day I've been on this kick lately. Are we putting too much on the Developers? Should it be the developers responsibility about how that the product or the application of the software?
Whatever you want to call it is not performing as as we'd hope or as plans. The thing is the world is moving toward. Everything is cold you have configuration is code you have security is code you have quality is cold.
It's automated testing stuff. Essentially. The developer is responsible.
And we're we're eliminated much of the other elements you no longer have it wrecking up servers you no longer have it right this configuring fireworks and ideas says you eliminated we eliminated those elements because they didn't provide enough value and they've hold us back in many ways. And if you want Engineers to and in fact that we've eliminated there is nothing left to rent thinking about serverless. There is nothing but code who is gonna own it.
If not a developer who wrote the code no. This well that that begs the other thing which is so we're gonna take that as a given who better to own it, but the server who the developer who wrote the code how much code does the average developer right? I would say surprisingly little I yeah, I'm seeing various benchmarks, you know, I haven't seen anything up to date most benchmarks while our pretty old speak on single digits.
I think today we might be double digits per day, but also the numbers were looking at Enterprises. I think that's a huge part of the problem because if you look at the end of the day, it's not just about writing the code. It's about delivering it and delivering code is messy it's complicated a lot of considerations you have to take place and that we got it doesn't matter if the developer owns it or if somebody else on it, you have to answer for Quality.
You have to answer for security. You have to answer for deployment. You have to answer.
A performance and availability somebody has to answer for it. We hope that by having the same person. It's gonna be faster, but still we need someone to answer it and that makes it longer and I think that's why one of the ironies of Social Development is how much time and effort we see software developers spend on updating observability on editing and removing log lines adding in the moving Matrix those online of code.
And if each engineered the end of day, right so many few precious lines of code, why waste their time on writing those if you can use to automate that if you can use make that instantaneous and have less have less code focusing on observability and unfortunately environment have more code on the business logic. So that's the argument for workout, you know in the US there was a president Harry trumid right word the end the world too. It's his thing.
He had a sign on his death in the overall office. It said the buck stops here. And really that's what this comes down to is at the end of the day whether it's on someone else's machine and it's the security people involved or this one or that one.
Where does the buck stop who is ultimately responsible? We're saying it's the developer because who else is better responsible. I think even more even if the CEO is ultimately responsible.
You still need to developer to fix it because everything so yeah, look that's an old security aren't you years ago? I'm insecurity. That was our selling Spiel.
We'd go into the CEO and say how you look in Stripes because you're gonna go to jail. If your security guy doesn't do whatever the compliance of the day was now but the fact of the matter is when something goes when something goes wrong with the software today CEO doesn't stand up and say it's my fall. It's those developers.
I pay these people of Fortune of money. They're the highest paid people here. I'm hoping most people are watching us have a better CEOs and better managers are gonna own up.
But even if they do own up the CEO, he's not gonna be the one to fix the code not absolutely. Know the code. Yes.
Somebody didn't have today has to dive into the code figure out what's wrong and fix it. And we see Engineers spending so much time and effort trying to reproduce issues trying to copy data from production to non-production environments. So and there's been so much time trying to make something appear in another environment.
When all they really have to do is observe the bug or observe the feature in the environment that actually matters introduction. Absolutely now so we've been skirting. What does does work out do all of these things?
How does it do it? Let's I know it's more tamed and Enterprises right? Let's let's zero in so Rook out offers production great tours that allow Engineers to dive into their code.
Our key. Our key product is called live debugger. It allows Engineers to set non-breaking points on any line of code.
They want with inter application and then see what happens when this line is executed on remote environments can be Cloud. It can be serverless kubernetes staging production. Whatever you're gonna get stuck choices variable values anything you would expect from a local debugger, except you can do it in remote environments anywhere you want.
No the tool is good for engineers of all kinds and in fact, we even have a community here that's free for you. But we've spent a lot of time and effort in making this production grade for Enterprises. In the compliance security performance availability support considerations that enterprises need because of our experience their pain is much bigger.
I mean, if you are a one-man show, you know, the code you have access to production. You can redeploy it will I mean it sucks to redeploy for a single outline, but you can do it if it's a one-man show, but if you're an Enterprises with Contours with separation of concerns separation of duties with a lot of flow that coming into those environments all of the sudden redeploying for a single logline can be a matter of days weeks or even months. And so we find that those Enterprises have much bigger pain and we aim to provide a tool that can support everyone from the smallest use cases to the most complex Enterprise.
Excellent. Where can they get more information? com.
We're also have a free sign up page. com. Check us out.
Hey, New York. Thank you so much a pleasure to see you again. Hopefully it won't be Me won't be three years.
We'll see you again soon. com here on textrung TV. We are at yala devops.
We still have a few hours left in the day. It will have some more people stand by.





