Platform engineering on the edge: The fascinating real-world scenarios

Darren and Pinja continue their series on platform engineering on the edge by diving into some of the most fascinating real-world use cases. From software updates on the Voyager space probes and Antarctic research stations to cars, planes, and even grocery delivery robots, they explore how platform engineering makes these edge deployments reliable, self-healing, and secure. This episode is full of stories and lessons on what it takes to manage software far beyond traditional data centers and clouds.

[Darren] (0:02 - 0:22)

There's always the joke that people used to make about if you brick the server, you have to drive three hours to go press the reset button. Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development.

[Pinja] (0:22 - 0:32)

Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna.

[Darren] (0:38 - 0:49)

Welcome back to the DevOps Sauna. Today we're going to be talking about some things at a distance we don't usually get to discuss. Joining me today is, of course, Pinja Kujala.

[Pinja] (0:49 - 0:51)

Hello. How are you doing, Darren?

[Darren] (0:51 - 0:58)

I'm doing reasonably well. I'm looking forward to the topic we have today because it touches on a lot of things I'm kind of nerdy about.

[Pinja] (0:58 - 1:25)

Let's talk about nerdy stuff today, and this is actually a continuation to something we've talked about before. In a previous episode, we talked to Sofus Albertsen about the platform. We're talking about edge computing.

We're talking about Kubernetes. And then now we're going to platform engineering on the edge. And this is actually a second part of an episode series on platform engineering on the edge.

And today we're talking about case studies. What is it actually where we use platform engineering on the edge?

[Darren] (1:26 - 1:52)

Yeah. Now that we discussed the basics in the last episode, we went through some interesting areas where we might consider platform engineering and deployment procedures to be applied. And we're actually going quite a distance for these ones because when we're talking about edge cases, we're talking about things outside of traditional data centers, outside of clouds.

And you don't get much further outside of any of that than the Voyager space probes.

[Pinja] (1:52 - 2:16)

Correct. So we're covering quite a distance here, not just for that, but we're actually going from outer space outside our solar system to maybe actually even your fridge and maybe your kitchen. How do we impact that?

If we go back a little bit before we go into the cases, we said platform engineering on the edge, but somebody might argue that is this even platform engineering? So if we talk about semantics for a moment, Darren, what do you say? Is this actually true?

[Darren] (2:16 - 3:02)

Yeah. Platform engineering. It's kind of in a weird position.

The focus of platform engineering is to build this internal developer platform. The developer experience is the key to platform engineering. So talking about the deployment cases might be considered by some to be outside the sphere of platform engineering.

But for me personally, it isn't because if we're talking about platform engineering, what are developers doing except building software that is in use somewhere? It's like if you don't cover the deployment case of your system, then you're not doing CI/CD. And by extension, I think that means you can't be doing platform engineering.

You have to get your software somewhere so that it can be useful so that anyone can do what they need with it.

[Pinja] (3:02 - 3:28)

So let's not get stuck on this terminology, I guess is the message here. And anyway, we're talking about deploying stuff, right? And DevOps or platform engineering is nothing without deployment.

But if we go now very far, let's start as far as we can with the known cases that we have. So let's go outside the solar system. So space stuff first.

So the Voyager probes, they have now exited our solar system, haven't they?

[Darren] (3:29 - 4:02)

I believe so. Yeah, they're now currently in interstellar space. They've been traveling for 47 years and eight months at this point.

So that's obviously quite a long deployment time. I hope most people don't have a 40 year release cycle of their software. And the reason we're talking about Voyager is actually because in 2022, a data glitch happened where the incoming data was garbled and a patch was applied by NASA.

And we just want to talk about how monumental of an undertaking this was.

[Pinja] (4:02 - 4:20)

And we're talking about a distance that I don't think anybody, one of us who's not actually working with space stuff can really understand because we're talking about something being out of our solar system. And the delivery itself, the delivering of the batch took over six months from here to the Voyager.

