Continuous Automated Root Cause Analysis Platform – Manish Gupta, webb.ai
Webb.ai has created the industry’s first Continuous Automated Root Cause Analysis Platform. The modern cloud platforms are very dynamic with changes happening across code, infrastructure, and configuration to deliver the desired features to customers ever-faster. This change of pace is a key competitive advantage, but it makes troubleshooting hard for SRE and DevOps. Webb.ai aggregates all of these changes and uses AI to conduct root cause analysis for every change to reduce downtime. Cross functional visibility into all the changes and their impact provides situational awareness, empowering the organization to deliver features faster, thus increasing revenue.
Transcript
This is Textron tv. Hey everyone. Welcome back here to techron tv.
Um, I wanted to introduce you to a friend of mine. I've known this gentleman for longer than we probably both care to imagine. It's gotta be 15, 18, something like that, years.
Uh, I wanna introduce you to my friend Manishh Gupta. Manishh is a serial entrepreneur as well as a long time exec team member in, in what we call today cybersecurity. Of course, when I first met him, I think we were still calling it InfoSec.
Yes. And, uh, Manishh, welcome back to Text Drunk tv. It's great to have you on my friend.
Thank you, Alan. It's great to be here. Um, it's always fun talking to you.
Absolutely. So, Manishh, before we jump into the new thing, let's talk a little about, bit about some of the old stuff. Yeah.
I think when I first met you, you were, I mean, maybe an SS v p or VP at McAfee. This is, this might be pre Intel McAfee even, right? Yes.
This is a long, long, when McAfee was McAfee Correct. And, uh, we, we met up, I guess it was the nac the nac, uh, technology. And that was a big thing.
And that, I'm going to guess Manish what, maybe 2005, 2004, 2006, something like that. You were right. I think it was somewhere around 2005 to 2007.
Yeah. Yeah. Network access control.
Yeah. Yeah. That was, man, I think about those days.
And then o of course, you, you left McAfee after a while and, and you, you know, you went about on a very entrepreneurial journey. Your last company, of course, was Schiff left, which is still out there doing the job. And what I, what I loved about Left Man's as only you can, you, you recognize that, hey, what we needed to do here was to shift security left into the domain of the developers and the DevOps teams and the testers, because it was a lot, it's a lot more, uh, uh, resource, resource less intensive, a lot more, uh, business wise to fix these problems further left.
Now, of course, that's common knowledge. Knowledge, right? Everyone talks about Shift left.
Yeah. But when you started Shift Left, it wasn't right. It was, you were the, you were Schiff left, and you know, and as I said, Schiff left's out there doing its thing, but you, you again had the wanderlust of, uh, you know, someone who, who understands the security market, understands what people are grappling with.
And so, you know, there's another problem here. There's a problem here that needs to solved, needs to be solved. So that's my, that's my lead up to this.
Manish tell us, tell us more. Yeah, no, absolutely, Alan. Um, you're right.
Shift left. Uh, in hindsight, it's now called Quiet. Um, that is, uh, that was, has been our biggest achievement.
Um, you know, when we started the company in 2017, um, shift Left was not known. It was not, um, part of every CISO security strategy. And today it is.
And, um, we were amazingly successful at establishing the concept. And, uh, now under Stewart's leadership, uh, we are growing the company. And I'm sure we will see more and more financial success because shifting Left is a core component.
Um, and so after I left, uh, shift left, uh, I was thinking about what to do next. And, uh, like you said, uh, the entrepreneur bug hit me again, and I started looking at the problem. And one of the things that I had experienced at Shift left also was that, especially with the adoption of cloud, um, security is becoming everyone's job.
Um, yes. It's, For example, shifting left. Uh, much of the work actually has to be done by developers.
Um, very similarly when I started looking at, uh, how are we going to protect and monitor our cloud environments? Uh, because every company is now a SaaS company. It initially started out as a security problem.
And more I dug into it, uh, and more and more people I talked to, and now we've talked more than a hundred customers, prospects worldwide. And it has become clear that, uh, this is a far bigger problem than just security. And security alone cannot solve it.
ai. It is, uh, we are starting out as a sort of next gen observability company. Um, but as we have seen from some of the other players who are publicly traded, large companies in the observability space, observability eventually leads to security.
Right? Agreed. 'cause first, right?
And we've seen this even in infoset, like the way you used to call it before or cybersecurity, it all has to start with first visibility. And today, if your environment is very dynamic, which it is, um, right, and we'll talk a little bit more about that, uh, in our conversation. If the environment is so dynamic, how do we visualize, how do we understand what is going on in any given time?
And if we don't, then yes, it is a monitoring problem. It is an observability problem, it is a cost problem, and it is a security problem. Yeah.
Agreed. You know, Minish, I'm, I'm reminded of, for instance, Mitchell. Ashley, our C T O, he was out in la Las Vegas last week for Splunk, Splunk comp.
Yeah. Right. And Splunk, look, public company, great company, great technology.
io or, uh, log Rhythm or Log d n A, all of these companies that were collecting data, right? Right. Which, you know, in today's vernacular are now part of this observability ability type of universe.
They all, you know, they talk about the many uses of, of the data, of observability, what you can do and what it can help with. But I think, not, not that they're disingenuous or anything at all, but they don't come out and say that, Hey, for a lot of this, all roads lead to security because perhaps the best use of all of that data and all that observability and all those logs is for security purposes. And that's why we still have things like c you know, s I Sims and, and, uh, and Soar and, and these other types of solutions which are riding on top of this data collection capability that a lot of these companies are good at.
I mean, there's no, you know, there's no secret there. They're good at collecting all different forms of data, but the, the, you know, one of the still a primary use for it is for security. Uh, yeah, I do.
Uh, well, I will defer with you slightly on that. Um, you know, imagine you are a software company. You are a SaaS company because almost every software company is now a SaaS company.
Um, and you're the c e o, what is the most important thing for you? Revenue, your customers? Um, sure.
If your product is down well, you can't make revenue, money, you can't make any revenue. Um, and security is yes, important, but a significant afterthought. And so it has start, it has to start with reliability, availability, reducing mean time to repair different ways of saying the same thing, to make sure that the software that we are creating for generating revenues through our customers has to always be up.
And that is really the purpose of monitoring and observability. Um, and, uh, you are right. We've had tools, um, many of them that you mentioned.
Um, we've had these tools for a couple of decades, I suppose, in sort of pre-cloud world and in the post cloud world. But I think you said, as you described it, um, you described it really well, which is they create data, right? And so that is one of the things that, uh, we learned as we talked more and more ss r e side reliability engineers.
And as we talk to more and more DevOps people, you know, these guys are getting paged, let's say, at 2:00 AM to debug a particular issue. And at 2:00 AM they don't want to see data. They don't wanna see data, right?
They wanna see insights. They almost wanna be given action items. They tell me, Manishh, I would wish you told me do this, do this, do this in that sequence, and see if you are able to resolve the issue.
As opposed to the current word of monitoring and observability is what I call component level monitoring. Uh, if I have a hundred services, well, I'm looking at each service and looking at some metrics and time and trying to, as best as I possibly can, deduce what's really happening. But the whole work of understanding what's happening in this at the system level is on me as a human.
And I think that is the opportunity, uh, with the new generation of technologies, starting with large language models. They weren't around last year, uh, or a few years ago at least. And how can we leverage that, uh, to take this data and convert it into insights to leverage modern technologies like Kubernetes that are fundamentally different in the sense that they're declarative, um, and, uh, the Kubernetes operators that are constantly making changes into this infrastructure.
Um, and, you know, so all of these things like using eeb p f uh, as opposed to sort of deploying, um, thicker agents, factor agents, leveraging all of these technologies, we have found that it is conceivable, it is possible, as we've shown with our product to establish causality between things. And so that when you are woken up at 2:00 AM to say, Hey, this is wrong. We give you the likely root cause.
This is got, this is what got changed at such and such time, it was changed by this person. Um, and that caused a series of things to happen which resulted in this failure. And now you might have two or three choices to recover from it.
You might want to undo the very first change, or maybe that's not possible. And maybe you want to ameliorate that problem by perhaps adding more resources. I mean, that really depends on the situation, but that is what we are driving towards, is to establish causality, um, and do away with this humongous amount of data that is thrown at our, uh, DevOps and SREs.
Um, and instead I give them something much more actionable. Yeah, I agreed. It's almost, I, I think what you gotta realize is who your audience is, right?
It, it's nice to have that background information, but manishh, I, I'll tell you the truth, we see this here at Textron. Yeah. We write, our average article is 800, used to be 800 to a thousand words.
We've se we've since gone 600 to 800 because in heat map, looking at heat maps and so forth, and it's the same thing in videos. Like, this interview is 15 minutes long, but we'll probably edit up a three minute version of it. Mm-hmm.
Right? Which gives people the highlights, the actionable items in your vernacular, right? Yeah.
And because that's where the world is today. Hey, you wanna listen to the whole 15 minute interview here, here's a link, click through it. You wanna go see all the data behind these recommendation, here's a link, have at it.
But for most people, once they establish a baseline of trust, that the, the, the recommendations you're making are sound based upon the data, you know, going through the data twice is, is wasteful. It is, it is. Uh, I think that's a great analogy.
Um, we are overloaded with information. We are overloaded with data, and, uh, we need, uh, modern technologies, like large language models to convert them into insights. Right?
I, and I think, you know, for all our friends out here who are AI crazy these days, AI is everything. That to me is the real deal of, you know, the real use of, of these LLMs right? Is Hey, take, do me a favor, gather all this data that's overloading my brain and boil it down to insights that I need to, to work with, right?
And, and that is to me, today what's real today. That's what we want to be able to do here. Right.
Um, and quite frankly, some of the things I was talking to you about, like cutting these videos down Yeah. And, and doing a, a, a summary three minute of a 15 minute, that's a great use case for ai. Yeah, right.
AI should be able to do this for us. Absolutely. Absolutely.
Yeah. I, for one fall in the camp, there's a lot of talk about how AI replaces humans. And, you know, we won't have a job.
And I, for one, don't believe in that. It's not happening in my lifetime at least. But I do believe where there is a huge opportunity is to make us humans much more productive by becoming, by making AI a very credible, important assistant.
Um, to, and there're probably gonna be different versions of quote unquote, AI implementations. ai. You might be using a different tool to help you with shortening and briefing, uh, creating brief, uh, three minute, uh, videos of, uh, something much longer.
Yeah. No, it, it is exciting. It is exciting.
Look, I mean, the part that you asked me, I thought that was a very important, and I love that question, which is sort of, you are an entrepreneur, serial entrepreneur, minish, why? Right? I was meeting with some friends yesterday, and they asked me this question, why?
Because, you know, so a customer has said it best. He said, ish, the part that I like about you is that you like to imagine how the world should be as Be, as opposed to how the world is. Think that's the best compliment I've ever received.
So that, so that comes out of a quote from, uh, Senator Edward Kennedy at the funeral, of course, of, of his brother Robert, who was shot. And he said, some people ask why, and other people will say, why not? Why not?
Right? And, and, uh, yeah, no, it is powerful. And, but Manishh, that's what makes the entrepreneur, that's what makes it right.
It, it's all entrepreneurs. And I, I include myself in there, right? We dream of what should be, not what is correct, but what should and could be.
And I think, you know, because let's face it, the average people tend to think, oh, that company was an overnight success. And there are some companies that, you know, strike catch lightning in a bottle, but that's not the norm. No.
The norm is most of our venture backed startups, and we feature many of 'em here on tech drunk tv. They're 5, 7, 9 years old, right? And, and they catch their stride.
And they, you know, because it takes that long to, to, you know, you gotta see the problem. You gotta develop a solution, then you gotta go to market, build an organization, and go to market around it. These things, they do, they take time.
So when we say entrepreneurs or visionaries, they don't have a, you don't meet many successful entrepreneurs who are not visionaries. Indeed, indeed. And, uh, and That's where we are.
Yeah. And wouldn't wanna do it, um, any other way. Absolutely.
ai, and by the way, for the audience at home, that's web with two Bs. Yes. You probably see it in the lower third or by Manisha's name, but it's Wbb ai.
So Meneesh, where are we on the maturity scale here with web ai? I know it's still very early, you're just putting together teams and, and stuff like that. Um, for our audience out here, what, what, you know, how do they follow along and when can they expect to see some things?
Yeah, indeed. Uh, we are very early, but not quite as early, um, as kind of perhaps maybe you, uh, said it, which is our product is available in early access. Um, please visit dub dub dub dot web with two Bs, as Alan said, dot ai.
Um, you'll get to read about how we are solving the problem of, uh, helping DevOps and ss r e sort of go get those insights, do automated root cause analysis. Um, and the perspective there is, you know, typically we have a big major outage, uh, and companies will do a detailed r c a root cause analysis, which might take them days, sometimes weeks. Many, many different people trying to manually figure out what is happening across these highly connected systems, highly dynamic systems.
Uh, we take the perspective that in this dynamic system, there are many changes and every change. If software could do automated root cause analysis for how that change results in something else, then we are not just showing, you know, trying to boil the ocean by doing root cause analysis, some major problem, right? Which is highly complex.
Um, ideally we give you the root cause of a certain problem. If not, we give you the sequence of events that perhaps could have led to it. If not, we give you the changes across your entire environment, right?
So with something called the knowledge graph, which is, you know, the best way to describe it, Alan, is kind of like the next generation of service map. A knowledge graph is, contains all your services, how they're interconnected, but also all the infrastructure components, et cetera. Um, you, if you are interested, uh, in reducing your meantime to repair, if you're interested, interested in reducing downtime, if you are a Kubernetes, uh, uh, um, primarily a Kubernetes based infrastructure, we believe we can definitely help you come click on the early access button.
That'll send me an email, and I would love to talk to you, uh, to make sure that you have a environment and you have a set of requirements that we can meet, in which case we would love to deploy and help you along, uh, this journey. And you will help us along in this journey as we make this product much more mature, uh, before we release it for general availability. Love it.
Manish, I wish you nothing but lots of success, my friend. I'm sure, you know, as as this matures, as this comes along, you'll be on here often enough, and we'll, and we will, we'll ride along with you. Um, but hey, it's great to have you back.
I appreciate you and we'll speak to you soon. Absolutely, Alan, thank you very, very much. Thank you.
ai. ai. We're gonna take a break here on the Text Drunk TV Network.
We'll be right back.