How Fast Can Data Go? Pretty Darn Fast

You've heard AM, you've heard FM. Now tune into DM Radio, the world's longest running show about data. Each week, host Eric Kavanagh interviews the brightest minds in the world of information management. Want to be on a show?

Send an email to info@dmradio.biz.

Now here's your host, Eric Kavanagh.

All right, ladies and gentlemen, hello and welcome back once again to the longest running show in the world about data. It's called DM Radio. PM Radio, yours truly, Eric Kavanagh here with another rock 'em sock 'em all-star cast here, folks. We've got some industry veterans, some visionaries, movers and shakers. We'll be talking to my good buddy Dan Everett of Insightful Research, and we've got Bill French on board from StreamIt, and Sanjay Agrawal, who is now with Revify, formerly of ThoughtSpot. So 3 real smart guys on the call here today. We're gonna talk about fast data. How fast can data go? Pretty darn fast these days. Lots of cool things are happening. We're gonna try to talk about information architectures and streaming data versus traditional data paradigms or architectures. We'll also talk about cost containment. That has been a big interesting topic of late where, if you all will remember, the first sales pitch around going to cloud for many services was lower cost, it'll be less expensive. And it was at first, and then all of a sudden it just started ratcheting up. And what was the funny line I heard a couple years ago? Someone said the most ungoverned, line on your IT budget is your Amazon spend. Just look up, wake up one day like, holy Christmas, what have we done? Where did that money go? Yeah, kind of a problem. So lots is being done on that these days. And with that, let's bring in our first guest, Dan Everett, uh, of Insightful Research. And Dan, you and I have been around for a while. You were at SAP, you're in Informatica. So, you know, you've seen the big corporate world of, of data processing and ERP and of course data integration and data movement. And you've seen some changes over the years. I mean, as you you look at what's happened in just like the last 10 years, we've seen pretty significant disruption. And let's maybe talk about streaming versus traditional architectures. That's a big deal, right? It's a whole different way of doing things like Kafka, and there's Flink, there's Apache Pulsar I think is another one, there's Red Panda. You got a whole group of vendors now doing streaming data as opposed to traditional architectures. How do you see that changing the world, and what do you think about all that?

Yeah, it's, it's been a really interesting shift. And I mean, there's lots of different tools to do it. But I think really this, this, it's a whole paradigm shift, right? Because traditionally, it's like, let's just collect all the data and put it in a data warehouse or lake or whatever. And then we'll run our analytics on top of it. And I mean, that's fine for certain use cases. But there's other use cases where you actually need to change the paradigm, and you need to do the analytics as the data's streaming right out of wherever it's coming from. I mean, you know, 30 years ago, we were doing algorithmic trading with complex event processing and fraud detection, right? So it's not that, that this is actually necessarily new, the way we're doing it has changed and those sorts of things. But that, that shift in paradigm really hasn't. It's still sort of this subculture, I guess I would say, of sort of the data and analytics space. I don't know, how do you feel about that?

Yeah, it's a good point. I was mentioning before the call that from my perspective, and we talk to technologists all the time on these shows, there are some fascinating use cases for streaming data, but they all tend to be net new use cases. There was an example about, I think either in New York or some major city, the bikes, the bikes that you rent and how the bikes have little sensors in them. So it's an IoT thing and all that data is streaming constantly so you can keep track of where the bikes are, how long people have them, all that fun stuff. There are other ways to do that, but in that particular use case, it's much more efficient to go with a streaming solution. And it's kind of to explain to the audience out there what we're talking about is, you know, with Kafka and these other streams, it's this sort of publish and subscribe model where you get this stream of data and someone can subscribe to it, they call it topics. And then you just get this stream coming in. Now you have to have some way to land it and to use it, and that's kind of the point we were making in the pre-show is like traditional approaches like APIs, for example, weren't really designed to handle that kind of thing. So you need a socket on one end and a socket on the other basically to connect this stuff. But what's cool is that you can have 5, 10 people subscribe to a topic. So in the old days, we did all this ETL from one point to another point and then from this point to that point and all this sort of point-to-point stuff, whereas in this version, everyone can subscribe to a feed on where these bikes are. For example, the marketing department, the sales department, other departments can just subscribe. So from that perspective, it's significantly more efficient. But again, the challenge is being able to map that into a traditional architecture connected to the cloud, do all that kind of fun stuff, right, to actually make it work. It's a fair amount of effort.