[Darren] (4:21 - 6:03)

Yeah, that's the thing. If you look at your phone, you're receiving data at megabits a second. What you have to understand about the Voyager probe is its receiving and transmitting at bits per second.

So it's several orders of magnitude lower than what you would expect. So for example, we can talk quickly about the Mars rover because we don't have a lot to talk about the Mars rover other than there is a software update in 2023 that was 21.921 megabytes that was split into 51 files and sent over 10 days. And the transmission distance to Mars is about 17 minutes in ideal situations, I believe.

So consider a transmission patch to something leaving the solar system. You are working, basically the more power you can put behind a bit space, the further your signal can get. So if we think about bits as ones and zeros over any specific length of time, if your bit window is extremely small, you can get lots of data in say 10 seconds, but your transmission strength is not as strong.

But if your bit window is longer, let's say you only get one bit per 10 seconds, you can transmit a lot further. And that's actually how Voyager receives its software updates by having extremely long bit windows. And that's why this small software patch and what we have to consider about Voyager is it's still using assembly and Fortran.

It's still using these languages that are basically archaic at this point. So just the fact that they were able to put patches together for Fortran and assembly is kind of impressive. But if you then think about the transmission length.

[Pinja] (6:03 - 6:38)

Yeah, that's even more impressive, I think. And we're talking about technology that was shipped outside of Earth 47 years ago, almost 50 years ago. And I'm thinking about how the lifetime of this device is far longer than what we consider, for example, like our laptops maybe last for three to four years.

And if we think of cars, which we're going to talk about a little bit more in detail later in this episode, like I have not seen anybody actually driving a 50 year old car actually in their daily life, to be honest. So we're talking about far longer times here.

[Darren] (6:38 - 8:29)

And that's the interesting thing about a lot of these edge cases, because as a standard technology user, you will think, yes, this technology is outdated and you rotate every three years, five years. But in actual fact, when it comes to operational technology, the time to live for industrial devices, which is a lot of the use case for any kind of platform engineering on the edge, is 20, 30 years. I think much of the Helsinki power system, for example, was installed in the late 1800s, early 1900s, and a lot of it hasn't been updated since.

So you have these like times to live, which are extremely different from consumer devices. And if we look at the specs for the Voyager craft, they're like they're running CMOS with like, I think it's 72 kilobytes of memory. So it's not even the size of an old floppy disk, which was 1.4 megabytes. That's how much space they're using. And for reference, the Voyager probes are probably not going to last all that much longer. They have three separate times to live.

So they currently have, this is kind of off topic, but just, I think it's interesting for people who are curious to know about it. Firstly, they're powered by a radioactive thermo generator. So the decaying of an isotope, which is actually putting out less and less power.

There is the fuel hydrazine, which is used to position the communication array by maneuvering the craft. And then there's the deep space network range, and at least the DSN range is likely going to be lost within the next five years. The RTG, probably the fuel might be the last to go, but basically Voyager is very much at the end of its use case.

[Pinja] (8:30 - 9:00)

It will be interesting to follow up on this, but NASA themselves have published information on how they work and what kind of tools they are using. And on their website, actually, there is a list of a couple of tools that we found to be familiar sounding. They mentioned GitHub, GitLab, Bitbucket.

And also what this was a curiosity that really sparked our interest was that they said that they are now strongly considering instituting agile ways of working into their software development. I think this was a list from a couple of years ago, I think, but it's still quite accurate.

[Darren] (9:00 - 10:12)

It's more like these are guidelines that people inside NASA should consider using agile ways of working because they're so large, they make suggestions rather than demands, I guess, and people decide to follow them. But it was kind of interesting. They also mentioned using watchdog timeouts to prevent software from hanging and provide safety valves.

And this was interesting because this is exactly what we were talking about with Sofus and talking about last time, the use of Kubernetes on the edge. Because if we look at the Voyager system, what happened was it was sending information in 2022. It was sending information to a system that was no longer functional and it was gobbling the data.

