KCAA: Inside Analysis with Eric Kavanagh (Sun, 21 Apr, 2024) - podcast episode cover

KCAA: Inside Analysis with Eric Kavanagh (Sun, 21 Apr, 2024)

Apr 22, 20241 hr
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

KCAA: Inside Analysis with Eric Kavanagh on Sun, 21 Apr, 2024

Transcript

Host of this exciting new era learn more and Inside analysis dot com, Inside Analysis dot Com and now here's your host, Eric Kavanaugh. Ladies and gentlemen, Hello, and welcome back once again to the only coast to coast radio show all about the information economy. It's called Inside Analysis near truly. Eric Kavanaugh is here and folks, we have a fantastic topic lined up for you today. A good friend of mine, Ellen Rubin, who a company called

Cousley, is on the show. She's been in the business for a while. She was at in Natisa for those of you who mentioned who remember in Natisa, which took the market by storm years ago data warehousing appliance, and then of course it got bought by IBM for like one point two billion dollars or something amazing like that. And I was like, wow, how did that happen? I asked my partner, doctor Robin Blore. I said,

why would IBM going behind Natisa? They have their own dB two And I said, well, when you can borrow money at zero percent, why not? That sounds like rob that's a good point. That's a good point. So anyway, yes, Ellen Rubin, welcome to the show. Thank you for your time today. Thank you, pleasure to be here and nice to remember remember old times from that time. But you know a lot of technology

has happened since then, for sure. Yes, that's exactly right. I gave a presentation, in fact, I moderated a panel in New York last week Forever in Your Technical Debts, which was all about that, like dealing with technical debt, and it's out there and it's everywhere. I mean, one of the Finaliert quotes I've heard over the years was someone who defined a legacy system as any system in production. It's like, all right, I

get that right, Yeah, true. But you folks, we'll talk today on the show about cause I and what causal AI is, so Ellen, I'll give my take on things and just kind of see where you fit in this whole conversation. But you know, when I look at observability, which is now everywhere, I mean observability, I think it skyrocketed faster than big data, which went really fast, and of course llms now have skyrocketed faster than anything, but observability three years ago, I don't even know if it

was a term. And now there are like fifty observability vendors, and I think part of the reason for that is because of Gubernetes out of Google. Because this new distributed way of container orchestration is so different and so dynamic that all of a sudden, we have all these new sources of information that we could pull together, which is great for developers and site reliability engineers and the application teams that people actually build the apps and maintain the apps that run business

these days. It's good for them, but also it's a blessing and a curse because suddenly we have five, ten, twenty different sources of data and it's up to the individual to parsel all that stuff and to kind of pull together. And I've noticed this, for gosh, in the first year of DM Radio, I interviewed a guy from a company called Precisely Zohar Gila.

I'll never forget his name, Zohar and Precisely, I'm sorry. It was a It was called Precise and it was basically troubleshooting, and so you would look at CPU usage and network behavior and app performance and all these different things and you get histograms. But the point is the developer had to piece this all together in their head, which is hard to do. It requires a lot of experience, a lot of hard knowledge about how things work and how

things interrelate. And of course these days companies create run books and all kinds of different things to help the srres and the others figure out, Okay, if this goes down and that happens, and this happens, then do X. And that's good for as far as it goes. But wouldn't it be nice if something came along to dynamically absorb these different data feeds correlate them. And that's the key. When this goes up, that goes down, which means one thing. When that goes down, this goes up, that means

something else. To be able to correlate that and understand that in Parson, that's getting pretty powerful. It's my understanding that's what causal ais is, at least in this context. Is that right? Right? So, you know, kind of going and taking the step back that you started with around what's going on and why are the problems in the industry getting so much worse than they used to be. You know, obviously monitoring APM, you know,

ability to measure and have metrics on what's going on. These are not new concepts. Anyone who's been in the IT operational space for a long time and has had to run and scale and own large applications and infrastructure. You know, like these are a lot of these problems or old problems, like stuff breaks, things slow down, things go wrong. You know, you don't understand what happened. So you know, that's many, many decades of problems.

But the point that you made, which I think is right, is that in some ways things have accelerated in the past ten years, not only with the adoption of micro services and you know Kubernetes as a good example of that, but also just the sheer pace of people using DevOps and being so agile and rolling things out all the time that you really have a lot of room for confusion and room for complexity that is in some ways exponential compared to

what you used to do the case. You know, certainly when you had more of a monolithic environment and people had more of a somewhat less dynamic set of changes that happened. You know, in a less you know, agile kind of a rollout approach, you could kind of know more about what was

there or what was in the stack and what changes were being made. And now you know, there's so much more frequency of changes, and there are so many things that can happen dynamically where people are using your application and their you know, their load patterns are changing, or the way in which the application gets rolled out and scaled out can be constantly causing new problems that you're not aware of, and no one person has a view of what's actually going

on, not to mention that there are all these interdependencies between services in that type of an environment, and between the infrastructure and the application layer of things that frankly, a lot of people have no clue what's going on at the infrastructure layer anymore, right, Like it used to be a little bit easier to get to the to the bottom of what was going on there. Now

it's all the inter relationships and the interdependencies. So if you look at that kind of a world, what you can see is that observability, like data Dog is a great example, took off with the rise of cloud and this type of you know, kind of shift into a much more agile world, and you know, that has driven tremendous growth. And then of course there are a lot of companies that are sort of the you know, the next

generation of observability but a lot of them. And I would I would make the case that you know, kind of like the whole industry is still focused on saying, well, if we just monitor everything, we just have a metric on everything, every piece of everything, and now there's so many more any everything is that now we need to store all of that data and we need to hold on to it for you know, longer term trending and compliance

and all that kind of stuff. And so what they've created is a little bit of a you know, like a uh, you know, the gift that keeps on giving, right, Like the more things that you're looking at and tracking and measuring, the more room there is for people to say, well, something looks wrong here, what's actually going wrong? Oh, now we've actually had something more service impacting. Now what do we do? And