Yeah, it's a it's a fair amount of effort. And right, it's how do you augment or complement, right? Because they're not one or the other.

Right.

You know, you just like, if we think about all the work around autonomous vehicles now, right? You can't, well, one, just because of speed, right? You have to make decisions, right, on the data that's coming off the sensors in real time, whether that's LiDAR or cameras or whatever it is about, you know, I'm not going to crash into somebody. To make these things safe. So, you know, that's one aspect of it. The other is, right, just trying to move, if we're just going to sort of use at the edge, trying to move all that data back to a central data store is unreasonable, right? Just the bandwidth and the cost of doing that, right, makes it unreasonable, right? So now we're really needing to be more real-time right out at the edges in these types of use cases. Making those analytical decisions right in the moment, right where the data is. Mm-hmm.

Yeah, and that's the key is understanding what is the use case. You make a great point about self-driving cars. You don't want to have to, like, take that data about your point in time where you are, ship it back over, you know, some network to the cloud where some analytics goes, oh, wait, you're about to crash, and then it comes back, crash. You know, it's too much time. You have to be in real time. And these, especially with the edge, right, with IoT, these are edge devices, you know, you have a whole different architecture, a whole different way of solving problems. There are more options for how to do that, but you do have to put on a much different hat and think very differently about how you're gonna get all this stuff done. So I think it just takes a special skillset and it takes a special mindset and frankly some courage, I think, to jump over the wall and do things in this new way. What do you think?

Well, I think that there's already pockets of people doing it in organizations, right? I mean, it's not like it's not out there. I mean, when the internet started, I know there's probably people listening that like, oh, these guys were from before the internet. They are around Lincoln's age. The internet came, right? And then we started doing recommendation engines, right? So those are actually real-time processes, right? What's in somebody's cart right now? What do they put in there? Right. And that whole transactional type of processing of carts and shopping online is, you know, needs that sort of real-time type of thing. So it's, it's not like it's not there already, but it's really about how do we, how do we, like you said, understand the use cases and then bring those teams that are working on these things together and make sure that we're really looking at our architecture holistically versus, you know, I've got parallel paths and I'm creating problems for myself down the line because I'm not really looking at how to bring these things together in a more holistic way.

Right, right. And that's the key. You got to bring all this stuff together. Well, stick around for the roundtable. Let's bring in Bill French from StreamIt. Bill has a lot of experience in this space, too. And we were talking before the show about how the API, the application program interface, which is the sort of de facto mechanism of communication in the cloud these days between different applications, different environments, how those APIs were not really designed to handle streaming data and how we may need to use WebSockets. Tell us a bit about that and what you're working on, Bill.

Yeah, I mean, all of this kind of circles the drain, if you will, in terms of the definition of fast, right? If we step back for a minute and we say, well, what is fast? We use that term real-time, which is probably one of the most abused words in technology. Transit organizations who have bus schedules or the location of a bus that is updated in quote real time every minute. It's a very different definition than the definition you need for real-time event handling inside of a full self-driving vehicle like a Tesla. So we have to kind of get our head around what the definition of fast is. But there's one thing that's certain: REST APIs are slow. They have a great deal of latency and they are often uncontrollable. Sometimes they're slower than normal and sometimes they're faster than normal. But at the end of the day, those architectures are designed to listen for a request process the request, and send back confirmation that the request was completed. But when we think about real-time data, none of that really can occur. And so a WebSocket environment, or at least an HTTP API that has a long-standing request-response capability, those are required. So there are ways to take a traditional REST API and make it faster. But it's not really as fast as what we'd see in like our messenger apps where we were texting our brother or our parents or something like that, our kids. These texting apps are instant. We know that from experience. And fundamentally, the world of data has piled onto that, right? So that the very first instances of real-time data, of course, go back to the '50s with telemetry and rocket science and things like that. Telemetry is, you know, the first example of real-time data, but in a consumer sense, we've proven this real-time data for a long time. And when I say real-time, I'm talking about a particular threshold I refer to the Doherty threshold, which I believe was some research that was done in the '60s, maybe '70s, where they determined that a human senses a delay at about 400 milliseconds. And so if you can't keep up with 0.4 of a second, then you're not cutting it, basically. And I think as humans and consumers of the information society that we live in now, we have to get at least to that Doherty threshold. So 400 milliseconds is kind of— it's the standard I kind of work with. But now there are use cases, as you point out, you might need 4 milliseconds, right? And so that opens up another very huge can of worms. So I hope that kind of framed, you know, the idea that You know, we're, we're in a new world and that even that new world, we can't really agree on what real-time means.