In a case where Kubernetes is there, you can have a check running natively and a fallback situation running natively. Obviously, they launched it 47 years ago. So Kubernetes wouldn't have been an option, unfortunately.

I don't think it would even run on the hardware. But the idea of this self-healing, setting a standard, testing against the standard all on your device to basically get that immediate feedback is kind of critical for any kind of space operations.

[Pinja] (10:12 - 10:31)

And NASA has a very well-documented performance of the code on their website, publicly available as well. So this is something that is mentioned. They share their best practices.

And this is what they're actually describing here. They're using the tools, looking at the performance of the code. So I guess this is what we might describe as, well, DevOps.

[Darren] (10:31 - 10:46)

Yeah, they don't come directly out and say it. They don't say we use DevOps. But reading between the lines is very much, we adopt this DevOps practice and this one and this one.

And it's just like a laundry list of, yeah, we do DevOps. We just don't say we do.

[Pinja] (10:46 - 11:05)

But from space, from different planets and outer space, let's come back to our planet Earth. So another use case for doing platform engineering on the edge is actually our research center in hospitable environments. And one example that we're going to dig down a little bit more deeper here is the McMurdo Station in Antarctica.

[Darren] (11:06 - 12:15)

Yep. McMurdo Research Station. It's basically the primary operations facility in Antarctica.

So I think the biggest thing it does with regard to this is radio comms for the area. And radio communication is kind of interesting in that I believe it used to be a mechanical thing that a radio worked in the way a radio works. But the advent of the software defined radio, which kind of had massive implications on the security field.

So that's something to maybe talk about another day. But software defined radios, I feel like are another good use case, especially if you have a communication hub, being able to test those linkages automatically, test those radios automatically and patch issues with them to ensure communication. Because if we're talking about, there's always the joke that people used to make about if you brick the server, you have to drive three hours to go press the reset button.

And that's not possible in Voyager. And it's probably extremely difficult to get to McMurdo Research Station and press the reset button on one of those radios.

[Pinja] (12:15 - 12:42)

So yeah, that's, that's very true. And if we think of the area itself, it is being connected by the Starlink system, isn't it? So there are buildings that are in these kinds of places, and they are benefiting from the satellite connection system, such as Starlink, which is serving Antarctica as well.

So it is still aimed at land and coastal waters. So I guess that's not the most ideal place to have software updates anyway.

[Darren] (12:42 - 13:26)

And that's, that's the thing, like land and coastal waters kind of ignores the fact that getting there requires vessels. I mean, I think Starlink does have some luck with vessels depending on the speed it's traveling. So it's kind of interesting how this in itself is changing, like things like Starlink, things like satellite internet connections are actually bringing connectivity to places where they never could have been before.

But we also have to consider the quality of the connection, because depending on how well they're covered, they may experience these connectivity losses. So considering things like Starlink is also kind of important. We have to understand that they're part of the ecosystem now, and allowing for these things like remote access to inhospitable areas.

[Pinja] (13:27 - 14:01)

Speaking of inhospitable areas, let's come to Europe and Norway specifically. This is something, a place that is reachable by an airplane. They have their own airport, and you can go really as north as Svalbard here.

So trying to preserve some of our seas, or actually most of our seas, and our plants on planet Earth, there is a crop trust Svalbard seed vault. So this is a place that is physically distant from many places. It is a cool and dry place.

It is designed for extreme longevity. I think it's, is it a thousand years of storage time in this place?

[Darren] (14:02 - 15:02)

Yeah, claimed to be a thousand years old, and it's not clear what kind of software they're running. But from my perspective, it seems it would be surprising if they weren't orchestrating control systems for vaults using something like Kubernetes. Maybe not directly Kubernetes, but some kind of orchestration system where a central node is controlling each of these storage bays, because they have to be kept at specific temperatures.

