Amir Krayden Podcast Transcript
Amir Krayden joins host Brian Thomas on The Digital Executive Podcast.
Welcome to Coruzant Technologies, home of The Digital Executive podcast.
Brian Thomas: Welcome to the digital executive. Today’s guest is Amir Krayden. Amir Krayden, CEO and co-founder of AIOps platform, Senser, is a veteran of observability and analytics for complex distributed environments. Before Senser, Amir was an early employee of DriveNets, where he oversaw network infrastructure for the largest global telecommunications companies as VP Research and Architecture.
He previously led research and development for an elite group of the Israeli Defense Forces, developing hardware, firmware, and software for embedded devices. Well good afternoon, Amir. Welcome to the show.
Amir Krayden: Thank you very much, Brian. It’s a pleasure to be here with you.
Brian Thomas: Absolutely love doing these – love doing international ones. Of course, sometimes we get up early or stay up late to do international podcasts, and I know you’re hailing out of the great country of Israel. So, I appreciate the time and I’m here. We’re going to jump right into your questions here with your background in overseeing complex infrastructure and services like cloud at Drive Nets, for example, and leading R& D for the IDF.
What inspired your transition to AI Ops and the founding of Senser? And I’m going to add a little question to that as well. How is Senser different from other IT infrastructure monitoring services?
Amir Krayden: Oh, excellent, excellent question. So specifically, we got to this field because of personal pain. As you said, we chaperoned or oversee the development of large distributed systems, and with that we felt a lot of pains especially when trying to debug.
Or to troubleshoot such a big system in production and the pain that we felt was based upon a few things. One, the tool set or the monitoring tools that we used to monitor these environments. They were super hard to install. They were super hard to configure and essentially took us a lot of time. And even when we did it, then two other elements came in place.
They were very, very Oriented on what I’m defining for those tools, which dashboards I’m defining for these tools. And with that monitoring was just as good as whatever I define for it. None of these tools try to take a more service focused approach or more realistic approach. And when you think about the way that current software or current cloud environments or cloud services are being implemented, the problem is that It became very vague.
Essentially, I’m running a service could be a retail service or an e commerce service on top of a cloud environment, and all of the infrastructure is not something which I’m responsible from the networking layer or parts of the application infrastructure the cloud infrastructure. So, there’s a lot of vague there.
So, trying to look at it from a classical IT infrastructure perspective, what is this machine is doing or that machine is doing is kind of benign. It will generate a lot of data, but the interesting problem would be the fact that. You for humans, it’s very hard to look at all these data and to understand what’s going on.
Something went wrong in my stack. How can I trace back all these data and came to the realization of what’s causing it? So that was the pain that we’ve started with that inflicted us very, very much. Other aspect was things like the cost of these tools. Sometimes it’s staggering 30 percent. Of the infrastructure budget and with that, it’s not bringing me the benefit that I spoke about actually having a copilot or having someone there who can traverse these data and tell me something interesting.
So, when we started Senser, these were the focus in our mind. One, how we can make deploying observability something painless. So, we took a, we took a motion of a zero-instrumentation approach, meaning there’s no code changes on your stack. There is no infrastructure changes. You could do it very, very quickly.
But observability by itself is not enough. It’s not what makes an AIOps platform. What we create. Is a 3600 degrees or a list to give you a service based approach. How is the service behaving from two aspects? How is your users experience in it regardless of the way they’re using it using mobile or using web application or using whatever they’re using a functionality in your service?
Is that functionality working right? And what is the answer to that? Yes or no. And then looking at the technical aspect of it, looking at the technical stack and think of it like a graph, can we correlate how that behaves with what the user actually is experienced that. And when we consolidate all to one platform, which is essentially what Senser does, that brings an order of magnitude, a better experience in terms of identifying or predicting an issue is going to happen to the point in which you say, aha, it’s that aspect.
It’s that team that I want to operate and how it’s solved.
Brian Thomas: Thank you, and I appreciate the background on it. Obviously, you and I both been in technology and operations, and we’ve all struggled with this. You know, this age-old problem of trying to get to the root cause of something right doing those root cause analysis, and it’s always very hard.
So, I appreciate the share and what you’ve done and what you’ve created. So really do appreciate that. And a mere service outage can have an extremely detrimental impact on customer service, obviously. Which can turn in damage to your customer loyalty. How is Senser helping companies in industries like retail, finance, travel, hospitality maintain observability or over their production environments and prevent service outages?
Amir Krayden: I think specifically with those industries, so it’s, it’s easy to understand. They’re essentially very SLA oriented. The interaction of the user with the services is very important. And that’s essentially the bottom line. That’s what they generating money on. So, it’s easy to see why it’s super important for them to preserve a high level of reliability, a high level of resiliency.
What Senser does for these verticals. Is essentially to focus on the fact that they need to understand beforehand that something goes wrong being able to look at the unknowns, if you will, which element in my architecture are more susceptible. To be problematic and when something is going to happen or something is happening, then instead of having a Zoom call or whatever, Teams call with 100 people trying to go over where that could stem from and how to eventually solve it, we’re shrinking that time massively.
So eventually when the SRE team is engaging or the DevOps team is engaging, instead of having them manually do this process, We are doing that automatically. We are looking at all this data and telling them as, as simple as I could put it. Here’s the service problem. This is the user effect.
Now look, this is our analysis of the issue. We think that specific component is the one that’s responsible for that. May it be a software issue or an infrastructure issue, but you can engage with us. That team, it could be the DevOps team who will be responsible to solve it. It could be an application team, but that’s what we’re trying what we’re trying to minimize the time it takes them to detect and then the time it takes them to engage the right team and eventually solve it.
Brian Thomas: Appreciate you unpacking that, especially for again, those industries that are really SLA driven. What I like, the fact is your product can do some proactiveness and get, get really that team alerted to what’s going on before you start getting an influx of customer calls that obviously they’re You know, pretty irritated with you know, whether it’s an outage or something’s not working right in that process.
So, I appreciate the share Amir and Amir diving in deeper. What are the ramifications of a service outage beyond the customer experience? And what kind of costs are associated as a result?
Amir Krayden: I would divide it to two. One is before then the during or the after the before aspect of it. Has a lot to do with The teams, the teams which are responsible for reliability need to spend a lot of time essentially because of fear, you’re very fearful that something like that could happen.
So, a lot of the time of this team is spent on the monitoring tools. We spoke about the hidden cost of them, the labor cost of configuring them or customizing them. But because of that fear. That just multiplies. You need to spend a lot of engineers there in order to be prepared. And when they’re doing that, they’re not doing other things.
They’re not deploying new infrastructure. They’re not aiding to feature velocity from a company perspective. And they’re essentially spending a lot of time on that. And that’s just the before. But when something does happen, then essentially if we think about it, they need to answer three questions.
What went wrong, where it went wrong, why it went wrong. And the first two could be very cumbersome, and they could require a lot of people which are not really of the issue itself. Because of the nature of a cloud system or distributed systems, until the moment you can identify something, everybody is a suspect.
It could be the network, it could be the underlying infrastructure, it could be a configuration, it could be an application issue, until the moment you come to realization of where exactly is that and what, on general terms, happened, then a lot of teams are involved. And that costs a lot of money. Because all of them needs to be on the call, all of them needs by means of elimination, go and traverse a large base of data until they’re coming into more, coming to more focus and be able to say, okay, we think it’s that aspect.
And when we’re targeting that and when we’re enabling them to go from this what and where. To be more focused on the Y and how to solve it. The amount of the amount of money that’s being saved here is enormous. And people eventually, when they see this type of failure, they’re measuring the time it takes from the moment that the service owner understood that something’s wrong until the moment he essentially amended that.
But behind the scene, that’s where a lot of costs are associated. A lot of the teams, a lot of the hurt to other aspects that the company is trying to work on are taking place.
Brian Thomas: Thank you. And there is always a lot of hidden costs or costs. We just don’t realize because when we do have an outage or some sort of disruption, we don’t realize that it’s, you know, just customer loyalty or unsatisfied customers, but there’s a lot of time that from engineers that are taken away from their regular job to focus on something that really impacts the bottom line.
So, I appreciate that. And Amir, last question of the day. As a successful entrepreneur and leader in cutting edge tech field, what advice would you give to decision makers looking to innovate in technology and AI ops?
Amir Krayden: Excellent. So, I think in general being open to new developments, like the one that we are doing and others understanding the focus that executives should have on the business part and looking at things from business perspective.
If something is hurting my business, how do I find technology that can close that gap to be very cautious on what we call the hidden cost of observability that we discussed, what exactly is being invested there and whether or not whether or not on a scenario failure or on a scenario of an issue, will that be.
Exactly what I need in order to close that gap. And I think looking forward to in general, AI ops, but artificial intelligence and implementation within those fields. I think when they’re looking at it and trying to do to do this connection, how can artificial intelligence or machine learning can help me within those fields?
I think it’s a very unique time in the market where a lot of vectors. Are kind of converging and enabling that enabling companies like us to come and bring immense value for them.
Brian Thomas: Thank you. I really, really appreciate that. And, you know, hearing from somebody that’s been in the trenches. And it’s done a lot of this work again, appreciate the gems that you’re sharing with our audience.
Obviously, someone in our audience will take full advantage and this may resonate with one or several of those and makes me happy. So, Amir, it was such a pleasure having you on today and I look forward to speaking with you real soon.
Amir Krayden: Excellent. I thank you very, very much, Brian. It was a pleasure. And we hope that your listeners and other are more than invited to look at our website and come and try. I think they’ll be impressed by how much benefit we can give them. Really, really appreciated your time.
Brian Thomas: Bye for now.
Amir Krayden Podcast Transcript. Listen to the audio on the guest’s podcast page.