Yeah. Well, that, this is all fascinating stuff. And it, I think the challenge for a lot of organizations now, especially companies that have been around for a while, is to leverage some of these new technologies. You're creating this divergent world now, right? Where that you have a traditional architecture with a traditional mindset of, persisting data in your database, for example, in your NoSQL database or whatever it is, versus streaming, which is real-time. And those don't tend to play together very well. There is this classic impedance mismatch, right? Which then you just have to solve in some architectural fashion, right, Bill?

Yeah, that's correct. We might say that the interchangeable parts don't. I know that's not a complete sentence, but it proves the point, right? These are some allegedly interchangeable parts and they don't really commingle very well. A lot of good research though has yielded some really powerful benefits. And so when we think of a real-time network, you know, such as PubNub or some of the others, Kafka is another good example, there's plenty of helper libraries that help you put data in, to those networks and pull data out of those networks. So there's a tremendous amount of, of good technology available to use these in practice. We don't have to look very far to realize how good that is. And I think your earlier comments— and by the way, Dan was spot on when he kind of unearthed that and caused you to say, wow, it could be many different departments within a company or an organization looking for the location of those bikes or scooters or whatever. We don't have to look far to see examples where 50,000 people need the same data at exactly the same moment. Right. Who would that be? Anybody playing a game, right? So the gaming industry is the fundamental proving ground of how you synchronize tens of thousands, perhaps even millions of people at exactly the same instant. They all have the same data. Right now, this applies, of course, in financial trading. It applies in gaming. It even implies, you know, applies in marketing and content distribution. So I'm pretty impressed with the way the technology industry has expanded and reacted to you know, the need for fast data.

Yeah, and I will say I'm glad you brought up the gaming industry because what a pioneering discipline that has become on so many levels. Yes. I mean, just look at the GPUs, right? So because of all the gamers, we have tremendous innovation in the space of graphic processing units. And then someday someone woke up and said, wait a second, I can use this for analytics.

Right?

Because it can be parallelized and all of a sudden, boom, there's this another whole renaissance in how to do stuff, right?

Right.

And then when you inject into the conversation the concept of real-time analytics versus very latent or after-the-fact analytics. In transportation, for example, there's a lot of people that want to know long after these events have occurred, how many Mercedes are going by this intersection? Should I put a Taco Bell there or should I put an upscale restaurant there?

Right.

That's after-the-fact analytics. There are analytics that need to be done at the edge. And when you say the edge, it's not just about IoT. At StreamIt, we coined the phrase IOR, and that stands for Internet of Recognition, because increasingly we want vision to supplant, or at least play nicely with, sensors. It doesn't help if a sensor can tell you that the device is reaching a boiling point, because once it passes a certain temperature, it's going to stop. Whereas a camera at some juxtaposition away from that incident is able to tell you what color the flames are, right? Long after the flames begin. And so that kind of information at the edge needs to be determined without sending video somewhere else to process.

Interesting.

At StreamIt, we do exactly that. We take video at the edge and interpret it at the edge. You need to have AI at the edge in the stream, literally as the data moves through the stream, the cloud. Most companies focus on one of the three, usually one of the two, the edge or the cloud. We focus on all three because we realize that there are AI inferences that should be made while the data is in motion. And that needs to be done, by the way, in the 250 milliseconds we give the data to start and end. And so those are very complex ideas, but The technology is there to solve it.