They have to be kept at specific humidities and very specific environmental conditions to ensure longevity. Okay, so talking about Svalbard, there are a couple of interesting things about it. And one of them is, as you said, it's the most remote place you can get a commercial flight to.

And that gives it some advantages. It means if you do break the server, you can actually travel there and reset it. It just takes a bit longer.

But the other interesting fact is the polar bears. Did you know that? I mean, I've heard the rumor.

I don't know if it's true that you're supposed to carry a shotgun by law on Svalbard because of polar bears.

[Pinja] (15:02 - 15:21)

I don't know. I've heard the same rumor. And I have not been to Svalbard myself, personally, so I have not been able to verify this.

But it's the same. Sometimes we get the question. We're both living in Finland, Darren and myself, and sometimes we do get the question.

I don't know, Darren, if somebody asks this from you, but do you have polar bears walking on the streets? Yeah.

[Darren] (15:21 - 15:22)

Do you have polar bears?

[Pinja] (15:23 - 15:33)

No, we do not have polar bears, but Svalbard definitely does. So that's one of the key features. And I guess the rumor is indeed that you're not allowed to go outside without that shotgun.

[Darren] (15:33 - 16:49)

Yeah, I think that's a thing to consider. But it actually hasn't put people off because there's this Arctic World Archive, which is kind of literal cold storage for data. It's similar to the Seed Vault.

We're looking at data storage in an extreme climate. And the idea of this is actually quite interesting. So Svalbard has this natural feature that Finland actually has too, and it's the idea of cooling.

So the idea of leveraging natural resources using edge-based computing and having platform engineering to support that isn't new. We can look at Google's data center in Finland. It's in Hamina, and it's built inside this old paper mill.

And the idea of it is that it has these pumps, which there's this layer of water called the thermocline, which is basically where it has a stable temperature. And the idea is that it has pumps to pump water up into the plant through the servers to act as environmentally friendly cooling. And Svalbard has that same option, the idea of being able to use the natural environment to cool what is a high computes processing requirement, and obviously high heat dissipation requirement.

[Pinja] (16:50 - 17:19)

And if we're thinking about maybe Finland is a little bit more reachable than Svalbard, and yes, we do not have those polar bears. But then again, it's maybe easier to just basically drive out there and reset it from the bottom if we oversimplify it a little bit in Svalbard than it might be in Antarctica, since there are those commercial flights to Svalbard. But at the same time, I highly doubt that all the developers are actually in Svalbard for both the data storage that there is, the Arctic World Archive, and the crop trust seed vault.

[Darren] (17:19 - 18:40)

Yeah, I'd imagine most of them aren't there or spend a little time there. And that's actually what the idea of platform engineering on the edge is. It's to, in a way, ensure that this remote work standard that we've set for ourselves over the last five years continues, in that it's knocking down the walls of deploying software in cases where you may have needed to be local.

And there are actually discussions on that. One thing is the idea of this air-gapped network. So for example, air-gapping is just physically separating the network from another network so that it's not connected to the internet.

And actually, from a cybersecurity standpoint, we know that's not enough because, for example, it was 2004, but I might be wrong, when the Iranian nuclear tests were derailed by malware designed to be transmitted through an air-gapped network. So this air-gapping is actually an interesting discussion point that we're not really going to touch on here. We'll touch more on it in our next episode when we're talking about security and platform engineering on the edge, of course.

But now we've talked about the extremes. We've been off the planet. We've been in the most extreme places on the planet we can think of.

Let's talk about something a bit more day-to-day. Let's talk about planes.

[Pinja] (18:40 - 19:05)

Let's talk about planes. They might be more day-to-day to us, distance-wise, they're some 11 to 13 kilometers above us, but it's more day-to-day life for us to actually be on a plane, sometimes even just Svalbard. But those are massively connected.

If we think of the sensors and the sensor networks that it takes to keep a modern airplane on air, it's a massive effort. But of course, they need the software updates.

[Darren] (19:05 - 20:15)