often the interdependence of those things are not clear. And also the people who are involved might actually sit in multiple organizational teams or functions and try to pull it all together. And the poor you know, SR or incident response person who gets hit with this is like, Okay, where do I start, you know, And in particular, if they don't have a lot of knowledge

and expertise of the particular area where the problem is. So these are all things that we see all the time, and so I think your your initial point is the right one, which is to some extent, more observability tries to solve the problem in the industry. In some ways, the more problems get created because how many hundreds of alerts can you look at? Right? People simply can't keep track of it and they don't understand it. And sometimes

the alerts that you're getting are the symptoms and not the actual cause. So that's you know, that's that's the problem space that we're coming into as Cousley, and you know, bringing a lot of knowledge and expertise from the founding team from this particular set of problems. Well, I mean you've hit the nail on the head right there with the fact that many times what you see are symptoms, it's not the problem. And root cause analysis has always been

difficult. It's always hard. But I will say that the power of machine learning is very compelling here because machines can scan vast amounts of information log files, for example, usage patterns, and the key obviously is to capture that and to identify the correlation, help the end user find the causation or even find it for them and then catalog that and know for next time when this set of circumstances comes. Aha, it's probably that problem we had before.

Maybe not. There can always be some new piece of information coming in. But to be able to dynamically ascertain the correlation between feeds and thus get too closer to the causation, that's a huge deal because one of my big themes here is morale and morale of your teams and your sres. Your app teams are going to have very low morale if they can't get to the bottom of things. If stuff breaks and they can't even figure out how to turn it back on again, that is not good for the home team, it's not

good for me, for anyone involved. And so what I love about this causal AI is that it's greasing the tracks to the correct answers. Right, Okay, So I'm going to shake your world forget about correlation. Oh, correlation is history. The way people think about correlation is stuff's going wrong.

And there are a whole bunch of things I got alerted on, and I'm looking at the picture that I have of my topology and the incidents that I'm seeing you know that, you know, all my tools are telling me about and I'm a human being and I'm trying to figure out how those relate to each other. And mostly what I'm looking at is anomaly detection together with correlation.

That is the state of the world right now. And what we're saying at causally and what you know, we as the founding team really believe in very strongly, is in the end that comes down to providing human beings with pieces of information and updated you know, pictures of their environments and reality that still they have to piece together what's going on. You know, it's like the joke right about correlation is not causation. So let's let's just pause on

that for one second. Like, the most the funny one that people always talk about is how like ice cream sales in the summer and sharks correlate. Like that's the most obvious one. So like if you think about it, you realize how ridiculous it is, which is, of course those things correlate

with each other. But the root cause is like that it's the summer, right, It's a season, and you know, it's hot and people are outside and sharks are outside too, so like, there's there's something about that that I think the industry has not kind of accepted or believed that it's possible to do more than that, and that as a result capturing all of this data or having to do more of a bottoms up approach in which you try to like build models that you could automate, you know to your point,

you know, run books and all that. But in the end, all of that comes down to that some human beings with some expertise and knowledge took a look at things and said, Okay, that's actually really the thing, because you know, if you start to fix something and you're not fixing the root cause, all you're doing is pushing the problem around or just it's going

to come back later. So the philosophy that we have a causely is that really what you want is you want to have the knowledge of causal relationships of cause and effect, not correlation, but causal effects captured in software and automation as opposed to relying on human beings. And that's a really hard problem.

It's not something that a lot of I think people in the operational space and you know, in AIOps and other areas that are are kind of part of the industry have really wanted to take on, and so they're focusing more on how do you automate the human capabilities that are out there and make those more repeatable. And what we're saying is, let's go to the heart of this and capture the actual causal knowledge and ability to say what these causal relationships are.

And we do that in a very particular way that's based on a specific approach that you know, my co founder and the founding team bring to the table. But really what we're trying to say here is that what you would want to see in your application environment and in the way that you build and run applications is that you are able to maintain and run these applications reliably.

You're able to ship code without breaking things, You're able to have new changes that are constantly happening customers using your application in different ways, and that all of that can be maintained in a good and healthy state where you're able to

meet your business objectives, you're able to meet your service level objectives. And at the heart of that is the fact that there is this causal knowledge that's being captured, because without that, you're just you're playing wackable, right, you're running around your environment trying to fix things and tweak things and improve them.

So that's the approach that we take to the industry, and we happen to be using an approach that is a causal AI platform that we built, and that's technology that we are running our first that is available now for people to be testing with. So that's that's kind of the approach that we've taken. And I think that a lot of companies that are out there are hoping that they will automate things enough, you know, with enough data that eventually

they'll get a picture of reality. But of course then things change ten seconds later, and one customer's environment is not like another customer's environment. So these are all things that you know from our approach. The bottom is up is not the right way, The top down is the right way to think about it, and that's that's part of the Causal platform. Yeah, that's very

interesting. So in other words, the technology, the AI that you're using is designed to focus on understanding root cause, which, as we've discussed, is very difficult typically to do, but it's not terribly difficult depending upon the algorithms that you're deploying because you can run what if scenarios very quickly, you can do all sorts of Monty Carlo assessments essentially on the data, and then I'm guessing that when you find certain things you are cataloging, that is that

correct. Well, we're actually using a very different approach than that. So some of the things people are familiar with using, you know, machine learning and you know, more traditional types of AI approaches that are out there, are approaches that other companies use. We are coming at it from the perspective that you need to start with what we call structured causal models, and they're what we're able to do is we're able to capture the relationship between the root

cause and its symptoms in a very generalizable and very abstracted way. And we've created these and we've captured them in software and that's a key part of what we've built, and that just out of the box. You know, it's not like, oh, we have to come in and understand something unique about

a customer's environment or what their relationships are there. But we've done it at a higher level where we're looking at problems that are things like noisy neighbor and database slowdowns and congestion across data pipelines, and you know, message broker problems where often it's the inter relationships between a lot of the different parts of the environment and uh, things that could be very multi variate, right in terms