Yeah, that's so cool. It really is an exciting time, especially to be an enterprise architect, right? And that's a big title in our list. So the people that we market to and we cater to, they love that stuff because there are so many opportunities now. There are so many ways to do things. It is a bit complicated, but if you get the right people doing it the right way, it works extremely well. Folks, don't touch that dial. We'll be right back. You are listening to DM Radio. Hands-only CPR video at heart.org and become a hero.

Welcome back to DM Radio. Here's your host, Eric Kavanagh.

All right folks, welcome back to DM Radio, talking to 3 experts about fast data, what it does, how to get it, different architectures, all kind of fun stuff. And next up we have Sanjay Agrawal, CEO and co-founder of Revify. That's revify.com. And I said FinOps, it's not quite FinOps, it's data operations, right? Tell us a bit about that. What are you doing? How did you see the opportunity? And what are you delivering for your clients?

So yeah, let me sort of build that story. Eric here. So one thing we, we are extremely passionate about is, you know, how do you help the data teams, you know, bring the right data to the right, at the right time, at the right cost. So all of these elements are, are part of what we refer to as the Data Operations Cloud. But the idea is very straightforward, and this is best summarized by what our customers, you know, articulated about us. And what they said is that with Revify, now my data teams can sleep at peace at night. That's the key essence. And then we can break it down into 3. So, so there were 3 pieces to this. The first is that, you know, how they said, you know, we had zero escalation from businesses to data teams, which is like really a strong testament which is about, you know, us watching out for the data quality and bringing it to the forefront. It's like a lot of these things you talked about, I believe also will refer to, you know, a difference between an early warning system, which post and pre. So one is that how do you tell them, you know, that this problem is likely to happen or it's important to look at it now because your business is going to look at it very soon. So get on it. And that's, that's a huge thing. And naturally, and then the second piece there was around, you know, how do you help them cut costs? And I know in the beginning you talked about spend and we can go into that, but yes, when we look at it 10 years ago, it was all about how can cloud lower the cost, whereas, and now it's a very different discussion.

Yeah, that's right. So things change, right? Well, I mean, lots of things come into play. I mean, I'll throw a little curveball here just 'cause I think it's kind of interesting. Look at the observability space and how observability has exploded in the past 3, 4 years. Which I think is largely because of the success of Kubernetes, which is a brilliant project out of Google, distributed compute, right? There's so much activity in the observability space that there's now a vendor that sits on top of your observability data to help you transform and optimize where you store it and how you store it, a company called Mesmo, we did some work with earlier this year. So it's like, that's a pretty fast maturation cycle that you have all these vendors doing observability, then you have a next layer up, an abstraction layer up on top of that about how to orchestrate all that, to help you save time, save money, and in the long term not get your, you know, your, you know what handed to you on the cost of storing all that data. Because at first it doesn't cost much, and then after a year and 2 years it's like, wait a second, what are we holding on to here? And that's very hard to unwind. So if you look at where things are going, the cloud, and again, in the last few years has really taken off. And frankly, I credit Satya Nadella, from Microsoft with pushing that company forward into the cloud. Because previously, you know, I thought cloud was gonna take off in like 2008 and '09 and '10. It just kind of didn't. It wasn't until Microsoft pushed full force and then all those Microsoft shops were like, "Oh wow, I guess we do have to take this stuff seriously." And now they do. And of course Google is getting involved, Google Cloud Platform. So we're there now, but there are these other issues like SuperCloud and MetaCloud and other ways to manage it. And I think you folks are right at the center of this conversation for helping companies understand how to leverage these complex environments and how to do so in an efficient way, not just to save money, but to have better data quality, have better processes, right?

Absolutely. I, I think you have, you've very like beautifully captured the key essence, right? In fact, one of the key conjectures we had was that data observability, like, as it's like a really passive term for us, right? It means that you're just looking at That's right. I mean, I just— I'm sorry, but it sounds too funny.

I get it.