And there have been some kind of high-profile issues, especially with the Boeing 737, and I was at Disobey, I want to say in 2020, where Chris Krodecki was talking about software updates onto planes, and it's actually no different than you would expect. But it's this idea that there's a lot of invisible software running when we don't expect it. And that's why we're talking about planes.

Most people think of planes, they think of engines, they think of radios, and they don't realize that there are computers sat in between everything, connecting everything, networking everything. They don't realize that that layer has been there for a considerable amount of time. And in difficult situations, the ability to revert to the last known good software can be critical.

And this is actually what GitOps gets us, which is a cornerstone of platform engineering on the edge. The idea that the authority who is closest to the device is capable of making the decision of when to update, when to revert, and has full autonomy over that process.

[Pinja] (20:15 - 20:39)

And I'm thinking of, if we take a large airline, in Finland we have Finnair, then we let's say British Airways, and let's say American Airlines, and their fleet of airplanes is huge. So it's not that they're going to go to every single plane and push a button. But if there is, for example, as you say, the cases that we need to revert to a previous version of working software, it can be done remotely as well.

[Darren] (20:39 - 21:18)

Yeah, and it's one of those situations where fail-safes are just so important. We talk about fail-safes in Voyager, and obviously if something happens there, then the mission is scrapped. But in cases of flights, we're talking about human lives, and actually the intersection of platform engineering on the edge needs to understand that the closer it gets to people, the more responsible for this they need to be, and that needs to be understood.

So if you're understanding that you are dealing with the lives of people, their health, their safety, you have to build software in such a way that supports them.

[Pinja] (21:19 - 21:36)

And speaking of everyday life and what people use, let's talk about cars. First we want to mention self-driving vehicles. It's not just that we're talking about the peasant-recarrying futuristic self-driving cars, perhaps.

At the moment, they're still not in commercial use so much, but for example, mining vehicles.

[Darren] (21:37 - 23:21)

Yeah, there's quite a lot of interesting developments happening in industry with regard to robotics and either self-driving vehicles or remotely driven vehicles. Like it's becoming more common to have drivers for cranes, for example, not be anywhere near the crane, but be sat in a control tower many hundreds of meters, if not kilometers, from the actual crane, especially in shipping systems. So when it comes to shipside cranes, the control tower control method is becoming more popular.

And this is actually another great use case because then you have two different edge nodes. You have an operator who's sitting in a control room, and then you have a massive device which is interacting with physical space, and these both need to be in sync with each other. They both need to understand what's happening in both directions.

And again, we're talking about fleet control because it's rarely just one of these devices. So if we're talking about self-driving vehicles, I think things like cranes, various mining vehicles, and various drilling vehicles. If I feel like, okay, one of my weird faults, not exactly a guilty pleasure, but I find it quite satisfying just to watch videos of industrial machines digging up roads, for example, that's just, it's very cool to see.

And then I see it from a point of view of the modern world where it's a driver having to go several hours out of his way, unload the truck, and then go back, where I feel like if he had a remote setup, he could just sit there with his controller while the truck is delivered. He could do the job and then not have to use those hours. It would be more productive for him, more interesting, and far more efficient just to be able to switch between jobs.

[Pinja] (23:22 - 24:02)

There's also the safety element here. I think it's like Caterpillar who's been mining these remotely controllable mining vehicles for quite some time now, and they use this as one of their marketing tools as well, that this is making the mining safer. And the person, the operator doesn't have to be in the mining vehicle, in the mine somewhere deep down, like under the surface of the earth, but rather they can be in the control room and they can do it.

And not only do they not have to go there, like actually use the time and be more effective and efficient, but it's also the safety element here. And even do the remote operations and also diagnostics with these vehicles now that they are so highly equipped.

[Darren] (24:02 - 24:06)

Yeah, but let's talk about something more pedestrian. Does your car have software updates?

[Pinja] (24:06 - 24:18)

