Hello, I'm Rob Hirschfeld, CEO and co founder of rockin and your host for the cloud 2030 podcast. In this episode, we continue to dive in to a topic that is related to edge technology, although our discussions pretty general about it versus OT or infrastructure information technology versus operations technology, and this ongoing dilemma of edge sites specifically, but that includes factories, retail locations, I think this is actually inclusive, even in data center technology, and 10th standard cloud of having operational tech, which is vendor locked, narrowly controlled siloed technologies versus general purpose technology. So in this case, we're talking about ot as specific vendor locked islands of technology versus IP, which is really multipurpose, multifunction shared infrastructure technologies. And we really get into the tension and how to resolve the tension between those two technology approaches, I know you're going to enjoy the podcast, have a good time.
This actually, if you'll take the transition, I would, this would be a good place to actually jump into the it ot edge conversation in a way. Because one of the things to me that that is a struggle for for, and this actually is its edge, but I think it's actually it versus ot lore, is this idea of general purpose infrastructure versus specific purpose infrastructure. Like that, we have the same issue. If you look at building out an edge site, if you're building, right, if you have components and systems that are vendor specific, then you know, you lose that vendor. You're, you're you're done. But if you can move some of it or all of it into general purpose hardware, general person purpose operating systems and things like that, it seems like a better maintenance store. Along the same lines is what you're talking about.
Yeah, maintenance and all along a bunch of other stuff. I was talking to a friend the Air Force yesterday prepping for this, and we were talking about the F 35 is a flying Mach two data center that is stuffed to the gills. And another guy had been working with he's a math PhD and he built this whole automated system for stitching together communication systems. So think about five to four projects, you know, F 35 is communicating with F 20, twos communicating with, you know, other other weapons platforms, and they all speak different languages is that that tower of Babel problem. And what he had what he had developed in this stitches program was basically it would pull the messaging format, and automatically write code to be able to convert F 35. Speak to f 20 to speak, so that fighter pilots could not only talk to each other, but you could talk to f 22 pilots in the Royal Air Force and in France and etc, and so forth. So language conversion and all of this. But the way that it was required is he had it has to deploy to a micro service on a container. Yeah. So so now it's like, okay, well, now we need a K eight cluster sitting on an F 35 and 40,000 feet. Okay, plus f 35 has every single square millimeter accounted for in the airframe, which means that what we have to do is modernize some of the existing software systems within that platform, so that we could free up space for general purpose computing to be able to to accommodate this additional need. So in the ITT use case, what I'm saying here is that there's a there's a future backwards compatibility advantage to be had by being able to have some component of legacy ot systems that include some a general purpose component.
So does this always have to? Does this always have to be done? In situ, like on all on the on the on the aircraft can now
now it's a whole software supply chain locked down issue. So they have to, you know, go through the whole process and create, you know, the the, the, you know, you know, standard standard que deployment model, but it's got to be hardened and tested before it gets pushed up to the cake cluster.
Okay? So so you'd be very interested into two levels of protocols and it ot integration from to a bunch of companies that are working in the robotics space that are addressing it for manufacturing. And there is a protocol called Zeno, zety, n o h. And the two companies one is called Move AI, and the other is called Zetta scale. And they're coming at it from the perspective not of aerospace and defense, but automotive, where you have exactly the same problem, just a different domain, where you're trying to do V to X communication, and they're actually doing ETL in flight. So they've developed not only CUDA, but also Kubernetes, and other micro service containers to be able to do this. So they're taking in everything literally from the microcontroller to the cloud, or the cloud microcontroller. So it has used in aerospace and defense, industrial manufacturing, V to X, anything to anything. And they have in one case, one of these companies has done a provisioning plugin, to be able to do the bare metal kind of stuff that Rob is doing. And that would be a very interesting thing for you, Rob to take a look at. I've been doing a lot of research on this stuff for like the last six months, in terms of how are you going to take the walled garden of robotics, think spot Boston Dynamics, or Atlas or any of those and integrate them with something from Siemens, which will never speak the same language because they needed their own walled garden. And each of the subsystems that you're referring to in Aerospace has exactly the same issue, not only about compatibility, but fighter jets, a fighter jet across different disciplines and domains, meaning it's Canadian, it's American, it's UK, it's Australian, whatever their you know, NATO country, you have a big issue water
robotics to, to, you know, small drones. And right, those are the exactly same issues. Yeah.
That's where I have this, this vision of like bringing together these different integration technologies at different layers of the OSI stack. And when it and OT. So so that's what got me interested in stitches is because it's doing what I'm, so I'm doing it at the data layer, and he's doing it at the RF comm layer and the messaging network, comm layer. And then and then coincidentally, Rob's doing it at the infrastructure cloud layer. And if you were able to pull that all together, you could have this whole industry, Ford auto optimized ability to move and tire everything from cloud to cloud, you know, to different, it and OT platforms. So basically, yeah,
so good. Take a look at the Open Source Eclipse project on Zeno, because I can tell you that they have done I believe that they're building a platform like an industry for operating system would be the best way to describe it. So they have many, many capabilities not only in the in the Zeno language, but they can do things like DDS to OPC UA or DDS to N Qt T or any of the broker type things with various brokers various plugins and break the notion of the walled garden. And in most case, they came at it from a fleet management perspective for factories, right you have different types of AMRs running around and different types of ABGs and other equipment so that why do you have to go and do a full IoT implementation with sensors and actuators and then work in the robotic side when the robot couldn't pick up all of the data from the machines directly. Like that takes years off of deploying.
And that's that's the thing that's always been strange to me is that why is it so hard for us to have moved these systems into using more standard delivery or standard packaging? Right or standard protocols? For that, I mean, I go, I had a, I did a stint with physical security company where we had been making our own hardware. And one of the things we tried to architect was switching it to standardized servers like buying a cots server, instead of building our own machine, which would have been much more powerful have a lot more capability. But interestingly, it was much more expensive, like we couldn't, we couldn't get the cost to work out for using standardized hardware. But we also weren't in a position and this is a chicken, the egg issue, to say, hey, we just need to put a VM or container in your infrastructure. And then, you know, and then we don't need hardware at all, we're just going to use we're going to sell you the locks or the software. But that was a really though it was 15 years ago. But that was a really hard conversation. Where it was an impossible conversation, there was no way for us to do that. Yeah, the economics would be different. Now.
This reminds me of so you know, back in the day, when I was a chipset, engineer at HP doing super domes. The folks or engineers I worked with went and left and joined a startup called convey computers. And what they were doing is reconfigurable processor architectures on CPLDs for special purpose workloads, and this was 15 years ago as well. And that never worked out because they only found traction with very specialized scientific workloads, like upstream. Oil and gas, data munging type stuff. Right. And
what's your question? That quick question, Tyler, when you were speaking a little bit before? Were you talking about actual migration? You know? Are we talking about container migration? Or are we just are we talking just kind of general purpose? Communications?
Yeah, I got conflated a couple of things there. Okay. So I find that the software supply chain delivery of container images for DACA. But then once that's there on the general purpose compute, is this, you know, universal translator to speak. F 22. And f 35. So two separate things. I apologize.
Yeah, I just wanted to be clear. Yeah, sure. I got it.
Right. Thanks. But what I was saying about con Vai, and that special purpose reconfigurable processor architecture stuff? Is it was the same thing you were talking about, Rob, is is that, that scale out computing, Moore's law, economics completely trashed that business model. And, and I think we're gonna see the Moore's law continues.
But there's a different side of it. And we still see this as a problem is that the it ability to, to provide a consistent, reliable service also makes the OT delivery, much harder from that perspective. So like one of the so I'll give you the old example. But this still, I still see this playing out over and over again, is that when we were running locks for people, and so if somebody said, Oh, don't worry about your server, we'll put up a VM, we'll make it work. All you have to do, you know, we'll run your software for you. We're gonna get the call when people are locked out of their building, right? OT systems are usually operationally critical, that, you know, the OT provider gets the call when the IT infrastructure is failing. And, and I think one of the problems that we've had in in this whole idea and maybe the fighter jets a good example, right? I mean, I get I get a little bit nervous, right. But my stomach tightens up. When I think of an of a of a fighter jet running a Kubernetes cluster, it does not have the reputation and the practice to have those mission critical systems running.
Yes, but another way, what you're saying is that, you know, in it, we think four or five nines is fantastic. But if it's a fighter jet, we need six nines. In my view that that's just another example of what we need. It's an economics problem. Because it's a trade off for resilience. We can deploy multiple aka cut clusters on hardware, isolated systems. And then and then use a load balancing or scale out model to be able to create to get to six figures, or six, six nines. The problem is, is the expense involved in that? And whether that what point that makes sense economically,
but hold on, hold on a second, because I want to challenge something in the IP model, the general, the general infrastructure model is fundamentally a shared infrastructure model. And the OT models is fundamentally a dedicated infrastructure model. However you want.
Go ahead, go. All right. Sorry, for cutting you off. Okay. Okay. However, if you take a look at what's been happening, and the reason I came at this from the AMR and robotic side, is because that no longer holds true, they have to be highly distributed, or federated architectural models because they have to be able to do real time transmission, and in flight and in transit ETL. So you're talking on a microcontroller. On a computer on an Edge Server, let's say, all the way up to the cloud, where you have data center and micro controller, you have all the different permutations and combinations and the fact that it's in flight transmission, because remember, this is being designed for vehicle anything, or any one or anywhere that changes
through and does that address Rob's point about dedicated infrastructure?
Yes, because they can distribute it once to all.
Its how do you overcome the issue of, you know, one system has a vulnerability or goes off the rails or falls over and then takes down, you know, adjacent systems, which isn't, which is a it reality, part of what we build is, and there's a lot of overhead for it is that that type of thing? Economically, it's, it makes a ton of sense. But if you're an OT person, and you're like, Oh, my system is now going to fall down. Because, you know, the cash registers are for the robots. You know, the conveyor belt system is antiquated, and it has a glitch. So also the robots are are unable to process because somebody did a patch to the conveyor belt system that's struggling to communicate why I feel like there's so much resistance to the to it being involved. And I do think that's part of the challenge is
no question on ot it bridges or integration. It is the, you know, it's like men live on Mars and Women live on Venus. It's kind of a it's a religious holy war. Yeah.
And there's not a technical problem. It's a people issue. Yeah,
that's one part of it. And the other, but the other part of it on the technical side, to Rob's point, what I became very enamored with, with these systems that are being developed and even out in open source and whatever. And even what Zetas scale is working on is they're using the same concept of what Tumbleweed was for so dynamic routing, and dynamic rerouting so that if if part of something fails, it has an alternative to not bring the entire thing down.
Yeah, I mean, that's right. DARPA. Net. Yeah. Nuclear War resilient.
Yeah, so the way that they've gone about doing it, and I questioned him several times when I was watching, you know, watching it unfold was were the flags to a an incomplete packet, for example, how does the flag get raised for that? If you're doing ETL in transit, and you drop a character off the packet? What then like, like, where are all these contingencies to your point, but I will send you some data, or aside from the website of what they've been working on and how it's how they're overcoming some of this but the Dynamis As the the the dynamics of the way this could work are really intriguing. I'm not sure that I've answered your question, Rob, or that you don't still have a giant red flag. I just need.
I think I think that, you know, what, I'm, what I'm scratching my head as I look at, you know, how do we help it succeed at the edge? Or in the factory? Right? There's there is you're right, there's we're talking two different languages. And I don't think it does a very good job, saying, we will have ways to get you a faster turnaround, when you have a patch, you know, better isolation, higher SLA is better monitoring higher. There's a lot of stuff you have to overcome to move somebody off of an island into another system. And then I think on the other side, the teeth of people, this goes all the way back to your stove. Comment, yeah, are sort of like, you know, we have specialized stuff, it's very proprietary, we don't want to move into very little incentive to move into using standard equipment or standard protocols. In some cases, because it adds costs in some cases because they lose control, or they price price protection.
Do you have to do with all of this is all of this predicated on building out a net new underpinning net new infrastructure, because if you have to consider fitting edge components to an existing network architecture and kind of backfilling, I realize you're trying to put in place the, you know, talk to anything, let anybody talk to anybody, but that kind of interworking, that kind of interoperation, if you have an older infrastructure, and you're trying to fit. I mean, I don't know what the implications there are for all of your, you know, your big metrics, you know, reliability latency, not to mention, any issues that it puts up puts on you for scalability.
The thing that's weird to me is that the OT systems, to Joe's point are, are all converging on cots stuff. apart with their
reasonable, which is the right thing to do I get it correct.
But they're doing it in a way that still is not right, they're still not talking the right language, to actually say, Oh, wait, I don't have to buy a server, I can run the gym for the IT team can give me, you know, capacity to do that here. And we were there. This has
been going on longer than most people realize, you know, I mean, PLCs running ancient versions of Linux. Back in the day, F 22. was running a bastardized version of Windows 95. They didn't they didn't brag. They didn't broadcast that too much. But and then and then next gen or, I'm sorry, I've got my Air Force hat on right now, because that's what I'm focused on. But next generation air dominance platform. So the platform that they're they're developing after F 35 is all cots stuff. It's all you know, containerized standard it type stuff. They're just figuring out how to harden it using like custom rad, hardened versions of processors, all the way up to everything to everything else. So so it's out there. But and that's why my opinion is that this is purely an economic and a cultural issue, and not a technical issue.
Well, part of part of my thought processes also, as I'm watching this stuff unfold, and the convergence is happening. And to Rob's point about OTT convergence. There are a lot of companies that have decided to just virtualize the plant floor. And part of the reason that they're doing that is because they want to build digital twins a lot faster. And this is the only way to do it. So there's that aspect, but what's going to drive this whole thing is you now have some very big Kahunas in the fray, that are betting the bank on making this stuff work. All of automotive is geared towards this because of vehicle to anything. All of manufacturing is gearing toward toward it because they want the operational efficiencies of digital twins. And they want to be able to put digital twins together, because you can't run an end to end digital twin. It's just physically impossible to do. Whether it's because of comps and latency and stuff like that, that you just cannot take a 50 year old piece of equipment and virtualize it because it has nothing to attach to you. Even with intelligent actuators and sensors, just as they give them I would say
this was one of the issues that I wanted
to raise. Right. So they're looking at, you know, they're trying to do it from the protocol side. And they've been very successful at doing it from the protocol side with zero latency, because in V to X, which is the next big hurrah, and horizon is you cannot have any kind of latency. Think about what swim was doing right with traffic. And now with all of the automation in the vehicle, for autonomous vehicle, whether it's level three, or level four does matter. The point is, they all have to talk to each other, they all have to be able to pick up data from each other in a in a in traffic, and also from light stanchions, from phones from pedestrians from signage, front, you name it, they have to be able to glean data from it that has zero latency. Well, they're gonna
have to build in something like like a caching model, like what we see in Server architectures, or content dislocation, or, and that's going to require some enhancements to the protocol to be able to, to handle that type of an architecture. Right? Well,
kind of without that kind of caching, you know, you're, you're dead, you're dead going to be dead in the water. It's not gonna do good.
There's no such thing as zero latency.
I guess part of part of a
whole other discussion is speed of light that gets you to large ships, relative
Einstein speed of light, no such thing as zero latency. Relativistic.
Yeah. No, that would take my brain into FPGAs and chips. And, you know, the whole nine yards of that night. I don't think that a there's no time
I have I have a small but interesting aside. Go ahead, derail us for a moment. But the White House has issued a mandate to define lunar Standard Time. Did y'all see this? Because I'm travels faster on the moon. And there's actually a time drift of the length of a second seconds that it microseconds to drift. But
it's it really microseconds and not Yeah.
Wow, like 23 microseconds a year, I
think. Okay.
Yeah, it's just material, which is material. Absolutely.
But I thought it was speaking of Einstein and relativity. I couldn't help but interject the if you wanted to evidence that. Einstein was right. Yeah, that'd be got it. That
makes sense. Because you have the the relative velocity differences between the moon and the earth. And the fact that that light travels faster in a vacuum.
Correct? Yeah, that's just the moon. The moon's traveling faster than we are through space.
I fell. It's so so deep. The topic of the day, but did they also publish the current speed of the rotation of the earth?
I assume they have to factor all that in.
Okay. No, I'm just I'm curious before I started Googling things, and doing Delta kind of math in my, in my spare brain. I figured maybe.
I guess if you if you weren't deep enough into the core of the Earth.
robic, you don't have those. If you want to totally blow your mind. Think about how you'd need to calculate that time drift difference based on the latitude of location on Earth and the latitude of location on the moon. Yeah,
I suspect that that our actual assault solar orbit has a bigger Delta than our rotational orbit especially because you're going to make up that time as you as you grow as you go around. So I think the net for that That's gonna probably be zero. Whereas your your actual solar orbit is probably a bigger contributor and the but then again, the moon's got our solar orbit plus its own orbit as from a persistent velocity. So I don't know.
Yeah, the solar orbit in the mind.
Mind Mind blowing. Yeah,
the solar orbit should cancel on both sides of the equation for just the Earth and Moon.
So southern world are very close to the moral of this story then is, well, some of us I think it's going to miss where I am. I'm gonna have to go somewhere else. But the moral of the story is when you're watching the clips, Don't blink.
You know, I was waiting until the last minute because my my plan was to get in the car and go see this thing. We saw it in 2017. It was amazing. But the cloud covers it's not as not, not doing so hot. It just not look promising.
I know. It does
not. I mean, maybe and northeast Missouri. Maybe.
But going at the last minute to see it is not advised. Traffic is supposed to be sort of everywhere here. totalities. Yeah, I
think we're I think we're gonna pass.
We had events planned for rack end to them flying people into Austin for our wealth plan. all hands meeting, and I just cancelled all of Monday activities. That's yeah, yeah. Kevin travels. Yeah. Alright, thanks.
Before we go, I got a quick story, I want to tell you guys that I think you might enjoy, because we were talking about that. I was thinking about the chipset days. So this is goes directly how you design for resilience and achieving more nines. So we were having multibit errors on the Superdome memory subsystem, and couldn't figure out what was going on. For months, and then we we realized it was just a specific manufacturer of memory chips. And, you know, with the with the high end, you know, Unix grade systems, you have custom contracts with memory chip suppliers, to provide that. And so we theorize that, well, they did something in the in the layout of the memory chip on the integrated or the memory circuit on the integrated, you know, Chip. And so the way that we think with the way that we were able to validate that was in the lab, we had all of these super domes sitting here side by side by side, right? And so half of them, we put, we went to the home improvement store and got kiddie pools, oh my God, and then put the kiddie pools on top of the servers, and then fill the kiddie pools with water. So we were able to show we were able to prove via that method that it was in fact cosmic rays strikes that were causing the multi bit errors, because the memory manufacturer had changed their layout so that cosmic hitting the chip could actually take out multiple memory cells
so that did you float any rubber ducks in there? That's what I wanted. Oh,
shut up. Shut up. Well, that was that was some crazy shit
that's hilarious. My
brain just exploded. All over my desk.
The value the value of understanding physics is plays out in the real world.
Oh, yeah. Another story when I was at TRW, we had a an ASIC motor controller, and the ADC kept getting strange errors in terms of accuracy resolution. And I debugged that using Excel by taking all the readings and then processing it in an Excel and figuring out which RC circuit and the ADC was actually had the wrong cue constant and wasn't settling and time for the next reading. But it was hard to figure I mean, we had ability to probe inside the chip. So you just had to look at the data and figure out what the problem was from the data.
So along along those lines, and pull us back to the question I had for Ito T. Yeah, is, you know, is some of this just improving ability to patch and respond like, because, you know, we did on Tuesday, we talked about the latest hack attempt, we didn't do it here, which maybe we should plan next Thursday to really bring that up, because there's some community lessons in that. But this whole ability of I think mismatch for it and ot of how you have to be much more able to patch and test the whole resilience for both of the systems, I think, is really where it needs to be. And we're just protecting ourselves by not collaborating at this point. And, you know, is the first foundation just to be able to build systems that you can flow patches through more effectively? I couldn't be that simple.
I think I think the answer to that question is, the more automatic you can make it, the more hands off you can make it, the more you would attract the convergence. Because right now, if you think about a test engineer running around the shop floor, trying to not necessarily do the patches, even in a seat, you know, like one offs kind of thing, they'll never get it right to begin with, because chances are likely that the firmware has issues. So okay, that's where I think if, and I've said this to you before, and I don't mean to be repetitive, but if I see how to home, it would be in manufacturing, because the more you can take that weight off of the OT, and break those walled gardens down, the more easily, you're going to have the rest of the OT related work, start to converge more easily with it. And I will tell you that with whether it's AMRs, or drones or any of the newer technologies, there is a huge gap in that market for being able to rapidly deploy patches, fixes, new iterations, or even basic firmware across them. And it's needed desperately because right now, you have the biggest Kahuna in the world, in Vidya getting in this game in a way that's going to change everything very, very quickly. And they're partnering with SAP and Siemens to do it, which means that you have the one end of the whole transactional stack, and you know, shopfloor, operating systems, and whatever. And then you have all of the digitized digital, digital twins, digital threads, tapestries, whatever you want to call them all converging at once, and all wanting to use AI at the same time.
And evenings for ramp throughput.
This is absolutely 100% Yeah, it's all
about process optimization. And what I mean by that is eliminating friction, friction within systems of systems. So that I mean, kind of goes back to my blog post on data friction, is, that's the trick.
One of the frustrations for me, though, is that, you know, most organizations aren't prepared to leave you. I keep thinking about like Tesla, sending patches out software updates to cars, you know, frequently and they're the, you know, they do it very aggressively. They're known for it, but other other manufacturers are ready for it. The people haven't been trained for it, right. It's, it's an opportunity for it to be leading and how well they can distribute rollout update patches that I you know, when we're talking about people in it, they're not. They're not leading. They're not, they're not moving into a stance that says, you know, I can patch my systems and in an hour, I have a way to roll out I know how those controls would work.
And they're not. By the way, my prediction is they're not going to because there's a fundamental business model, where interoperability is against the self and interest of vendors?
I agree, strongly agree with that. And it's until the until the customers, it is until the customers demand. Yeah, the customers need to be making that a buying criteria. And I think, you know, things like the VMware debacle at the moment is people starting to realize the lack of abstractions, is is actually very expensive, not not building, not insisting on vendor neutrality is really expensive.
But I think that that's, you know, I 100% agree with you. But I think there's another part to it. CIOs are not trained on OT. Generally speaking, no matter how big the organization or what type of manufacturing it is, your CIO was originally looking at, I keep the lights on, I keep the computers going, I make sure the helpdesk is adequate, or above, above par. And now that I have a seat at the table that I have the power to influence. OT is like, Oh, how do I do this now. So I'm going to start with security because that's most germane, and and integral to the company, and work my way up from that. So it's going to take some time. But for folks that are coming from the other direction, where you have a CTO who is ot friendly, they are equally in adapt.
Do you see that on the in your fracturing side? Joanne, I know on the defense side, you have a CTO, that's the OT CTO or the weapon platform CTO, and then you have an IT CTO, and those are completely different programs and offices.
In I think aerospace, and defense is a very broad sector that has its own rules and regulations that are governed by military. Whereas in manufacturing that's not related to aerospace and defense. The, there's one or the other, there's not usually two, like I don't know, I know the CIO at Ford, but I don't know the CTO at Ford, unless they're specifically in manufacturing parts. But like Ford, as an example is trying to rewrite all of its software, because it outsource it over outsource and couldn't make anything talk to anything else. They're a perfect example of virtualization or what I would
I would bet that it's it's a separate role at a at that scale of manufacturing. Maybe smaller manufacturers maybe not so much.
Um, the US is laggard, right. I mean, I could tell you that Mercedes, yes, it might be two roles, and one, but they actually have five or six different CIO and CTO roles within the same level, because they're all focused on very specific parts of the vehicle, like the LiDAR, and the visual aspects, right, where you need those analytics happening, or the batteries, right, as they're becoming lithium. So moving from combustion to evey, so they have very dedicated teams for those kinds of things. But at the at the, to the point that Rob I think is making, you don't have a lot of IT leadership, that's conversa janotti. And similarly, if the inverse right well, or worse,
we could broaden that and say, conversant in the product side of the business in general. So that could be the building factoring. And as well as the like I did a few years ago, we sat down with the CIO of Manhattan associates, which is an SAP competitor. And he didn't know squat about I mean, he knew like the the high level, you know, marketing level of the product, but he didn't he didn't have any interest or deep knowledge or involvement in in the technology or the product strategies that the chief product officer had their chief architects and engineers, and that was a separate, completely different organization. And I got the feeling that they don't even really talk.
Well, I think that that's changing very rapidly, only for For two reasons, one is, you know takes a comment about North America or rest of world outside of Europe being laggard, they're very quickly catching up, because they have no choice in order to compete. But the other part of that is that the fluency of cyber physical systems is now coming to the forefront with things like Chachi, TP, PT, sorry, that was it backwards. When you want to get AI in manufacturing, that's not part of a visual inspection system or something else. And you're looking at using that as an HMI. That's what's going to drive the convergence. And since happening more more quickly, and in leaps and bounds.
Some of it, I think, is also examples where people are, companies are being successful doing it, they're showing the ROI. In very dramatic ways. I you know, and I'm, I'm not a huge fan of, of the person who claims credit for SpaceX. But, you know, one of the things that I think is SpaceX is really remarkable for is that they, they're not building rockets one at a time. And it's similar to what we're talking about, right? The mistake that a lot of OT and IT people make is that they're like, I'm just building this, I'll get it done once, and then I will do it. That, you know, with CI CD pipelines, you wouldn't build a project. Now, without building the CI CD pipeline. First, that has been a remarkable turnaround in industry, you know, this idea that, you know, I'm building a rocket company, I'm building a rocket assembly line first. And, and, you know, will that once I have that iterating on the rocket becomes easier. And I think the thing that we're missing here is the, the now we're full circle, I T is good at iterating. And ot needs to learn that behavior. But OT is good at keeping things up. And it needs Fleur that behavior. But this fast iteration cycle, I think when people see it, it changes the game for what you can get away with. It's like, just in time inventory from that perspective. And we were on the edge maybe. Versus just in case. Yeah. Yeah,
no, no. But you do see it at Mercedes, you do see it at European automotive manufacturers. You do see in at Bosch, there's a there's a whole pocket of Eastern Europe that's so dedicated to this, that it's as fluid as Tesla. Right with SpaceX, we're going to build the pipelines, we're going to build the the capability of doing, you know, mass production, what they didn't figure out. And this is going to be another thing that just kind of is very disruptive, is that by giving people things like Gen AI, to work with, that they're now bringing the end user consumer all the way back to the EDA side. By giving them the fluidity of saying to a system, I want my shoes to be this level of cushion, this amount of millimeters dropped from the front to the back, the materials to be recycled or vegan, etcetera, etcetera, etcetera, they can basically build they're built to order for a consumer of one. There, that's why the automotive industry right now. That's the apparel industry right now. It's gradually changing industry by industry sectors. So in Tyler's case, for example, it's not going to be long before you have the fluidity of you know, Northrop Grumman doing one part and Lockheed doing something else. And Boeing trying to get its little nose in there and being shut out because of defects. It's, they're all going to be able to do this in one form or another, because they're making the point that if they don't, nothing will work.
It's like, why they were I agree with you, Joanne. That's where it's coming. My fear, though, is that that the status quo will will persist until there's a shooting war. And we start seeing the economies in an asymmetric warfare like the $10,000 drone taking out a $10 million dollar tank.
Yeah, but wouldn't you agree that like on I think it's, I'm gonna get it wrong, I'm sure but the B one bomber and all old all old equipment that's been around for like 35 or 40 years or even 50 years that they still have in service that they want to upgrade, that they're now scrambling, because they can't. They're having to remanufactured, the originally designed parts to keep them from the maintenance side. So that's going to force a lot of change and the fluidity of design. Well,
they weren't they weren't, like out 30 fives on their G version, I think. And and basically the only thing that a version and G version share is the the windscreen and the airframe, as at but But what I'm still saying is there's always still a single contract holder, it's Lockheed Martin, and they still control the architecture 100%. And they use that control to aggressively lock out the Boeing's and the Northrop's. And I've seen actually, I've seen it go back, since we had since we had the new leadership with the new president, and they've gone actually gone back, they've regressed, they've gone back to the old more the old way more the traditional acquisition model that they use. So yeah, I mean, I agree with you. I'm hopeful. But that's not where we're at today, that's for sure. At least in the US military?
Well, I think it's, I think you're gonna see a lot change between now and 2026. Just because of the not only the technology advancements that are being made, but also out of necessity. And so I'm not sure whether the problem will have convergence will go away over that period. But there's going to be disruptors that will influence the time that it will take for that convergence to go, you know, for the issues to become a converged or unified sort of system. And operating system for the shop floors for plants and manufacturers will be one of those disruptors that comes up before that time period.
interesting to think about Yeah, I feel like there's we're there's there's a lot of motivators, there still isn't quite the killer, the killer feature, or the killer reason for the security. Security would be a good one. And Jen is the one. That is the one. All right.
Yeah, and I think AI is going to be a big driver of the speed of change here.
And that is true. You don't have time with with AI to build proprietary systems. That's the interesting. Maybe the interesting takeaway here is, is a lot of the stuff we come back to is security or AI innovation. You don't have the time. This proprietary systems take a lot of time. So
I just had a thought so if if email was the killer app of the internet, is AI the killer app of industry 4.0.
Know what kind of AI or think talking about here?
Okay. Too many too many. Too many flan analogy doesn't work so well, but
too many flavors. But yeah, you're onto something there.
I mean, there's, there's a pushing force. And for the internet, it was email and for industry 4.0. It's all of the changes. It's going to be
Yeah, but I think you know, to pick up Joanne's point, before she does, it's going to be digital twinning. From that perspective to the AI AI or AI use case is actually a digital twins use case. Let
me just throw in a little history here because I've got the scars to prove it. When we tried to standardize on electronic mail on commercial electronic mail services, the big vendors the at and T's Telenet CMCI, as everybody else gave lip service to the standardization. They sent their people in for standard email protocols and directories. But what they put in play Ace was absolute crap. And it wasn't until I assumed the vice chairman ship of the EMA and went out and went to El all of the petroleum Association's electronics associations. Air Defense, and basically said, You guys have got to put the pressure on these folks. Because you cannot talk to one another using their commercial email systems. They're still trying to lock you into their services. So basically, I stack the deck and got, you know, American Petroleum and AEA to come in and to basically put a gun to all of this providers heads and said, you either put real standards in place for interoperability or interworking. Or work, we're going to somebody who does, you should have seen how quickly they moved. But it should have that kind of gun to the head. And
to basically happen. Innovation needs a not so gentle push sometimes.
Well, that's well said Carter.
Well, rich, the same thing happened with b2b. You, you know, I mean, look at Rosetta net, look at GS one. They did exactly the same thing. I remember distinctly having conversations with fighty shahadi. Over are you carrying a carrot? Or are you carrying a stick? Yeah. And his answer was I'm carrying a stick? And my answer was, but I can get farther with honey than you can with vinegar. You know, and eventually they came to be, but I understand it 100% of what you're saying. And I agree with that. 100%. But what I'm also starting to see and you can't leave this as just a little chink in the armor to standardization, is that the resurgence of old ways are becoming new again. Mean vertical integration. Companies are
doing vertically integrated. Yeah, no and more than they did before.
And that goes back to the whole Clayton Christensen. model, right. You know, over time. Hey, guys, I gotta run.
Me to? Yep. Okay. We we have we're way
over this was a great conversation. All right. Yeah. I'll talk to you next week, Mike,
I
wow, there are so much to unpack in this concept of it versus OT, and what pulls one group into the other camp. And I really appreciated how this conversation morphed into that type of thinking, how do we get the benefits, and the needs met of each group, really core thing to think about, and I and I'm really excited to see some of the changes going on. And I love the way our group analyzes the cross cutting concerns that actually can impact people's careers, and day to day lives and their enterprises and how they deliver technology. This is interesting to you. And if you're listening all the way to the end of this podcast, it probably is, please feel free to join us at the 2030 dot cloud, check out our schedule and be part of the conversations. Let us know what you think we really do want to hear from you. Thanks.
Thank you for listening to the cloud 2030 podcast. It is sponsored by rockin where we are really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly or just keep enjoying the podcast and coming to the discussions and laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you