That's right. But it just feels that, you know, you need to do better than that. So when we started, we thought, you know, it's important, it's necessary, it's not going to cut it. So, and the second thing we said is, you know, just give a very simple example. It's like so intuitive that we say, well, quality is important. Well, you have a problem. Your data didn't get on time today. Maybe it's delayed. So what, should I fix it? The answer sometimes is no, you don't need to fix it. If nobody is using it, you're throwing this data out. If there's nobody catching it, the best decision is not to try to fix it, is actually to get rid of it. And then it becomes a cost thing also. Then you get the benefits. You spend too much time processing a query. Very classic. You're talking about historical— your talks about, you know, we talk about data performance and all. Longer you take, the more it costs. This world is so interconnected. That's why Revify, the data operations cloud we started, we said you cannot create another silos. You got to walk the lines of a data team and bring all of these 4 pieces together, which is the quality, the spend, the usage, and performance. I think you brought it so well. So thank you for doing it.

Yeah, no, absolutely. And you know, when I think about this stuff, and you know, we don't want to get too far afield here on the topic of fast data and data ops. But again, there are so many different ways that you can architect a system. And I think now really forward-looking people are looking at the workflows and the processes and thinking, OK, do we really have to do all these steps? I think to myself, even in the cloud data warehousing world, which of course is white-hot these days, you've got Amazon with Redshift, you've got Snowflake, you've got Databricks, which is on— it's like a juggernaut these days. These guys are doing amazing work. Of the three of them, Databricks seems to be the most cognizant about the power of generative AI by virtue of, uh, Ali Ghodsi buying MosaicML for $1.2 billion or something like that. Like, okay, fastest billion-dollar deal ever made, right? But my point is that there are so many ways that you can solve problems now, so many ways you can get signal from your data, that I think a lot of the heavy lifting we've done traditionally in data warehousing is not going to be as necessary. It's, it's not going away. We're, we're going to have data warehousing until the end of time, I'm quite sure, But I think that the heavy lifting necessary isn't what it used to be. And I'll just give you an example of a story I heard just the other day, I guess it was on Monday at Dreamforce, how— who was it? Snowflake announced that they can now connect to Salesforce and let you see into all your Salesforce data without having to ETL it. I heard that, I was like, yes, we're finally getting somewhere. I'm dying to know how they're doing that. But, you know, the— it's funny, in the first year of DM Radio, I remember when I was wrapping my head around ETL and all these batch windows, and I'm thinking to myself, this madness has got to stop. Because what happens is you start with X number of batch windows and ETL scripts, and it just grows over time and grows and grows. And then, you know, after 10 years of doing that stuff, you've got hundreds, if not thousands, of scripts running to pull data all around. And there was no strategic view of how many times you were moving the same data around and around and around again. I mean, there are other ways like CDC to do it more efficiently. Recently. But the point is, ETL just went off the map. It is crazy. And I think that's finally starting to stop, or at least to calm down. But what do you think, Sanjay?

No, I think you have— in fact, the best part is that we have seen evidence of this across the board. It's, it's like everywhere. So we are— one of our customers is a public company. It's, uh, I think very interesting in the space all of us are talking about. But, but the part which they said, you know, I really wanted to understand that, you know, why, why, why do— what do they really care about from the data side? And what they said is that, you know, over this many years we have built so many reports, we have processes, they're just pumping data into these tables and this going from here to there. We have no clue.

That's right.

Which one should I remove?

That's right.

You know, absolutely rightfully said, you know, the world has completely changed, right? In about 20 years ago, all of us, we can look back and say the amount of data you had in your warehouse was by and large controlled, like, because there's a data team, very controlled ETL systems. And yes, it would take you 6 months in the best case, you know, to get data in, but it was a small set. But if you got it, you're fine to a large extent. I mean, that also is another story. But now if you look at it, like, if a small company we are talking to, they were having like 50 data sources getting into Snowflake. To create a marketing site. My belief is absolutely on the lines of what you have said, that the amount of data which is just flowing in and how people want to use it, their hunger for data is so immense now. But it does lead to challenges because the shelf life of the data is now perhaps much, much smaller than what we are used to.

Right.

You really have to build everything keeping that in mind.

Yeah.