Yeah. It tells me every now and again, like, hey, you cannot drive your car anywhere from the lot that you're desperately trying to go to the store, but can you please sit down in your car for the next 10 minutes and allow the software update to happen?

[Darren] (24:18 - 24:19)

Is that a common thing?

[Pinja] (24:19 - 24:23)

Not so common, but it does seem to happen at the most inconvenient times.

[Darren] (24:24 - 24:34)

That's interesting. I mean, I have the security angle. So for me, it's like, I don't trust something that would need a software update to my car.

I drive an old car specifically for that purpose.

[Pinja] (24:34 - 24:51)

My car, I think mainly the software update is concerning the navigation system and the screen that I'm using, the computer itself. So basically the, let's say we're giving you new features for the entertainment system. But of course I cannot see everything that goes on and what happens in a, in a software update.

[Darren] (24:52 - 25:04)

For me, I'm more of the guy who has the shotgun by the printer, just in case it makes a noise. I don't know what it's going to make. So maybe I shouldn't be talking about software updates in cars, but it's actually becoming a more common thing.

[Pinja] (25:04 - 25:40)

It is true. And let's, for example, the navigation system. So we do have the center computer in many of the modern cars.

And like, for example, there is a node for, just for the navigation, for the GPS. And we have telemetry, there is the accelerometer, we have speed meters, and many of the modern cars nowadays have the radar for the, is it adjustable cruise control, for example. So it actually reads how far is the next car from your car to keep a safe distance.

So you don't have to pay so much attention to it. It's a communication node for the satellite and the wifi in that car. But as I mentioned, all the other driving adjustments are steering and the brake also have that.

[Darren] (25:40 - 25:57)

Yeah. And all of these are computer controlled. Now there's also one we can't go without mentioning, which was the suggestion that BMW were going to start charging a subscription for heated seats.

I'm not sure they actually went through with that, but just the idea that someone sat down in a boardroom and thought that was a good idea is...

[Pinja] (25:57 - 26:09)

Well, maybe, because BMW is a German car. Some parts of Germany have cold winters. And let's consider again, in Finland it is a very nice comfort feature to have a heated seat.

[Darren] (26:09 - 27:12)

Mm-hmm. So across all these nodes, we have to consider that each of them is running software. Each of them is communicating with some kind of central computer.

All of this data is presumably uploaded. So the car manufacturer can know where you are at all times so they can sell that data. But that's a different discussion.

The idea that we'd have to push software to these while they are in maybe areas of spotty connection. I wonder if that's why you're seeing those pop-ups, whether it's like a, that you haven't updated in a while and now it's forcing, but it gets rid of that idea that the authority closest to the car, and that would be you, has the ability to say when you update and when you don't. The idea that you would be delayed because your car needs a software update is still to me quite foreign because ideally I don't want my car to need a software update at all.

But if it does, it should probably do it while I'm not trying to use it. And I'm guessing there are large times during the day, for example, where your car's just sat in a car park.

[Pinja] (27:13 - 27:38)

It is. And like, I do get a say in this, like, Hey, would you like to do it now? And I was like, yeah, sure.

But I also need to go and I also need to go to places because that's why I am in the car in the first place. But then it says like, well, you're not allowed to do it while you're driving it. So it does have this, the control like, no, it's not going to be done while you're driving, but it's not why I'm actually in the car.

So at least in my car, it doesn't do it if the ignition is not on.

[Darren] (27:38 - 27:59)

That's kind of a failing in understanding user experience, really. Like it should come with some kind of mobile app, which then connects to your phone and tells you, Hey, do you want to do the update now? You don't usually use the car at this time and you can go, yes.

Like the main purpose of a car is you get into it to go somewhere. It's not like you're hanging out in your car.

[Pinja] (27:59 - 28:06)

No, not usually. No, that's not a. Well, I don't know about others, but that's not the case for me.

So I go to my car to get to places.

[Darren] (28:07 - 28:15)

Yeah. If I'm going to my car, it's very much because I have somewhere to be. OK, so let's talk about the last step.