of how many different things are interacting with each other in real time make it really hard for human beings to troubleshoot. And so we've captured those in our structured causal models, and then we're applying the causal inference engine that we've built

to these problems. And all of that is happening with live and dynamic real time customer environment right where we're sitting in their environment, and we're able to see a lot of the you know, kind of like the data sources that exist about their you know, what's happening in the kumunetes cluster, and then their cloud services, and what's happening, you know, across the environment with databases and networks and you know, and message brokers and networks and stuff like

that. So we're we're essentially taking all of that in as live, real time feeds, and we're able to then apply that to these causal models and use the cause imprints to say, hey, at this moment in this particular

customer's application, you know this particular set of scenarios. These are the things that are problems that are either happening right now and you need to do something about them immediately, and here's how you should take action, or these are emerging problems, things that are potential things that could happen in the future that you would want to be aware of and you may want to take action on in a more preventative way. And that's the causal relationships really help us to

do all of that. That's very interesting. So you built these models, and we'll pick this up in the second segment here in just a minute, but it sounds to me like a foundational model for causal AI for troubleshooting and finding root cause analysis. And just to explain to our audience out there, foundational models, well, like the large language models are I think going to reinvent enterprise software, but they have to be very focused. The large language

models are very, very big, They have billions of parameters. They still work. One of my good friends heads up actually at Northeast in Massachusetts, the Institute for Experiential AI, and he was joking when I talked to him on the show earlier this year. He's like, these models they're too big, they're not supposed to work. Nobody knows why they work. I'm okay, you're running the whole institute. Sometimes I does have that feeling, right

like nobody that's kind of scary. But so we'll pick this that out of the break. But it sounds to me like you have built a foundational model in this space and it's very very interesting stuff. Don't don't touch that down, folks. And we were right back. You're listening to Inside Analysis. Expected welcome back to Inside Analysis. Here's your host, Eric Tavanaugh. All right, folks, back here on Inside Analysis talking to Ellen Rubin of Causey,

which is a company. Guess what, folks on cause AI, which is really interesting stuff. So this is not large language models. This is not some of the other foundational models you've heard about. Specifically, what the folks did here is they focused on these structured causal models and they look for very specific types of symptoms and can help you use an inference engine to know

when this variable changes, that variable is going to change. So they're basically looking at the inner workings of a system to understand how it works, and that's why they can get to the root cause of some very complex problems very quickly. Is that about right on? Yeah, Yeah, that's definitely in the right direction. So, you know, for us, the whole point of this is to remove human effort and you know, challenges that require sometimes

days worth of like what the heck is going on in my environment? And so there is no there's no effort or lift from people who would be using causely to have to you know, use our inference engine, or to have to create any of the models or apply the models or whatever. That's just

completely automated and completely out of the box. And that's something that we think is really critical here, which is if we're going to automate this in a way that allows us to go all the way through to what do I need to do to fix this or who do I need to inform about this information so that they can make a change in their code or do whatever it is that needs to get done. You need to take them all the way through

right to the conclusion. And so it's really about understanding the root cause of what is happening in the environment, and even better to help people see things that could be emerging problems and potential things that might be happening in the future, because you know, it's such a dynamic environment that they're living in.

So that's really important. And I think what you were saying earlier is key, which is we're really looking for the symptoms of certain types of problems that are these you know, often challenging, very complex problems that people deal with all the time. And by doing that, we are more efficient and I

would say almost more like laser focused on. Based on seeing these particular types of symptoms, we can tell you what the root cause is, and we can show that to you automatically in a completely, you know, real time way, and it doesn't require as the human being to then stiff through a lot of other pieces of data and try to say, oh, okay, that looks like it. Now, let's go try to fix that and see

if that actually was the root cause. We're telling you automatically. So we think that that is that's just the way the world needs to work in the future, and it's been very very hard for people to do that up until now. The fact that there are lllms and the fact that there's machine learning. You know, we'll take advantage of all of these techniques that are out

there. These are known techniques, but what we're bringing uniquely to the table is the ability and the expertise to have built a platform that is this really really scalable, really really you know, automated platform for capturing cause and effect relationships, which you know nobody else has done so far. Yeah, and it gets into graphs too, right eight, like directing graphs and acyclic graphs and things of this nature where x leads to hy, which leads to z,

et cetera. So you identify these patterns and then you look for when it applies in a particular scenario. Now I'll throw out sort of a random anomaly here or analogy. I should say. What I remember from taking calculus years ago is that if you skip a day class, first of all, your toast so do not skip. Okay, but you kind of do that back and then too, right, that's right, that you probably shouldn't skip

a day. But I remember what I remembered by it that it was very interesting, is that their x number of patterns and you have to sort of you have to infer what the nature of the problem is to apply the right formula to figure out the problem, and it sounds like these structured CASEM models are the foundation for that. So they have a certain number of these these views of the world essentially baked in from experience, and then you apply it

to whatever the situation is. And then the way it works is it looks for certain characteristics, certain symptoms as you mentioned, and when it finds that, it goes aha, we recognize this pattern, we think this is what's going on. That's that's basically how it works, right right, Although it's you know, it's less about we think and more that we feel confident and

that you know, a lot of it is applying it. Applying this causal ai approach to the cloud native and operational world is what is unique here, right, Like the field of causal ai, you know, we were chatting about this previously. You know, like the field of causal ai is a known field. This is that people have been at this for a very very long time. There are people who are famous in this field, like Giba

Pearl and others who have worked on this. You know, many universities and it's frequently applied in things like healthcare and marketing and financial markets and stuff like that, where the need to know about causality has been strong, and people have applied it into those situations, but usually it's done in a very project based type of approach, like here, we're going to build something with this