Yeah, that's right. Well, it's a time to redesign things and maybe I'll bring Dan Everett back in to get the roundtable started here, and then Bill French as well. And then we've got this GenAI stuff too, which is also fascinating, and it's just everywhere. It was all over Big Data London. Everyone I'm talking to says it's all over the place. And it is very real, and it's just a first phase. I mean, this generative stuff is phase 1. Interactive AI is probably the big phase 2, which is knocking on the door. It's right around the corner from us. But when I look at, again, fast data, using data for analysis, coming up with bespoke solutions that work for your organization. This GenAI stuff is very interesting in lots of ways. And I'm going to throw out one of my theories and see what you all think about it. I think in many ways, GenAI is a second chance for data. So if you think about how you can make these GenAI models work and not hallucinate, which is the big problem, it's all about the embeddings. And it's all about having the right embeddings as a foundation. Like a good buddy of mine I'm doing some work with, Eugene Burke, came up with a great concept. He says that these— large language models don't have an epistemological boundary, meaning they don't know what they don't know. And that's the problem. So if they know what they know and what they don't know, then you can avoid the hallucinations. The hallucinations occur because it doesn't know what it doesn't know and it just makes something up. And that's what it's supposed to do. In fact, the guy from OpenAI who is the go-to-market guy, when I was tweeting And the Databricks conference, a girl was talking about how you don't want to use your corporate data and all this stuff. And he got offended. He goes, we don't do that. They know we don't do that. And I said, because I had him on the line now, I'm a journalist. So I'm like, hey, what about these hallucinations? And he said, remember, it's more of a feature than a bug, right? And I'm like, well, that is a very good point, but what are we going to do about that, right? So I think it's in the embeddings. It's in layers of embeddings that you sort of build in your hard, fast foundations, your moorings or as Brian Raymond of Unstructured Audio calls them, anchors of truth. Oh, I just love that term. I'm going to be using it forever. Dan Everett, I'll throw it over to you. Take any of that and comment on it.

Wow, that was a lot you threw out there.

I know.

But, you know, I think that's why seeing people starting to look at augmented retrieval methods like vector databases and knowledge graphs and semantic layers to really hone in on, right, on that hallucination problem, as well as, you know, I mean, creating ontology so that there's a little more context and understanding of, you know, what the question is really trying to get to. But you're right, I mean, we're just at the beginning of this. And it's really interesting to watch in the last few months, right? And when I was at MIT CDOIQ in Boston in July, everybody was talking about it, but they're all trying to figure out, like, how do we, how do we actually use this, right? Where are the business use cases? Then how do we do it compliantly, right? I mean, you know, secondary processing of data, you know, from GDPR perspective, right? They just had that Meta ruling in July, right? So I mean, that's the real threat I think to AI at this point is having access to the data and how do we manage that trade-off between privacy and utilization in a way that it works for everybody? And that's going to be a challenge going forward.

Yeah, that's absolutely a challenge. That's right. And Bill French, Since you've been around for a while and I've done a lot of cool things, uh, I'm going to throw one of my other theories at you. So I'm looking at the healthcare world and the medical field, and, uh, for various reasons. And you think about the— all the MRI files that these companies have to store, and these are extremely heavy files, and they're burning them to disk still and doing things the old-fashioned way. Well, couldn't you vectorize images like that and then store the vectorized image in, in a faster, like in a vector database somewhere, and then just put that big-ass honking thing on some slow cold storage system somewhere where it's significantly cheaper for lots of different reasons. One, it's less expensive. Two, now you can do analysis across all these things and look for patterns, like for MS or Parkinson's or all these kinds of diseases. Once you do that, you've not only saved yourself a ton of cost, but you've also created this new really fluid environment for analysis. What do you think, Bill?

Yeah, and oddly, Google is doing exactly that. I mean, they've leaned into the medical research segment with exactly that architecture using vector embeddings, text embeddings. So I agree with, you know, the other guy that you were talking to. That is the key. That's the answer. And we can see that today. If you've managed to get a hold of Bard and the latest updates, you can prepare for a podcast like this in an instant by simply sending Bard a prompt that specifies @gmail in the prompt to use all of your Gmail history to answer a question or a query. So I can say, you know, show me every email that I've conducted with Eric, you know, over the past 2 years concerning this topic. If I throw @gmail into that prompt, Bard will give me a complete dissection of that which we've conversed. But it goes beyond that. Because if I add into the prompt and isolate all of the different items, we'll pick that up after break.

Yes, we'll pick that up after the break. It's such cool stuff. It's fundamentally changing discovery, which is my favorite part of this whole industry. We'll be right back, folks. You're listening to DM Radio.

