DevOps Workflows and Edge Computing Platforms – Nicolas Rabault, Luos

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Nicholas Robo. Who is CEO for Lewis? And we're talking about.

Embedded systems software updates how we're gonna put microservices on these platforms and in general how we're going to bring devops to the edge. Hey Nicholas. Thanks.

Hi Mike. Nice to meet you. Fundamentally, what do you think the challenges?

I mean, we are putting more stuff out at the edge. We have more embedded systems than ever. We have some devops processes, but where they really design for the edge and what do we need to make all this work?

Yeah, I think you're just point. The main thing today. There is not really existing tools for a merit systems allowing to deal with the devops way.

So what we are doing at yours is that we are developing a microservice orchestrate or dedicated terminate systems rowing embed system developers to use the same kind of methodologies, but for electronic devices and I think a lot of people somehow think that the platform or the provider the embedded system is going to help manage that but it seems to me there's a lot of different kinds of embedded systems. So do we need something that feels like an overlay that is specifically designed for software development on these platforms. And what does that look like?

Yeah, there is a lot of different embedded systems depending on. What you what you do? You can have a lot of different work depending on what you are developing.

You can develop embedded system using embedded Linux. For example, so in when you are developing on top of a Linux, this is really close to a normal software developers and that you could develop on top of a real-time operating system, which is like extremely Light operating system. Most of them.

You don't have like five systems. You only have like a scheduler or in each deal with multiple test. And also sometimes you we can develop directly on on something we call bare metal.

So without any opportunity system. We just have the hardware and we have to deal with it. So depending on where you are working on you have a lot of tools are not tools at all.

And when you're working on top of yours are Phoenix, sorry sometimes You can use existing tools allowing you to deal with with this kind of agility on how to create your software. The way software developers are doing it today, but the closest two-hour choose a hardware You don't have tools when you are close to the hardware. So when you are developing using dermital directly, you will not have any tools allowing you to deal with this kind of methodologies.

So on most of the time there is a lot of different embed systems everywhere. We are using this kind of devices every day on a lot of embedded systems have multiple electrons boards inside. For example, I know cars cars have a lot of cars inside you can have multiple boards on a lot of different devices such as the Hoven you have at home.

There is multiple board inside too on all of those, but there is a small computer. Ability to rent a small piece of code exactly the same and we have the exact same problem we have when we are developing. I don't know web applications because when you might develop a web application, we have multiple servers running small applications and this allows you to avoid any default when I don't know one server crash, for example, you have to duplicate this application that we need to deal with it.

We have the exact same kind of things but in the retraining devices But we don't have any tools allowing us to deal with this kind of configuration with this kind of distributed configuration. So Just first to begin most of the time we don't have any kind of default Network such as we can have a normal software industry. So most of the time depending on the application, you have to select the good network and to create the complete protocol on top of it.

Which takes a lot of time on can generate a lot of mistakes. We don't always have a way to have multiple tasks running in Dayton gold. And so we need to be able to find a way to get information from the network and to put it into the good parts of your code.

All of it is extremely difficult to do on specifically when you have something like 20 or more boards in a device this became like a nightmare when you scale the product and if we think about electronic devices following this way of small computers working together using a specific Network. We can apply the exact same methodologies. We are seeing on the normal software, but the big difference is that we can't use the same tools because we can't run the tools.

We are using on the software world into extremely small early train devices. If that's the case, I mean are we going to see microservices based applications running across these distributed platforms and a lot of that will be embedded systems talking to embedded systems not everything is going to go back to the cloud. So we prepared to manage at that level of scale because it seems like it's a lot different nuances than just merely throwing up an application on the same cloud or in a data set.

Yeah, I think yes, we will start to see a lot of different applications using microservices for the embedded devices. And also the big challenge is to be able to link those embedded microservices to the normal microservices using normal software things because today most of the device are connected so we need to have A standard way to exchange information between embedded microservices and software microservices and to do that we can use API because API can work on any piece of software. So we just have to find API allowing to Be sufficiently optimized to work on embedded systems and that can work on normal software.

And that's exactly what we are doing at plios. The idea is to be able to create. API on top of any kind of small services and then all those services will be able to exchange information and you can also use the same Library.

Directly into your software microservices allowing to link your normal software microservices with embedded one. and I think this will change a lot the industry in the future and there is already some companies that probably internally develop this kinetic Technologies. For example test slides a really good example for that because the slides already able to I don't know for example during the hear my hurricane.