particular organization or this particular team that solves these particular problems. And in a lot of ways, it's kind of a closed system, right, it's meant for that particular you know, it's it's kind of a proprietary thing that that people work on within the analytics or the data teams. What we're saying is we've now created this in a really generalized way, in an abstracted way that

can be applied to the overall cloud native and IT operational world. And you know, we happen to have picked a certain set of initial problems that we're focused on, and we're doing official you know, work with companies that are using more micro services based environments, but it's more generally applicable than that.

No, that's interesting. So you have a very focused approach and that has allowed you to leverage this these models and let's face it, I mean the challenge now for developer teams, for application teams, to your point earlier, is that the environment is incredibly complex and it's getting more complex by the day, and I don't think that's going to change. So what can you do

differently? And that's where this approach comes in, right, is to leverage the known science of causal AI and to map that against the symptoms and all the data that's coming from these various environments. To keep it simple and look for the patterns right right, and make it an out of the box experience.

Like I think about the people who are responsible for building and operating large scale, very very you know, kind of complex application environments like you know, huge huge companies that have these applications where they have like thousands of applications, is also true, And think about the nature of the job for the people who are the DevOps people, the srees, the people who are handling incident response, the people who are on call, you know, like all

of those types of people, you know, let alone the people who are in the mode of like I own the you know, the the KPIs and the you know, the metrics that are you know, the business and technical metrics for for how this application is behaving. Like you don't want things to break all the time. You want to ship code faster, and you want to be able to adapt to dynamic and changing customer needs, and you know things that happen at peak periods, and you know new things that get thrown

in because the cloud infrastructure underneath you keeps changing. You're living in that world, and a lot of time what you're thinking is, oh my god, like if I just don't have every piece of information and every single thing that's in my environment, I might you know, something terrible might happen, right or I might not achieve the goals that the business needs. And you know, from us, the philosophy is, what can we take away a lot

of that confusion and difficulty and pressure. And even if you're not somebody who's been on the team for very long, or even if you only know about a few services that are the services you're responsible for, how do we give you this kind of out of the box and really fast experience that allows you to then say, okay, well I don't have to worry about that anymore.

Rightly, the environment is going to be healthy and it's going to be resilient, and we're not going to be constantly, you know, kind of playing the whack a mole game and really we can focus on the things we care about, which usually have to do with I have new features to roll out. I want to make sure that I'm you know, kind of architecting things for a better experience for the customer or for bigger scale or whatever it is, and that's where the energy should be going. Yeah, well,

I mean I happen to know from experience to talk about whack them. You can spend the rest of your life trying to track down problems and never even get there if you don't have the right perspective, if you don't have the right information at your fingertips. And what you're talking about is providing this sort of foundational component to solve those problems out of the box. I guess one question I have is how do you deploy Like when someone actually buys the software,

where do they deployed? How do they deployed? Is it in the instance in the cloud or how does that work? So the initial product,

initial costly product is it deploys into a Kubernetes cluster. So we kind of are you know, using that as an initial As I mentioned, that's kind of our initial decision about you know, kind of starting with those types of environments that can be used more generally than that, but for the initial product, people would deploy us and it's like a couple of minutes, you know,

to be up and running within in their Kubernetes environment. And what we are able to do though, is we're able to see things that are you know, well beyond what's happening in Kubernetes. So all the different cloud services and the you know, like all all those different inter relationships that I was describing, we're capturing those automatically and out of the box, using a lot

of different data sources. So you know, uh APIs from the Kubernetes and cloud environments, using uh accessing data from Prometheus, leveraging open telemetry, e B, p F st O, all of you know, a lot of open source tools, and then being able to take alerts and other information from products that a lot of the customers would be using, like data Dog and similar observability products. So all of that is kind of input to us,

but that just happens automatically. The customer doesn't do anything, you know, to to make that happen. And then uh, you know, the idea for these customers is that they would be able to immediately see like it's not They don't have to run it for a while and baseline anything like they can

immediately out of the box start to see what's happening in their environment. Not only you know, of course, the topology and you know what their environment looks like, but the causal relationships that are in place across that environment.

And we think that that's really exciting and compelling that when people can see that all of a sudden, they're like, oh wow, Like we have this idea of a causality tree that basically shows the root cause with all of the different symptoms, and that's something that is a view within the product that we're able to say, here, look for this particular issue that's happening. You know, it's either an existing problem or it's a problem that could happen in

the future. Here are all the causal relationships, and we can tell you a lot of the information around them, and you can dig deeper on them, you know, with as much you know, more detail and metrics and

data. But really the thing that you want to see is in my environment, this particular issue is happening or it's about to happen, and here are all the causal relationships that are captured visually, and so we think that's that's really fun and that people you know, will be excited to have that, and you know, kind of early working with early customers, a lot of times what they say is, this is the first time we have this view

of what's happening in our environment as opposed to a more general cology view which I think they're used to seeing. Well, I mean, understanding causation across these environments. That's the key, because one problem here can propagate over here and over there, and that's those are the symptoms that you're seeing. But to your point, with this structured causal model, you're able to say with great certitude, when certain conditions are met, Okay, we know what this

is, right, it's a pattern matching scenario. But it gets you to the root cause very very quickly, like, okay, this is it now we know basically it's not even probabilistic. We know that when these conditions are in place, X is happening, or we know in those conditions are the place, why is happening? And here's what you do? And then you actually go the next step is that right? Do you actually then remediate with

automation to solve some of these problems. So you're a experienced person in the industry, so the remediation conversation is always a conversation, right, So basically we can remediate all the way and take action. That is definitely something that we do, and we can do it, and in some cases customers have told us please do right, like if you can actually just go ahead and you know, kind of do certain types of actions, please fix it,

Yeah, take it, take it away. But often in some of the larger customers we're working with, there's a desire for it to become a part of a set of change management pipe you know, CICV pipeline that's already in place, and for obvious reasons, right, like, you can't go around