Welcome back to DM Radio. Here's your host, Eric Kavanagh.

All right.

Folks back here on DM Radio with an all-star cast of guests. We've got Dan Everett, Bill French, and Sanjay Agrawal. And we're talking about fast data and getting results fast, right? The whole point of all this data stuff is to learn something and then take some action, right? And I think over the years, you know, I myself included, have maybe gone too deep into architectures and technologies and bells and whistles and stuff like that, because it is fascinating. But at the end of the day, All you want are answers that are relevant and focused on what you're trying to accomplish. And Bill was just telling us how Google has been creating this layer over the last year or so using this vectorization technique to be able to allow you to absorb all your data, which is absolutely fascinating. Now you don't just have to remember what terms did I use in that one email and like, who is that from? I mean, it's going to facilitate the access to insights in ways that we just have never seen before. And it's going to— it's really going to shake things up up in a very positive way. Dan Everett, what are your thoughts on all that?

Yeah, the productivity enhancements. I mean, we're just starting to see them now, right? You know, once, once we start being able to, you know, create loops of things for these models to do, right, can you get more automation going on? And I mean, let's face it, speed and agility have always been important to business. But nowadays, I mean, it's just even more critical, the speed at which things change and the ability to, you know, get answers, right? The faster we get the answers, the faster we take action, the more agile we can be in changing the market conditions. So that's good stuff.

And Sanjay, I'll throw this one over to you. I'm going to take a guess here. I don't know anything about your company. I haven't seen any white papers or anything like that. I'm just going to guess on something, which is getting back to the point I made earlier about ETL and all this unnecessary movement of data. Right? There's just all this movement of data for one little nugget that might occur 6 weeks from now, and all a lot of that stuff is going to go out the window. And I'm guessing that what you've done is figured out how to ascertain what might be needed soon, almost like the intelligent caching stuff that we've had over the years, but be able to understand, okay, that let's say the nexus of automation and prediction and data ops to be able to optimize the flow of information to get it to someone to where you don't have to move all this data around and around just to get 1% of it to a certain person at a certain time. Is that about right?

That is much better said than perhaps I would have said it.

All right, free of charge. That is good.

The way we talk about us is like, think of like a level 4 kind of an autonomous system where data and the humans, they work together. But your proof point, like where you start, start is really what defines you, right? So we said, you know, the data tells you all about itself. Use that, use that to make your life easier. That's the most important thing. And be maniacally focused that, you know, automation is your friend. And it can go a long way. Of course, right. And then you have the human override, right, you need to have these two working together. So you're absolutely correct. We are very much strongly focused on autonomous kind of a thought process. And that has been DNA from the company from day one.

Yeah, well, and the beautiful thing there is it's efficient, right? With the reality of these past systems, we had to do what we had to do. I mean, you think about in the early days of data warehousing, well, we had to strip out all that context in order to be able to move large amounts of data through these thin pipes to get to slow processors to do the work that they were going to do. Well, now the pipes are fat, the fat— the processors are faster. I mean, everything is better in that regard. But that doesn't mean you need to make the same mistake we made with code bloat, Maybe I'll throw this over to Bill. You can be hyper-efficient and be hyper-advanced all at the same time. And that gets very interesting, especially in this very complicated cloud world where, again, you know, I remember realizing as I talked about Kubernetes and how it's stateless and how to a certain extent we sacrificed state at the altar of scale, right? We want to be able to scale out all this stuff and do it, and that's great. But there are going to be cases where you, you don't want to do that, right? There are gonna be cases where you want to manage state or figure out how to do that intelligently. Well, now, and especially with this interactive AI that's coming down the road, I'll tell you what really excites me is when you can leverage this sort of interactive AI to sit there and look at all this movement and go, hey, you don't have to do all that. Just do it like this. Right? And 'cause it's gonna find stuff that you're— the processing power is so much greater and it could take so much more data. It's just ridiculous. It's almost amazing beyond belief, really. But Bill, what are your thoughts on that, on needing to go? Because that's the other thing is that, you know, when there's a recession or when there's pressure for a recession, when things are very disruptive and people are getting laid off, all that stuff is— there's a lot of pressure. And so there's pressure now and there's financial pressure to get it right, because if you don't get it right, you're going under. What do you think, Bill?