This Tesla was able to update the car batteries to increase the autonomy of the cars knowing people on the area of this weekend to fit and today's something customers expect to have because they have it on any piece of software. But this is something extremely difficult to do and you're critical device such as a car and the main idea of yours is to provide a tool. Allowing any developers electric Developers for any product Developers for early train devices to be able to have the same kind of agility.

We've never been very good at continuous delivery even in the best of times that in the land of devops. So do you think that as we move to this embedded systems and we have all these distributed applications that will finally force the issue where we're going to have to look at the way we think about continuous delivery because frankly we've done a lot of good work on the continuous integration side of the world, but CD has always been problematic at best. Yeah.

Yeah, and I think we will have the same problems but In embedded word. I think it will be worst because today to update your car record most of the time you have to physically access the board. So you have to unplug everything and put a USB cable somewhere and to update it.

So it's kind of extremely difficult specifically if you want have like something 20 boards in a device. You have to impact all of them one by one and two update all of those balls. So at us we are we created something allowing to get back information from the network on to copy it into the memory inside directory box.

Exactly the same way we are doing remote updates with no more software and this allows you remote update any firmware anywhere on the complete device and this is something extremely important for for having a completely and so When we doing cicd, we need to get feedback from the devices and this is also something extremely challenging form but it systems because we don't have a lot of bond with the Wingers to get everything we need from the services on director inside. We don't have any screen. We don't have I don't know a keyboard or something like that are going to interact with those extreme boards and also most of the time Event on this kind of environment are extremely real time extremely with a really small time granularity and all of those are challenges that we have to to face to be able to deal with cicd in Emirate world.

And this is something we are working on with us allowing to get feedback from any information at the 90 seconds scale because we are dealing with nanoseconds must of the time when we're dealing with extremely real-time systems and allowing so developers to deploy any revision and I think we have the same kind of issues you mentioned today on the software world, but In worse because we will have a lot of different hardware and we will have to under all those different kind of Hardware which will be like a big challenge. As we go forward. How automated do you think all this can get I mean the challenge with CD in general has always been every one of these platforms is a snowflakes.

So it's been difficult to kind of distribute applications and code and update it. But, you know, are we on the cusp of some sort of significant Advance here? Yeah.

I think the big the big difference is that we don't have to manage. Hardware diversity when we are create when we created a program because in embedded system when you create a program. It work on most of the time it's work on only one specific Hardware with only one specific configuration and we don't care about I don't know operating system update for example, because we don't have operating system.

So we musterize everything on the firmware having us to don't have the same kind of portability issues that we have on the software. So we don't really need naturalization to for example So yeah, we will have some issues regarding this kind of thing, but we don't have the same kind of problems. The main problems we have is in when we try to develop a software that will be able to run on multiple kind of Hardware.

This is extremely challenging and to do that. We need to have a really good separation between drivers on applications because drivers rely on actual Hardware things, but applications. And avoid all those relation to the hardware and when you are developing this way, you can have portable application able to run on any piece of software just using the available drivers on the system and ateos.

We are considering Drivers Services. Because you have a lot of different different. Hardware features everywhere on the product so we can consider all those Hardware features are Services then applications can use any of those drivers anywhere on the complete device extremely easily.

So we don't have the same separation between a drivers on application that the one we have a normal software because we don't have those operating system holding those drivers for us. So we are creating services on top of drivers to make it possible. So do you think that there might be a backlash against the edge Computing when people figure out how hard software the appointment is and then we'll go through this cycle of disillusionment before we figure out, you know, how to automate all these processes and make it work.

Yeah, I think we had the same. Issues on the same needs of tools allowing us to automate the things. and The solution we will we will use on develop the same kind of solution.

So all the tools allowing us to automate the the trace management the feedback Management on on the deployment Management on the normal software tools will be also something useful when it comes to develop a hardware product and we will have to develop the same kind of tools and there is already some companies developing this kind of tools, but the missing piece right now is this main microservice orchestration to we don't already have so we you can find for example mintford is extremely interesting at the developing a trace manager or doing to get feedback from from military boards, which is extremely interesting and we will have to multiply this kind of tools during us to deal with The raising complexity we have today on the embedded world and to be able to deal with extremely complex software development and to get feedback from all those small Services. We will create in the future and and to deploy all of them. So we will have the exact same kind of problems and I don't think is more difficult to develop the tools allowing to manage all those Services into hardware and then the one which we already have for the software we will have By the way, this specific base will be exactly the same using the exactly same Technologies.

Alright. Hey necklace. Thanks for the insightful conversation.

Yeah, welcome. All right guys back to you in the studio.