those systems, you have to live within them. And so a lot of the work that we're doing is to just make sure that we tie very seamlessly into that, Like how do we make sure that if the way that they take care of certain types of problems is by a set of things that they've built in their infrastructure as code, well, then we should just tie into

that. Right, We're not going to reinvent the wheel for them. On any of those things, and some of it, you know, as to some of the things that you were saying a little earlier, there's like the if the right person gets the information they need and they're able to have that information immediately, then sometimes the action that needs to be taken is a human action, right, It isn't really an automated action, like could you re architect this so that it doesn't have this choke point? Kay? That may

take a little bit. See. This is very very interesting though, because I understand that, and I think a lot of people on the outside of enterprise applications don't fully appreciate this, and I think they will more and more so as time goes by. But every environment is different, Every environment is bespoke, especially when you have these hybrid cloud environments. I mean, yes, the cloud is sort of garden variety if you will X number of services

that we can all use and cobble together. The second you touch some on prem environment, you have a whole other set of challenges that are very complex and that are very bespoke, and that will need special attention, which is why off the shelf stuff sometimes requires you to take some extra act added steps to connect it all and to get it through and to understand with the client what environment they want, what do they want want to get out of this.

So I'd love that it solves a lot of these problems in terms of getting to root cause analysis, but you have some opportunity for the client to say, well, we'll do this or do that when it comes through, because they're just different environments with different responsibilities in different people. Right. Having spent my entire career working with enterprise customers, you have to meet them where

they are on some level. So they're on a journey, right. They're on a journey in cloud adoption, they're on a journey in Kubernetes adoption. They're using different observability and they're adopting more like a lot of them are on a journey with open telemetry, right, and trying to figure out how to bring that in a more standard way across their environment, because they know that

that's a direction the industry is moving in. All of that's happening in the background, and you know, our job is to make sure that it doesn't really matter that where the customer is in that journey, we're able to kind of meet them there and provide them with the things that they need. And as much as we can build things into the product, you know, automatically,

the better. And also to a certain extent, sometimes it's aspirational, Right, you have these customers who are like, we really want to move in this direction, and this actually is going to help pull us forward, right, Like the fact that we're going to be able to see all of these different service dependencies and all of these inter relationships is something that we know we want to do and that this is like, here's a great use case

for what you're going to do with having that information is you're going to be able to see more causal relationships across all of that. And that's it. That's exactly not it's useful data. That's exactly right. Folks, don't touch out. That will be right back with Ellen Rubert of causely Ai. You're listening the Inside Analysis. Welcome back to Inside Analysis. Here's your host,

Eric Tabanac. All right, folks back here on Inside Analysis talking all about causeal Ai with Couseley dot Io and Ellen Rubin and Ellen, we were talking about the people, right, every company is people. A lot of people say it's the technology, it's the hardware, it's the software, all this stuff. That's true, but really a company is built around the people.

And one of the coolest things I've noticed being in this industry now for you know, twenty five almost thirty years or so, is that you can see the progression of individual professionals from one company to another. They learn things, they learned about this situation, that situation, and that becomes part of the fabric of their view of the world. And that's how you can learn how

to bring things together and create whole new projects. And I think what you've done here is very interesting because you came at it from a different direction. Like a lot of this stuff is inside out almost you refer to it as bottom up. I'm always going to say it's more outside in because you're like or maybe it's the maybe it's the inverse. I'm not sure. But the point is you figured out a different way to address this issue. And the

people are the ones who came up with that. So who who got together to create this besides you? Thanks? Yeah, And I agree with your analogy of it being you know that it's outside in instead of inside out. So I like that. I think the people in this case, you know, I mean, look the founding team is always critical. And the reason founding teams start something is because they had a problem that they saw, they wanted to solve it, and they think they have something interesting to say,

you know, to bring to the table. So in my experience having started several companies and you know, as you mentioned, being part of some other you know, startups, from from the very beginning, this team is it's pretty spectacular. So we have my co founder, schmul Kleeger, who was the founder of most recently of a company called Turbonomic that was acquired by also

biog. Yeah, so they were you know, they had this fantastic, you know, two billion dollar outcome with with IBM, but before that they had taken on a lot of issues about IT operation and how you are able to automate initially in a VMware environment, and then they kind of moved out and you know, made it a broader problem set and so a lot of this idea of automating IT environments and making sure that they're working really well.

They solved a lot of it, and it was kind of more focused at the infrastructure layer, right, That's where a lot of the work was done prior to that Schmuel was the under of a company called smart Son if you remember that company. They were in the root cause analysis for network management and they were acquired by e MC and that was also a really successful outcome.

So it was kind of like the people who are the founding team. There's a huge amount of DNA from Turbonomic and also from the previous company Smarts with this root cause analysis expertise and knowledge that was applied back in the day to you know, a completely different world, you know, much more monolithic on prem static, you know, all these things that were going on, but the building blocks were the same as the things that have been brought to Cousely

and then large scale, enormous IT environments you know at Turbonomic that needed to be managed and run in a way that you know, took away a lot of the pressure from the people who were having to do these things as you know, as initially VMware and then Cloud became you know, hugely deployed.

So that's that's a good chunk of the team. And then for myself, you know, you mentioned Natisa, which is you know kind of back in the back in the day and data where housing, but I also after that started a couple of my own companies that were very focused on hybrid cloud and being at cloud infrastructure layer and understanding, you know, how do you create environments that span on prem into the cloud or multiple clouds, and how do

you manage that as they grow? And it kind of culminated for me as a general manager. My previous company was acquired by AWS and so I found myself, you know, within the hyperscaler world, you know, as opposed to competing with or partnering with or whatever, I was actually inside running very

very large hybrid cloud storage services. And so the experiences that I had there were the ones that are pretty formative for me for wanting to start causely, which is what it feels like to be that owner of the service, you know, as the Amazon model is, you know, very much focused on service owners and small teams and you know, like you know, really like you build it, you run it, you own it, all that kind