Yeah, I mean, Sanjay raised a really important point, and that is we're trying to adapt. To a world where data needs to move very quickly. This metaphorically I see as kind of like Hyperloop, right? So Sanjay is building, and again, I don't know much about his company either or read any white papers like you. So I'm assuming that in the data ops world, it's all about moving data efficiently so that AI can use it or so that AI can think about it at least. But if you've ever gone through the experience of looking for that email that you know you wrote about X, whatever X is, and you spent 2 hours doing it and you finally found it, that ends now because of semantic similarity. And Hyperloops have a very similar context when it comes to moving people. You're moving them in context. And I think you said that, Eric, early in our pre-show. Where we were just kind of discussing the nature of AI and the nature of how it's going to be smart has a lot to do with context. And I think what Sanjay is saying is very, very similar in terms of getting your data organized in a way that will do that. The minute you put a semantic similarity engine underneath your data, which fundamentally is text embeddings, you now have the ability to think Y but find X. And that's the problem that leads me to constantly searching for that email that is perfect. It's the thing that's gonna prove my point why that worker failed. They didn't read my email. And I know the email, I know what I said, but I can't remember exactly the keywords.

Yeah.

And that's where semantic similarity will pay off. And so now we have a Hyperloop on top of our Gmail history, which mine goes back to April 1st, April Fool's Day, 2004, the launch of Gmail. And we have Hyperloop on DevOps, DataOps. Soon we'll see Hyperloops on DataOps and we'll see it in many different types of database environments, especially in the no-code world, which I believe no-code is gonna be supercharged by AI. It is fundamentally an extension of the no-code world.

Yeah.

It's going to figure out our, our data architectures, our schemas. It's going to marry our automations, et cetera.

So, yeah.

Yeah.

It's a bright world out there.

That's crazy. That's a great point. And maybe Sanjay, I'll throw one last question over to you. And if there's time, maybe Dan could comment on it. But as I'm researching these things in these, these new foundational models and the transformer stuff that, Jürgen Schmidt-Huber worked on, which kind of opened the door for all these things. One of the things that really jumped out at me is this whole concept of attention and how the newer models have the capacity to change their mind, essentially, is what it kind of boils down to. Which, of course, humans can do, and we do it all the time. We do it constantly. We're being flooded with information all around us, you know, whether or not we got kids yelling at us or the wife asking us or something or whatever. There's constantly stuff coming in. You're running multiple threads in your head thinking about stuff. Well, this attention its capacity to change its mind is really, really important, Sanjay, because it can look at something and go, you know what, this isn't working the way I thought, let's try something else. That's a big deal, right, Sanjay?

I think that's really, I would say, the guts of it, right? It's really, you've got, I think that to me is the essence between generative and non-generative AI, right? The ability to construct new reasoning out of what you've got. Right.

Which is like, well, and Bill, you had a great quote there a minute ago where you said, you know, either let the AI do it or let the AI think about it. Right? One of my favorite things, and maybe Dan, I'll throw this over to you just to get you in before the show's over. One of my favorite parts about using these ChatGPTs is when you get the prompt and you sit and you watch it thinking, right? It doesn't start writing. It's like, hmm. And if you've done a good job, it thinks for a while and then starts talking. But what do you think? Final thoughts, Dan?

Well, I think one of the interesting things is you have a conversation, you can actually get it to change its mind. So I did this little experiment, right? I asked Bard and ChatGPT if they were intelligent and in the beginning they both said no. But then I started with what's the definition of intelligence? Well, don't you do these things? And by the end of it, they both said yes, they were intelligent.

It.

So that's pretty funny.

And that is— it's a good stochastic use case. But I will remind our audience that what the New York Times guy was doing when this first came out was not a very good use case. He was asking, you know, trying to see if it's sentient, all this stuff. And then it told him it wanted to marry him, he should leave his wife, and all this stuff. It's like, dude, that is a misuse of the tool. So please use the tools appropriately. Use only as the AI doctors recommend And with that, we'll bid you farewell, folks. You've been listening to DM Radio.