Join the Insider! Subscribe today to receive our weekly insights
David (00:00)
Welcome, you’re listening to the IT/OT Insider Podcast. I’m David and I’m joined today by Evan Kaplan, CEO at InfluxData . Welcome, Evan.
Evan (00:11)
Hey, thanks for having me, David. Appreciate it.
David (00:14)
Thanks for joining the call. You are the CEO of InfluxData, or InfluxDB, I think. Almost everybody who is active in the data world knows Influx. So, you know what? We’re going to try changing that with this podcast. Hey, why don’t you start with your personal story and the story of InfluxData.
Evan (00:26)
Not everybody, but that would be great,
my personal story. So I’ve been in technology for pretty much my whole career, which is a long time. And I’ve been a CEO.
David (00:42)
Yeah, why not?
Evan (00:56)
you know, at least almost 30 years now. I started a company out of my house in 96 that was focused on networking and security. Um, that did reasonably well and then survived the bubble and then did reasonably well again. we were able to sold that to Sonic Walledale. It was around SSL VPNs, which I don’t know that your audience would appreciate, but they were layer five VPNs networking. Yeah.
David (01:21)
I do think we have some cybersecurity people
as well in the audience.
Evan (01:24)
So then, okay, I may appreciate that. So
we pioneered that. It was a company called Aventail. Then I worked, I ran a public company that did global wifi all around the world. And that was called iPass. I ran that company. And then I worked in venture capital for a little bit, looking at new opportunities. And I met Paul Dix, the founder of Influx. And we bonded and
I thought it was a really interesting space. And while I was not a data expert at the time, this is almost nine years ago, I did learn a lot and my networking and security background helped a bunch. And I joined the company in 2016 before we were pre-revenue. And at that point we had about 3000 open source users who were just beginning using InfluxDB.
Today there are 1.3 million users who use InfluxDB all over the world every day. And those are primarily open source users. But we have about 2,600 commercial customers, including a lot in the spaces, David, that you’re interested in, a lot in the spaces around IoT, industrial IoT. PTC is a large OEM, Honeywell. We have a relationship with Siemens, Bosch, companies like that.
Industrial IoT and IoT is not our only part of the business, it’s a really important part of our business.
David (03:00)
And maybe because I already have 10 more follow up questions on that, but maybe like what is the elevator pitch for Influx?
Evan (03:13)
Yeah, the elevator pitches is that we’re a time series database. We’re very oriented to collecting metrics and events at scale. Super high ingest, super fast query speed, strong organization of data into memory, cache, disk that allows it to be available. And while we are a database for sure, our real advantage is data in motion.
A real advantage is capturing data, very fast response time, sensors, edge. Probably 60 % of our business is oriented around some sort of physical sensor analytics. And probably 40 % is around some sort of, let’s call it virtual analytics. So custom telemetry, network telemetry, things like that. So that’s a little more than an elevator pitch. maybe we’re still need more.
David (04:03)
And how did, it’s three floors up, so that’s also fine.
And how, because you’re now nine years with the company, how did that position change or not in the course of those nine years? What has happened? What trends have happened, have emerged? Cloud, somehow. So what has changed?
Evan (04:27)
Oh, for sure. Yeah.
So think there are a couple of, one is there a couple of big changes in the beginning. Since we were, you know, we’re here in Silicon Valley, we’re adopted very much by sort of the early tech people, open source people, really, really what you would call IT in your world folks, for us developers, and they did a lot of app and infrastructure monitoring. So servers, hosts, things like that.
And we started to see my conviction why I joined is I thought the IOT would be the biggest part because I come from the network connectivity business and I’d seen the connection of machines and devices and sensors and that rising. But the early stuff was app and infrastructure monitoring. And so, but as time has evolved, it’s become much more, more and more IOT oriented stuff because events and metrics are fundamentally an IOT dynamic.
If you think about, if you think about sensors, any kind of sensors in the physical world, they speak time series. That’s the lingua franca, right? So whether it’s pressure, light, volume, temperature, speed, whatever it is, the measurement, they’re speaking it in time series. And the workloads associated are really quite simple to understand at the most base level, which is what happened, what happened, what happened, what happened. So how can I use this to figure out what’s going to happen? Right. And then that’s the basic stuff.
David (05:54)
Yeah.
Evan (05:56)
And so as you look at that, so one is we’ve seen a tremendous penetration in IoT and industrial IoT has been very strong for us. have seen, you know, obviously cloud has been very important. We have both a cloud native serverless platform and a cloud dedicated platform. Right now, 55, almost 60 % of our business is cloud. And lastly, maybe we’ll get to this towards the end of the podcast is the role of AI.
which has really been important over the last particularly nine months.
David (06:30)
something atypical here for my podcast. Obviously we have a manufacturing audience, but I think they might be very interested in understanding what is sensor data or streaming data, what does it look like in a non-manufacturing context. So you mentioned Silicon Valley. What would that be like?
Evan (06:47)
yeah.
David (06:54)
I would say that it’s a bit far for me because I’m only used to these very large physical assets.
Evan (07:00)
Yeah,
no, no, I understand. So the easy ones to understand are network telemetry, right? Packets moving across the network, packet, video latency, streaming latency, communication latency, anything you’re going to measure that’s packets that oriented timing and things like that that would say, I’m offering a digital service. One of our larger customers is Salesforce. And so the huge, you know, the app integration monitoring all the API traffic, things like that.
David (07:06)
yeah.
Evan (07:29)
So those are what I would call the virtual where they’re they’re sensors, but they’re software sensors is the way that we think about it. So the distinction between them is not that great at the data layer.
David (07:36)
Yeah, that’s interesting. Yeah. Yeah,
because that’s also massive amounts, I assume.
Evan (07:48)
But you also start the kinds of problems you deal with in the virtual world are in some ways different because our base resolution is nanosecond resolution. And so as you think about some of these cases where you’re resolving stuff at nanoseconds, you can’t keep that data around forever. It’s different in the physical world. It’s rare that you’ve got that kind of, I’m not aware of a use case where you’ve got the requirement for nanosecond resolution.
David (08:01)
Wow.
Now I may need you.
Evan (08:17)
Even
off a millisecond is not required. That may change. That may change, but it’s
David (08:20)
No, that’s, yeah,
I would say maybe like high frequency vibration sensors or something like that, but those are, they are not like the most common use case in manufacturing, for sure.
Evan (08:29)
Yeah, right.
No, but it’s a use case. And since you bring it up, I’m not aware that we’ve got any customers who were, well, there’s probably some vibration, but I don’t know that that’s high resolution, that high resolution. But yeah. Yeah. Good point. Yeah.
David (08:49)
So for those listeners who want to give it a try,
contact the people at TeamFlex. Hey, let’s go back to manufacturing. So we published this thing which we call the Industrial Data Platform Capability Map to cut through the noise and to make it a bit, I would say, clear for my audience, like, OK, to be more specific on where does a certain application, a certain technology really shines, right?
So could you briefly comment, maybe as a summary for those just tuning in, that we talk about connectivity, contextualization, storage, edge analytics, data quality, data sharing, data visualization. Those are the most important ones.
Evan (09:23)
Yeah.
Yeah, so you were nice enough to send me the map beforehand. So looking at it, so it’s pretty easy because we’re going on your map. We’re going from left to right, right? And so where we should be elite and where we should shine and where other solutions should be built on, which is really our businesses, other vendors you’ve had on your podcast that have been built on Influx, is one on ingest.
So we specialize in high resolution ingest, is describe your data to the greatest degree possible, as opposed to one sensor and one tag, so that you can have massive description of your data. And not everybody does that, but that’s useful. So the ingest has to be billions of points per second in some cases. If you can imagine a large distributive energy network or things where there are thousands or hundreds of thousands of sensors, as opposed to just a manufacturing floor.
David (10:31)
Mm-hmm.
Yeah.
Evan (10:36)
You
can imagine energy infrastructure, process control infrastructure, things like that. So we’re a lead at the ingest side. so on the ingest side, not only is it the performance stuff, but it’s also the number of connectors. There’s a project that, open source project, which is more popular than our database called Telegraph. And Telegraph is, has something like 350 different connectors, but classic connectors for industrial, like, know, MQTT and LPC UA and Modbus.
David (10:54)
yes.
Evan (11:06)
things like that built in. And so what they can do is take the sensor, take the protocol convert MQTT or indirectly into the line protocol and ingest very quickly in our database with pretty much zero time to be read. So the data is available almost right away. And so as you look at that, so that becomes that goes into your central data platform in your model. And then eventually how it’s used is a variety of different ways, which I’m sure we’ll get into is.
You know, people build their models, they predict a maintenance around that data, they do their telemetry, they do their capacity planning, they do a variety of different stuff, and the data is generally stored in Influx. But, and the analytics within Influx are pretty sophisticated, but our expectation is that maybe it’s not stored in Influx for, you know, for 10 years. Some customers do. Our expectation is that eventually it’s converted, downsampled, and pushed up into a Lakehouse environment.
into some sort of, that’s where we think always goes. And there’s, we’ll get into a little bit, but there’s a reason why I think that’s the right architecture going forward. So we fit in the three major pillars of your platform. But I think the lots of the applications that will be built, I think increasingly we’ve built out of these large Lakehouse environments where you’re taking our really operational data and you’re taking
David (12:04)
Yep.
Evan (12:30)
perhaps some asset data, perhaps some unstructured data, perhaps some business data. And that’s where you’re building intelligence, if you will.
David (12:38)
Yeah, where
you, I would say, are strong in the data streaming or the sensor data streaming part. And then obviously you have, would say, additional data sources also fed into the lake house.
Evan (12:52)
Exactly. so, and then I have a model in my, we have a model in our business about way we built our platform, because that’s kind of the optimal configuration. And by the way, we believe it’s the optimal configuration, not just for manufacturing, but almost all sensor oriented work. I can talk about that in
David (12:52)
Yeah.
So before we do that, let’s make things a bit more tangible and let’s, I would say, this to a use case. You brought a use case that’s Junis, I hope I pronounced that right, Junis Energy. So let’s do this first and then we can go a bit more in detail.
Evan (13:32)
Yeah.
Yeah, it’ll
sort of ground the discussion a little bit. So, and this is a classic kind of portfolio, this classic kind of application of our technology. So, Junus does, they have a lot of businesses, but one of the core businesses is sort of off-grid energy storage. So the energy is created in a variety of different places, whether it’s wind, solar, power, all that sort of stuff. And they build these batteries, these distributed battery systems, right?
David (13:40)
Yeah.
Evan (14:05)
to store the energy temporarily. so each of these battery systems, and by the way, Tesla’s also a customer does a bunch of this kind of stuff, in each of these battery systems then has some sort of output of data. could be a Modbus, it could be MQTT, and they’re using Telegraph to actually publish that data to a local InfluxDB instance.
So.
David (14:35)
locals are really
on the device itself.
Evan (14:38)
So it can be on the device or it could be where there are multiple batteries. It could be, I’m not perfectly sure how they exactly do, but it could be in either one. Influx can be run directly on the device depending on it, or it can be run as a consolidator for all the telegraph inputs from the different batteries. And so, you you’re converting the protocol to line protocol, it’s stored in Influx. And then what they do is something we call edge data replication, which is Influx is now at the edge. The physical edge could be in a location somewhere in Germany, right?
David (14:45)
Okay, yeah.
Evan (15:09)
And then they publish that data up to our, we have a cloud service, a dedicated cloud service, and they publish all of that data over time back up to the cloud. And because we know what kind of data it is, and it’s always time series, it’s always fields and tags and descriptors around it, we can compress that data pretty dramatically so they can keep it a long period of time. And they do most of their…
analytics or dashboards, they sometimes export that data to other systems in order to do their predictive maintenance work and things like that. But that’s a very common, which is either use telegraph or influx at the edge, replicate up to the cloud. Now, some people have built their own, a fair number of customers don’t want that stuff in the cloud, so they have clusters of influx in a large site, at a factory floor, in a central data center. Some of the larger companies do it.
David (15:58)
Mm-hmm.
Evan (16:06)
They don’t want it to go up to some Amazon instance.
David (16:12)
That’s an interesting point you mentioned there. There’s a bit the, yeah, public versus private cloud or at least cloud versus I own my own data type of thing.
Evan (16:23)
Yeah.
But that triple, so I think you would understand this very clearly, that kind of three tier architecture is very common in a variety of spaces, building management, because it doesn’t make sense to publish everything to cloud, nor is it efficient, nor is the connectivity in many cases perfect enough to do it, and so you have to up-sert the data. There’s just a bunch of technical issues with the data and the connectivity that make that three tier architecture make a lot of sense.
David (16:45)
Mm-hmm. Mm-hmm.
Evan (16:55)
And security could be, security adversities, right?
David (16:58)
Yeah.
Another interesting topic slash trade off in for many companies is open source versus I’m going for a commercial product, whatever the commercial product or how it’s, whatever way or form it’s getting offered. So you’ve been very successful in having an open source.
Evan (17:10)
Yeah.
David (17:27)
I would say a user base as well as a commercial user base. So how do you balance them out? I would say when does a customer chooses for the open source variant? When does it make sense to go for the commercial one?
Evan (17:47)
Yeah, it’s a really great question. A good friend of mine, Oli Goetze, who is the CEO of Databricks, the company you know, has said multiple times, he’s spoken to our employees, but I’ve also said to him publicly, the problem with open sources as a vendor, have to hit two home runs. And sorry, that’s probably not the great European,
David (18:07)
Yeah.
Evan (18:15)
You’re being, I wish I could figure out a good soccer analogy. We could find it in cycling. have to win both stages. You have to have a popular open source project that developers love, right? In order to get attention, to get it, to get people to use it.
David (18:20)
Could we find something similar with cycling or so? I don’t know.
Evan (18:40)
And the key to popular open source projects are they’re relatively easy to use and developers can very quickly be effective and powerful with them. Can feel effective in doing this, building the system they want. And there’s no friction, right? So they don’t have to engage with a vendor. They don’t have to do anything. They just download it off of GitHub or off the vendor site and they start building stuff. And so examples of that, you know, obviously are us, companies like Neo4j who do graph, Confluent who does Kafka.
I mean, Kafka, know, these projects, Elasticsearch, things like that. They’re very popular among developers for a variety of reasons. One is, yeah, for the reasons we just articulated. And so, but the problem is, is then how do you monetize that? Right? Particularly if you have permissive license, the way we do, which is anybody can take it and anybody can do whatever they want with it. We don’t, which a lot of the open source vendors don’t do. They put some restrictions.
David (19:12)
Mm-hmm.
Evan (19:35)
Our view is build a really big community and, and, and, know, monetize a portion of that community. And so it’s on us to hit the second home run, which is to figure out how to monetize that. So obviously we’ve been able to monetize it by running the service for other people. That’s been important. We’ve been able to monetizing it. If you’re going to run our, services in production, our open source products in production, they’re pretty good. But if you really want to run them clustered, scaled out,
You want more capability, you engage us. It’s our job to do that. a relatively small percentage of customers will do that because even we’re very popular, but there are a lot of people who use us at home. know, David, I hope you go home tonight and you monitor your temperature, a variety of different stuff. mean, like it’s that capable, but easy to use platform. So the irony is scaling from a home user up to a huge industrial complex.
David (20:05)
Yeah.
Yeah.
Evan (20:33)
So, but then, but that gets at the heart of what your podcast is a lot about is what’s the relationship between IT and OT in this particular space. I developed and cut me off, I’m talking too long, but I developed a lot of conviction about open source when I was running the public company. We had had, we had very, very good success with Mongo, the Mongo, the early MongoDB. And we had also had a lot of Oracle, which was very expensive.
David (20:47)
No, no, no, no.
Evan (21:03)
And, you know, I just developed this conviction if it was easy for developers to use, to implement, to think that the business would move faster. So that’s why when I met Paul in 2015, and Paul was very convicted about open source, like I was, I was already there. I was excited about being part of the open source. It’s not easy. It’s not easy, but I think it’s a really, it’s a, it’s a really good program. Anyway.
David (21:26)
Yeah, you win. Yeah, yeah.
That also ties in, if I can take another sidestep to an overall digitalization strategy. If you were to advise companies on…
boardrooms, whatever, if you were to advise manufacturing companies, where should they start if they want to build a data strategy? What should be part of a data strategy? It shouldn’t be about do we go for open source versus closed source. I think that’s only an enabling capability at best, I would say. So what would, yeah.
Evan (22:23)
So my general orientation around this, and by the way, I think it’s going to be true in…
basically across all industries for a long time now is instead of thinking about it as OT versus IT, I think we need to think about it as OT versus developer led as opposed to IT. IT has a very specific meaning across all industries, is, you know, these are information technology professionals. So that can be anything from
David (22:58)
Mm-hmm.
Evan (23:03)
managing SAP implementations to, you know, to even work day or things like, you know, or provisioning your PCs or, you know, or whatever. But developer led is a very different, you know, I don’t have a no DT, but a developer oriented, I think the capabilities and the reason why I love open source is I feel very strongly that developer led initiatives are going to be emergent.
And I think there’s nothing clearer with the ability to generate code is changing so much as you know, that the ability to build your own workflows as opposed to buy them and expensive is really gonna empower. And so I think that dynamic is really important. And because of that, think open source is important. Because of the things we mentioned earlier is the frictionless ability
to go in there to get the code, to use the foundation without an evangelical selling process, if you will.
David (24:09)
And is there,
would that be different from, I would say between a small company versus a multinational? Have you seen your experience differences?
Evan (24:21)
Yeah, yeah,
it’s also different on stages, right? And so, you know, if you’re a large motion multinational company, you’ve got hundreds of million dollars invested in your MES systems or, or your other stuff, you’re going to go slow, you’re going to start taking this stuff and building around the edges to supplement to augment where appropriate. You know, maybe some you just stay with the whatever SAP offers you or
whatever the other vendor, Rockwell or somebody offers you. But if you’re a new player, and you’re just starting out, companies who are in renewable energy are really classic examples, you get to rethink this from the start. You get to build, and this is classic Silicon Valley dynamic, which is that generation of next generation developers are saying, we do it this way, we get to start.
David (25:04)
That’s interesting, yeah.
Evan (25:16)
So if you started to use a terrible example, you’re, you if you started and built a company 15 years ago, you would build it on, you know, all of your communication bus would be built around Microsoft exchange. If you did it, you know, if you did it today, any startup, it’s like on Valley, you you start, you know, you’re starting with, with, you know, with Gmail and Slack and you’re just starting with, you know, everything’s built in from the beginning with those kinds. And so I would suggest that.
that these new tool sets are going to be built largely on open source platforms. that starting companies will start with them forever, but others will use it to augment. But over time, my view will be in a developer led IT motion, not an administrator led IT motion or an OT. I don’t think OT goes away because these are machines and processes and you need manufacturing engineers. That’s real. I just think that…
David (26:08)
No, definitely. Yeah.
But it’s,
yeah.
Evan (26:14)
You don’t
stop in the middle. go from developers to… Anyway.
David (26:18)
I think
that’s also the very interesting time we’re in right now. You can’t stay in the silos any longer when it comes to data. That’s… Yeah, it’s not possible anymore.
Evan (26:38)
You don’t want your data. I mean, these platforms are super important, so I don’t want to minimize it. But if all of your important data is locked up in SAP or Salesforce or ServiceNow, is that really the architecture you want? You want the dependency on these larger platforms. so I think there’s a democratization that goes on. And to be honest with you, things in the physical world, manufacturing, oil and gas processes,
David (27:00)
Mm-hmm.
Evan (27:07)
They have to move slowly. can’t do this. They can’t disrupt this stuff. They have to move very slowly.
David (27:09)
Yeah.
No, no. And
that’s also interesting, I would say, an interesting difference between indeed working in IT where you can move fast and maybe that’s maybe a bit of the Silicon Valley mindset is you can move fast and you, well, you can’t break too many things, I assume, but still.
Evan (27:31)
Yeah,
we recognize that we can’t like, we’re not going to go in and like, we’re not. that’s why we want to be in, we want to be that foundational level that empowers developers. And then we can control that process over time. Stuff will happen. And we just want to support those developers. We can’t go in with a pitch that like, Hey, you know, take your time series database, rebuild all of your.
David (27:53)
you
Evan (27:59)
your OSIsoft, your Aviva, your history. We know, like we’re not, we don’t know enough. We need developers who are there, people like you who know enough to do that work.
David (28:07)
No, that’s…
Yeah,
it would definitely be the wrong entry point. And not only because of, let’s say, legacy reasons, and not only because of, indeed, this manufacturing. An average oil cracker, for example, has a life cycle of between six, seven to eight years. that’s like, within those eight years, you don’t touch the system at all.
Evan (28:19)
Yes. Yeah.
David (28:39)
And after 8 years, don’t want to touch it as well because why would you? If it works, why would you? Let’s go for another run of 8 years.
Evan (28:48)
So, yeah, that’s a perfect example. I was in, I don’t want to say who it was, but I was in Germany visiting a very significant manufacturer who makes these hydraulic presses. These things operate for 30 or 40 years. And so, you can tack on some extra capability now with PLCs and pumping the data. But the truth is, this equipment works pretty darn well for a very long time.
David (29:15)
You
Evan (29:17)
And so any Silicon Valley view of that would be pretty naive. Like, you could be…
David (29:25)
Good statement. Let’s go back to some use cases. So I want to touch a bit about, I want to touch AI a bit more. So I think with obviously AI has been around for many, years, or at least machine learning, would say one of the, it’s been around for many, years, but now we’ve seen the hype of Gen.AI, especially
in the IT world, we’ve seen manufacturing trying to figure out whether that would help them or not. What have you seen?
Evan (30:06)
Yeah, so I have some pretty strong thoughts about where we’re at on that curve. And maybe it’s a virtue of, you I live here in Silicon Valley and so, you know, my kids’ friends, the fathers and mothers work at these companies. I’m also fascinated by myself, deeply fascinated. And my fascination
if I have a segue comes from the fact that I’m old enough to have started my career when a fax machine was shared by a lot of people and then voicemail and email and then the internet, which is where I started my first company and then mobile and cloud. And I think obviously we’d be crazy to think the rate of change is consistent. The second derivative is pretty significant here.
I recently did an All Hands with my employees. so if you can picture this, there’s an author, Tim Urban, who wrote a blog post back in 2016 about where we’re on on that technology curve. And, you know, we think we’re on some sort of, you know, relatively sloping up linear curve, because when we look backwards, we can see all these changes. And they’re coming along at what feels like reasonably regular intervals, and each one’s a little bit of a step function change.
David (31:27)
huh.
Evan (31:33)
But our perception is that’s continuous. But he has this drawing that has you standing on the curve and with a straight line that goes up and your nose is pressed against the curve now. And you’re not even realizing. If you can imagine that, hopefully I’ve described it well, like your nose is, like you don’t even see it because everything you’ve seen looks somewhat continuous. But I think this is a massive discontinuity.
And we talked about it in one sense, which is the ability to generate code is really, really amazing. I’m not saying all code is perfect. I’m not saying it’s important. I’m just saying is that ability to generate code is changing productivity. But I think as it relates now, now to try to tie it back to our world here, where I think it’s really what I, when I’m talking to customers and I’m out on sites, what I want to know is how they’re using the data they’re collecting. We’re super good at collecting the data.
David (32:05)
Mm-hmm.
Evan (32:30)
And we’re pretty good about building control systems when they want to round it. And so I’ll talk about that a second. But what we’re not great, which is not our expertise, is building the intelligence. And so we can feed the intelligence. So if you think about how you build intelligence, let’s use a factory example. Say the factory has 100,000 sensors across 25 different machine processes, right?
And I know for your point of view, you want to collect those centrally as much as possible and you want to do all that sort of stuff. And so we want to be really good at actually the ingest and the collection of that. We want to be good at organizing it in a way that can be used most effectively by the systems that we use it. But we’re not going to be great at is combining that data with a bunch of the other relevant data to build intelligent models, right? Machine learning at scale.
David (33:27)
Mm-hmm. Mm-hmm.
Evan (33:27)
LLMs combined with machine learning
and sensor data. That we fundamentally believe will happen in these huge data stores that you’re ETLing the data to, in the lake houses, Snowflake, Databricks. And I think, you know, if we’re having this conversation 10 years ago, that would have been into Cloudero, Hortonworks, or the Hadoop infrastructures. But now it’s into the lake houses because
They’re figuring how to do these things at scale. And so almost all the people we talk to are thinking about, okay, how do I make the data turn into intelligence? And that’s a whole other discipline that we’re beginning to see these traditional manufacturers, discrete process control folks really, really working on. And it seems exciting. And I would not call those people IT. I would call those people, you know, I would call them developers and I would call them almost AI oriented intelligence.
And so our view is, what we want to do is collect the data at scale, ingest at performance so that it’s available and we want to feed it to these systems that can create intelligence. But then really importantly, we want to be able to build control systems around that. So most of our business, I was to be honest with you, is around real time monitoring. Monitoring these systems. People are still looking at dashboards on regular basis.
Maybe they’re doing analytics off the stuff coming off the back end, you know, separated in time. But I think the real opportunity is automation and, you know, self-healing and eventually autonomy. And that opportunity requires you to be able to take action on the data in, you know, millisecond time. And so our query performance has to be elite. So if you can imagine an intelligence engine offering an inference, an inference saying,
you know, looking for this condition when this condition is, I want to query that within 10 milliseconds and I want to respond within 50 milliseconds in order to adjust a process or control. Most things don’t need it, but all things tend in that direction. We want to be more autonomous. We want to do all that in manufacturing and transportation in all these things. And so I think the AI stuff is like so essential.
David (35:37)
Mm-hmm.
Evan (35:49)
Right? We talk about relatively predictive maintenance. Sure. I want to know when a large hydraulic press is going to fail after 4,000 PSI. Sure, I want to know that. But what I really want is over time, increasingly operator less. Increasingly.
David (36:09)
Yeah,
you don’t want the thing to fail at all, basically. yeah.
Evan (36:13)
Right. Right.
Right. And if we do, we assume that nothing never fails. But if it does, like I’m very quickly correcting without having to page somebody in the middle of the night or stop a factory line. That’s where it goes. And I think we’re just on this blooming time. And I think the, you know, we’ve had machine learning around for a long period of time, but with the LLM, the amount of attention, the big breaks, I think it’s changing.
David (36:28)
Ab-
Mm-hmm.
Evan (36:43)
Anyway, sorry, that sounded like a long narrative, but I don’t know.
David (36:46)
No, it’s super
interesting. Well, let’s say if we, if we take that narrative and with your insights and with what you see happening at Silicon Valley and you would, would say, bring that into a manufacturing company of today. so what would be the things, what would be the things to do today? Is it about connectivity? Is it about, I don’t know, data management? Is it, is it about
building certain organizational capabilities. What are the, I would say the first steps a company should take to maybe unblock or at least speed up their path towards these things?
Evan (37:32)
So I want to be humble here because I don’t operate inside one of these large and they are our customers, but the kind of constraints they have, the kind of things they’re doing, manufacturing is really, really hard. And so I don’t want to assume I have expertise. don’t. But I think where the power lies is in investment in developers.
in the data plane, in ways to use it, in ways to pull data out of their older systems. I think the power lies in the stuff you try to cover in your podcast. when I think, when I would think about, and this is gross, this is a gross recommendation. When I would think about, I would think about how do I, how do I invest in that developer slash data infrastructure with developers who are prepared to learn something about
can’t be just coders. It has to be developers who are prepared to learn something about workflows, the dynamics of that. And how do I invest in that? Those investments will pay off long term. And they can be way more productive than they were even five years ago. And so free the data, invest in developers, and then come back to first principles. How do I make this business better?
David (38:36)
Yeah.
I think, Evan, this is a perfect way to end this episode of our podcast. No, I think you summarized it brilliantly. Thank you so much for joining me.
Evan (39:09)
Yeah, I enjoyed it, David. Yeah, really good
questions. Sorry for pontificating.
David (39:14)
No, I like those. Thank you for joining me from, I would say from Silicon Valley. It’s good to have those insights as well. And for our listeners, obviously for tuning in again. So yeah, if you enjoyed the conversation, don’t forget to subscribe at itotinsider.com and leave us a rating. And see you next time when we are back on bringing you more insights in bridging IT and OT. And until then, take care. Bye bye.