of stuff. So doing that at global scale and having things break all the time constantly, and it wasn't even just necessarily your services, like you made some changes, something happened, but then like three other services had other things going on and they impacted you and you were dealing with the impact of it, and so you know, on call, being paiged, trying to pull

people together from different teams with different expertise. You know, if the right person wasn't available, you could get yourself into a you know, a difficult place to you know, to get to the root cause. So I like to say, like I live that, so I know, I know how

that feels. And then the people who are the founding team you know school and the founding engineering team that that that has have built this coretu causally ey core platform and also you know, the the products that we're building around it, you know, like they they have what I would say is like unfair advantage in understanding how you build this stuff and how you do it leveraging causality.

So you know, so it's exciting and it's very cool. And you know we're doing it as a remote company, so that's that's new too. We're like, you know, we're remote from birth and you know, doing it you know, around across the US and hold internationally and stuff like that. So it's I think it's say, it's never dull, never dull well And you speak to being inside a w WES and of course owning the product, owning the service. So when something goes wrong, well, it's it's

up to you to figure that stuff out. And I see this time and time again in the enterprise software world where someone experienced a very hectic situation or a very challenging problem in a past life and they go, aha, I know how to solve this. And oftentimes they try to solve it within the organization. They maybe make the pitch to the executives, they say, hey, we want to do X, y Z. Sometimes it happens a lot of times it doesn't, and so what do they do. They spunter off

and start something new. And I know for sure in the software world the kernel is so important to understanding what you want to build, and building a foundation like the kernel, which you've done here with these structured causal models, is very important. Well, I'm a big fan of cliches. One of my favorite cliches is, well, begun is half done. Right. If you get off on a good start, you're halfway there. But if you don't, you could be spinning your wheels for months, weeks, years.

It happens. I mean, I'm sure you've seen projects at big corporations where you know, they launch it, they have all these great plans and it just goes sideways. They never get there. Millions of dollars wasted. That's painful, painful to see and just and not good for morale. So what I like the most about your approach here at causeley dot io if you want to look it up online, folks, is that you've you've focused on causality as the core of the problem, because that is what gets you to your

answers. If you know the cause and you can see the effects, because that's what we're talking about, right, you see the effects, you have a model that can then understand, oh, though that array of effects means X, and that X is the cause, right, definitely, Yeah, And you know a lot of it is helping customers see the difference between when you know the causal relationship ships and when you do right, Like that's that's

a key thing. And so intellectually people understand that this is something that is different or it's hard, or it's new and all that kind of thing. But to a Llergic extent, what they're sort of saying is, well, I've built a lot of stuff, and I have a lot of tools, and I collect all this data, and I have all these people that I've trained, and I have these run books and you know, like it's it's layers and layers of technology and process you know that people have had to put.

You can't run large scale applications without that today, it's just impossible. You would have to have a lot of things in place. And so what we're essentially trying to do is sort of break the paradigm and say, Okay, that's the way you do it now, and it you know, I mean, it works to the extent that you keep things running, but it brings these things into such a physical, manual like human place on a daily basis. And what if the answer was that these things were just happening automatically

and you didn't have to think about it anymore. And how would that feel? And that's a very like, it's a very stark Comparison's our that's our job, right is to make that really visible and clear well, and it gets you on the path to productivity, right, because the kinds of things you're solving for are nuisances. Quite frankly, they are not on the critical

success path of designing something new. They are hurdles that you encounter along the way, Hurdles that result from someone else's code, sometimes it's from your own code, sometimes it's just the environment. But basically, when you're fixing things, you're not building something new. You're just trying to put out fires all day and back to morale. That's not good for morale, it's not good for anyone. But I do understand and appreciate the mindset change that needs to

be embraced. You know, I've heard lots of different ways to describe this, but you know, in terms of following an algorithm and just believing what it tells you, we do that all day with our smartphones. In the maps, you're just following along with what it tells you to do. And I've learned that it's a trust experience, right, Like at the first time, they're like, wait, where are we going? Right? You know?

And then of course right. Although I will say that I've learned with these maps they have difficulty in very short spaces, like if you have to get around somewhere, they're not able to figure out, hey, just pulling a parking lot to turn around, like I've done this several times, Like okay, now he wants me to go up on the highway and around like this. Now I'm just going to turn around and go back, so you'd have to kind of watch out for That's this bit of an off kilter analogy,

but point being, we're following what they tell us. We're listening to the bots as we walk down the street. Okay, turn this, turn left, turn right, So you're solving for that at a foundational level, for the cause of these things and these causes. Man, the other way of doing things, the traditional correlation way, it can't get done. It does get done all the time, but it takes so much time and so much effort and so much lost time in production. Right. So well,

folks, we got podcast bonus segments coming up here next. Send me an email if I want to be on the show. Info at insideanalysis dot com. We've been talking to Ellen Rubin Ofcousely costly dot io. Be right back for the podcast bonus Boks. Time for the podcast bonus segment here and a fantastic show solving the observability conundrum cause and effect. We're talking to Ellen Rubin

of Coslely. It's coosely dot io on your internet browser. If you want to learn more, and I wanted to talk to you Ellen about one of the coolest things I've seen happening in this industry, and that is open telemetry. This is just a couple of years ago that it really took off. But I love this movement. I'm a huge fan of open source software. First and foremost hats off to Alina Stour of AOLS with Linux. But now

there's a whole stack. I mean, you and I have lived through this, the had dupe movement, the open source movement really climbed up the data stack, and this whole spirit of openness is I think very powerful and very good, especially for highly spread out teams of people working on stuff. If there's transparency, there's trust. When there's lack of transparency, lack of trust

kind of creeps up. But this opens lemas to stuff. I think it is fantastic because it's a standard and this and everyone is now moving towards this standard, so we can all see what everyone else is working on it we can at least benefit from this data source. What do you think about all that? I think it's huge, and you know, it doesn't take me