We've gone quite a distance already.

[Pinja] (28:15 - 28:44)

We have. We've managed to get to our car park and carports, maybe your garage. But this has been a discussion for a while now.

How do we make the last mile delivery faster, more effective, more convenient for us? So let's talk about delivery robots. And especially in Finland, we see these.

Some people consider them cute, small robots that come from a grocery store and they carry your groceries and they have this little flag to say like, hey, there's a moving vehicle in here. And they also need some kind of updates, don't they?

[Darren] (28:44 - 29:00)

Yeah. And we can only speculate because as much as we tried before this episode, we weren't actually able to steal one. I've been stalking them around Tampere to see if I could grab one.

But people have always been looking. So if you work at Alepa, please invite us to look at your robots. We want to know how they work.

[Pinja] (29:00 - 29:33)

We would really like to dismantle one of those. And yeah, we're going to be honest here. No, we did not.

For the purpose of this episode, we did not manage to steal one. But we probably should have. But just thinking of the features that these robots have.

So, of course, they need to be able to evade the collisions. So there are multiple things that they can bump into when they're running on the street. They need to be able to understand crossings.

When is the light green? When are they allowed to go? Is there a car coming?

But also the communications for the person who's receiving their groceries. Like, now is the time to open the container and pull out your groceries.

[Darren] (29:33 - 30:48)

And then having some kind of pressure sensor. So they know on the pad where the groceries are. So they know when the things have been removed.

And we also have to consider that they need to know where they are. So they need GPS. And also as an emergency system, they need telemetry.

They need to know whether they are on a horizontal plane or whether they have tipped, for example. To alert people. So this is actually an excellent use case for Kubernetes in an extremely small and, yeah, as you say, very cute package where you have a, you could have a central node and then sensor nodes attached to these GPS, attached to this, basically this level meter attached to a communication device.

Communication will probably be part of the central node. But all these different features are then being spun up in these destructible containers that if something goes wrong, they can just be restarted. And it's like it's this self-healing that makes it possible.

Again, I don't know what's running on these robots. I'd really like to. But if I was going to build them, I would probably use Kubernetes on the central node and deploy all the software to external nodes through that so that I have that level of fleet control.

[Pinja] (30:49 - 31:08)

Yeah. So we've gone to space. We came back to the face of the earth.

We've gone to your garage and now we're in your kitchen. So there are many samples where platform engineering is done on the edge. So it's not just a couple of examples.

Like we're going to look at the Voyager probe, but instead it is actually closer to us than we might think.

[Darren] (31:08 - 31:45)

And I think it's important to know that we, when researching this episode, pulled in all the examples that were most interesting to us. So we weren't talking about power stations or factories or any kind of SCADA control systems or any of those things that hold infrastructure together. We were looking at space and robots because they were fun to examine.

But the use cases of platform engineering on the edge are just massive, especially if you want to operate with any kind of connectivity. The considerations needed for these deployments are they're worth looking into because you can streamline a lot of things.

[Pinja] (31:46 - 31:59)

That's true. And so now we have covered platform engineering on the edge 101, the very basics in the previous episode. Today, we were talking about case studies.

And in an upcoming episode, we're going to be talking about the security aspects. So don't forget to tune in.

[Darren] (32:00 - 32:04)

Yeah, we hope you join us next time. And that's all from us. Thank you for joining me, Pinja.

[Pinja] (32:08 - 32:10)

We'll now tell you a little bit about who we are.

[Darren] (32:11 - 32:14)

I'm Darren Richardson, security consultant at Eficode.

[Pinja] (32:14 - 32:18)

I'm Pinja Kujala. I specialize in agile and portfolio management topics at Eficode.

[Darren] (32:18 - 32:21)

Thanks for tuning in. We'll catch you next time.

[Pinja] (32:21 - 32:29)

And remember, if you like what you hear, please like, rate and subscribe on your favorite podcast platform. It means the world to us.