to say that it's catching on. It in a big way. You know, you can see the statistics, you know, in terms of how much interest there is and how many people are participating in a lot of big companies that have gotten involved with it. And in the observability world, you definitely see that the kind of the large observability vendors have now adopted it because typically in the past they had some sort of a more proprietary way of capturing data

and stuff like that. And it's not new, right, you know, the APM tools have done that for a while, but they've all realized that this is the future and that the customers are asking them to adopt this more you know, kind of open standard that then can become the kind of the

source of a lot of that information. And so that's great. I think it's really good for customers, it's really good for the industry, and it provides that visibility that's been super hard to have, right in terms of all of these relationships us in an environment that tell you, you know, sort of what's connected to what and why, you know, like they're there are those types of things that are just not visible from the more traditional observability tools.

The thing that we've found that's been very interesting is that in spite of all of that excitement and interest, the adoption of open telemetry has some challenges to it, right, you know, in terms of there are changes you have to make to your application and things that you need to do that take time, and you know, people are I guess what I would say is people are taking this approach again in which they feel that then they need to

apply the open telemetry you know, to everything, like it's like a banket thing that they need to do, and then they go, oh my god, that's a huge amount of work and also, oh my god, the amount of data that's going to be generated, what are we going to do with it? Then we have to store it and we have to figure out how to access it, and you know, it becomes it becomes a data

management problem on top of everything else. So there's often pushback in terms of how quickly and we see this in some of the larger customers we're working with of the adoption path, Like we know, we want to move in this direction, and we're going to pick certain applications where the benefit of doing it is very high, and we're going to start there and then essentially we're going to like take on the challenges of making that work for these particular applications,

and we're going to try to figure out how to do it in a more cost effective and optimize type of a way. But that isn't like a quick like you know, press a button and everything's all set right, So see that there are these other open source projects that are meant to help with that. So, you know, eBPF is obviously something people are taking advantage of, you know, to try to see things. You know, people are using. Odegos is a project that we're familiar with where it kind of automates

more of the open telemetry process. So there are different types of projects and tools that are out there to help make it faster and easier and less you know, kind of physical labor to be involved. But I guess I would say that one of the things that we believe is that, just as with all these other things that people have put in place, throwing tons more data at people to then try to analyze is again not the answer. It's like

the thing. And one of the things that I was reading recently in an article about open telemetry was you should know what data you're looking for, and then you should optimize for capturing that data so that then you know what you're actually going to be learning and seeing, as opposed to if I just can see everything, then one of my what will it tell me? What will it teach me? Like like how many times do we need to do this

before it becomes obvious? But like this much more sort of like you know, needle in a haystack and looking for very particular things that will tell you the answers to the questions. It requires some more planning and thinking up front, and I think that's where the answer to this lies, because otherwise, you know, you're sort of back in the same thing, which is I have all this data, nobody ever even looks at it. I don't even know why I'm storing it anymore, and that that would be a shame for

that to be the case. So we're kind of use it smart, use it efficiently. You know. That's that's well, I'll tell you what I'll close on this. I'd be curious to hear your thoughts in this curveball question. So I love the open of lemon because again, it's transparency. We can all see what's going on at least eighty percent. Let's say, what's actually happening, and then I'll choose my twenty percent of that which is meaningful

to my business. I would love to see open standards in the marketing world, in the digital marketing world in particular, because the numbers are off the charts. I almost put together a talk for the Data Universe conference called SAT. It was called lies, damn lies and SaaS statistics because they're just all

over the map. I mean, like with YouTube or Instagram or these various engines, we throw a little money at it and all the numbers bounce off the page and like, well, what did I actually just buy there? Like it's hard to get to the bottom of things and to correlate, you know. And I've learned how to read through the data that I get from my email marketing tools, just from usage patterns, so I know, okay, the clicks I see in the first five seconds of cent of this email

probably spam filters, probably you know, some firewalls kicking into place. But being able to make sense of the numbers is really important for mark and I haven't really seen much of a move around that. And it's like, well, Salesforce could do it, or Marcato or any of these guys, but no one seems to do that. Do you have any thoughts on that and what do you think about getting some more transparency into what these numbers actually mean

and how they're generated. I totally agree with you, and you know, everybody who's in the IT world deals with these issues right about trying to like, you know, tell your story and get out there. And you know, we're all using a lot of the same platforms and stuff like that. But to me, it sounds like an idea for a new company, so you know, off you go go. I actually know a senior executive who hinted at starting a new company, so maybe I'll lean on him to get

the ball rowing. He knows a lot about Marcato too, because when you know better, you do better, right, And I think that's the key with what Cousley is doing and what this future company I'm thinking about is doing. I just want to know what's happening. I want to know what's happening, and I want to know what do you need to do to fix it? And even better, you want somebody else to fix it automatically. That would be great. That's right. Well, Allan, thank you so much

for your time. Look her up online on LinkedIn, Ellenreubin costly dot Io. You've been listening to Inside Analysis, Marino Valley, Corona and Riverside. Listen to kaa kaa, the station that leaves no listener behind. Redlands Ranch Market is a unique, full service international grocery store that specializes in authentic food items from Mexico, India, and from many Mediterranean and Asian countries, including

popular items from the US. They offer fresh baked items from their in house bakery, housemade tortillas from their tortill area, a delicious array of prepared Mexican foods, a terrific fresh food and juice bar, and a large selection of meats, seafoods and deli sandwiches, salads and hellal meats. Their produce department is stocked full with fresh, local and hard to find international fruits and vegetables

that you cannot find anywhere else. Don't forget to step into the massive beer cave and experienced the largest selection of domestic, artisan and imported beers in the IE. They can also cater your next event with one of the delicious takeout catering trays of food. Visit them at Redlands Ranch Market dot com. That's Redlands ranch Market dot com. Redlands Ranch Market a unique and fun shopping destination. To Hebotea Club's original pure power to rcosuper tea comes from the only tree

in the world that fungus does not grow on. As a result, it naturally has antifungal, anti infection, anti viral, antibacterial, anti inflammation, and anti parasite properties. So the tea is great for healthy people because it helps build the immune system, and it can be truly miraculous for someone fighting a potentially life threatening disease due to an infection, diabetes, or cancer. The tea is also organic and naturally caffeine free. A one pound package of

tea is forty nine to ninety five, which includes shipping. Do you order, please visit to Heboteaclub dot com. T hebow is spelled tea like tom, A, H E E B like boy oh. Then continue with the word t and then the word club. The complete website is to hebot club dot com or call us at eight one eight six one zero eight zero eight eight Monday through Saturday nine am to five pm California time. That's eight one

eight six one zero eight zero eight eight to Hebot Club dot com. If you're looking for a fuller, part time sales position and you have radio, TV or print media experience, KCAA has a great opportunity waiting for you that pays the highest commissions in the market. If you're interested in a sales position with us, email CEO at KCAA Radio dot Com. Kca with sixty years of fascinating facts. This is the man from yesterday and back in time.

We go to this time in nineteen eighty two, Apparently Tommy Twoton's new hit tune eight six seven five three oh nine is ringing up problems for those with the same phone numbers. In Cleveland, a lady called a radio station to ask why hundreds of total strangers have been calling her asking for Jenny. And from this time in nineteen fifty nine, ABCTV says it's going to air a new cartoon called Rocky and his Friends with Oatwinkle the Moose. It begins this

fall. It'll air late afternoons on ABCTV. We're gonna have a lot of fun. Come on and join us, juree. There's only room for one more. And from around this time in nineteen seventy one, Andy Griffiths new show is a dud. It's only been on CBS since January here in nineteen seventy one, and it'll be canceled by the end of May. The new Andy Grisha Show brought to you by with more at Man from Yesterday dot Com.

For over seventy five years, the Marine Toys for Tots program has provided toys and emotional support to economically disadvantaged children, primarily during the holidays, but needs are not just seasonal, and now neither is Toys for Tots. They've expanded their outreach to support families in need all year long with their new programs, including the Foster Care Initiative, the Native American Program, and the Youth Ambassador Program. To learn how you can help, visit Toys for Toots dot

org. Hi, I'm Lanni Swarodwow, and I'm back on KCAA ten fifty AM and Express one oh six point five FM every Tuesday at eight pm. My show is Beyond Common Sense. It's Lanny Sense featuring me Lanni Swardlowe, kcaa's resident gay, Jewish liberal potsmoking race mixing, left hand atheists, an evangelical fundamentalist, Christian nationalist, worst Nightmare with subjects that no one else will

touch in quite the same way. Every Tuesday at APM on Express one oh six point five FM, the Legacy ten fifty AM, and live streaming on kcaradio dot com. KCAA Radio has openings for one hour talk shows. If you want to host a radio show, now is the time. Make KCAA your flangship station. Our rates are affordable and our services are second to none. We broadcast to a population of five million people plus. We stream and

podcast on all major online audio and video systems. If you've been thinking about broadcasting a weekly radio program on real radio plus the internet, contact our CEO at two eight one five ninety eight hundred two eight one five nine nine ninety eight hundred. You can skype your show from your home to our Redlands, California studio, where our live producers and engineers are. I need to work with you personally. A radio program on KCAA is the perfect work from home

avocation in these stressful times. Just time kcaradio dot com into your browser to learn more about hosting a show on the best station in the nation, or call our CEO for details. Two eight one five ninety eight hundred NBC News Radio. I'm Chris Ragio. Opening statements are expected tomorrow. In former President Trump's criminal trial in New York, Judge Wan Mr Shan ruled prosecutors do not have to give advanced notice of the witness list, a Trump's legal team,

saying Trump cannot be trusted not to post about them. Trump has complained about his gag order, noting prosecution witnesses are allowed to talk about the case, but he cannot. Trump has accused of falsifying records to cover up hush money payments to an adult film star before he was elected. In twenty sixteen, the Senate will vote on a massive foreign aid package that'll provide military support to

Ukraine. Yesterday, the House passed a ninety five billion dollar legislative package that it would provide security assistance to Ukraine, Israel, and Taiwan over the objections of some Republicans. The bill now heads to the Senate, where preliminary voting could begin as soon as Tuesday. More Democrats are speaking out against threats to

remove House Speaker Mike Johnson. In an interview with Fox New Sunday, Florida Congressman and Jared Moskowitz said removing Johnson would only embolden foreign adversaries, including China, Russia and Iran. No, Russia and China are trying to destabilize the country, trying to stabilize the world, and we have to make sure the

United States stands for Western democracy. He slammed Georgia Republican Marjorie Taylor Green, who introduced a motion to a Kate Johnson's speakership last month over his handling of Ukraine aid and government spending. It's not clear if Green will force the motion to vacate to the floor for a vote. Michigan authority said two children were killed and a dozen others injured when a drunk driver crashed into a children's birthday

party yesterday. The Monroe County Sheriff says the vehicle drove into a building in the town of Newport, south of Detroit. Police say the sixty six year old woman behind the wheeld was in tuckicated and is being held in the county jail. Nine people, including six adults, were taken to hospitals with life threatening injuries. Police said the two children who died were an eight year old girl and her five year old brother. According to investigators, the driver's facing

a variety of felony charges. I'm Chris Karagio, NBC News Radio, NBC News. I'm CACAA Lomalinde sponsored by Teamsters Local nineteen thirty two Protecting the Future of Working Families, Teamsters nineteen thirty two dot org. You're listening to an encore presentation of this program KCAA The Inland Talk Express. Thank you for jarning this for this edition of Justice Watch with Attorneys Zulu Ali. I am Attorney Zulu Ali with the Justice Watch crew, Rosa Nunyaz, Michael Balao Clark,

and doctor Akhil Basher. Here, like each week or tonight, like each week, we'll be talking about critical legal and social justice issues affecting our communities. This week, the topic is

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android