In this episode, we discuss the value of integrating IoT connectivity with device management and we also explore the uses of edge applications and best practices for keeping edge deployment secure and reliable. 

Our guest today is Ed Hemphill, head of edge ecosystems at Pelion. Pelion is a division of Arm that provides secure global cellular connectivity and feature rich management for any IoT device or edge application.

IoT ONE is an IoT focused research and advisory firm. We provide research to enable you to grow in the digital age. Our services include market research, competitor information, customer research, market entry, partner scouting, and innovation programs. For more information, please visit iotone.com

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE, the consultancy that specializes in supporting digital transformation of operations and businesses. Our guest today is Ed Hemphill, Head of Edge Ecosystems at Pelion. And Pelion is a division of Arm that provides secure global cellular connectivity and feature-rich management for any IoT device or edge application. In this talk, we discuss the value of integrating IoT connectivity with device management, and we also explored the uses of edge applications and best practices for keeping edge deployments secure and reliable.

If you found these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have a business challenge you would like to discuss how IoT one can support you're welcome to email me directly at erik.walenza@IoTone.com. Thank you. Ed, thank you for joining us today.

Ed: Hey, appreciate it, Erik. Thank you.

Erik: So Ed, before we get into Pelion and the topic of edge, I'm really interested in understanding your background where you came from. I know you joined edge as part of an acquisition of a company that you cofounded. When did you first touch on the IoT topic?

Ed: Well, I previously kind of been involved in communications industry for a long time. So, years before, I'd been in the US Army, and did radio and touch communications and special operations, and then I later was at a startup that did video conferencing. And so during that time, me and a business partner got very interested in how do we automate things in a conference room? How do we automate things in a building? And that was the genesis for what became WigWag.

And so, WigWag was really focused on building a platform where you could interconnect very easily different devices. So you could say, I want this sensor to drive this action with these devices in this room or in this building. And it took us a long time to build a platform that could really begin to do these things. And as I'm sure a lot of people in the industry, the listeners of this podcast, no, it turned out the IoT and everything involved in it to do that was just massively more complicated than we thought it would be.

But in the end, we developed a pretty rich powerful platform, we ended up pivoting kind of towards commercial and it got ended up using a gas stations and sort of an age back control and things of that nature. And then that literally led us to partnering with Arm and where we are today inside of Pelion.

Erik: And I'm curious about the US Army experience. I was just interviewing somebody who was with the Israeli army, and then left and started up a company, also in edge computing, they were building chips for machine vision for specialized chips. The Israeli army is a bit famous for kind of spinning off startups. Is there a similar kind of anomaly or analogy to that in the US Army?

Ed: Well, probably not so much as an Israeli army. I just think that that technology, and of course, everybody in Israel is in the military, and has to be in the military at some points. There's so many people. And then Israel is such a technology focused country. And so much of their industry that I think you see more of it, of course, a lot of it around security and stuff like that.

But certainly, I think the military tends to test out a lot of new technologies that later make it into the mainstream. So, if you take mesh networking, the US Army was doing that stuff about a decade and a half before anybody else was with tanks, for instance. There's a lot of ideas and a lot of challenges that you have in the military in terms of robustness of communications, the fact that it just has to work that you have like really nasty environments in terms of RF and things like that to make things work.

So, I think people that live in our environment maybe aren't as daunted by the challenges that that IoT kind of has in it. And of course, IoT has a lot of the same challenges. You got distance problems. You've got buildings that you got to get RF through concrete, through steel. There's a lot of parallels, I think, between IoT and that stuff.

Erik: The military is early adopter of a lot of these technologies. So then WigWag was acquired by Arm. You we're director of Pelion edge. What's the status of Pelion today? Is it a business unit of Arm? Is it a subsidiary?

Ed: Yeah, so Pelion is a business unit of Arm that operates under the name Pelion for today. So, Pelion is essentially a separate operating company. And Pelion is really the genesis of a decade and a half of effort by Arm to create a very modern software infrastructure for IoT. And they started a long time ago, long before WigWag was a part of it, numerous acquisitions that built Pelion essentially along with a lot of in-house innovation from Arm itself.

And so what Pelion at the core of it is essentially a cloud service that allows you to connect both what I call device-to-cloud devices. So those would be things like little tiny microcontroller devices that typically would be able to dial up and talk directly to a cloud service because they have some kind of radio or capability to talk to the internet.

And then also, there's a whole edge and gateway component that I've been happy to be a part of the innovation there. And that's Pelion Edge. And so that's a big piece of what Pelion is, in terms of device management. But don't forget that also, some viewers may not know, Pelion also encompasses a huge connectivity piece. And the connectivity PV is basically a global MNO that allows you to get connectivity for devices all over the world. So essentially, you can slap a Pelion Semmen, and you can get IoT grade connectivity for a device that works in the vast majority of the world.

Erik: So the portfolio, you would say, is the platform, and then the SIM is this physical hardware, is this an eSIM?

Ed: Well, yes, so they support both physical SIMs, eSIM, and they have some other innovations as well. There's a management portal for the connectivity piece. I'm not the expert in that side of the house. But we're integrating all these services together. And so that's really why you see some sort of big names out there that are beginning to work with us, and that may be where people are beginning to see our brand out there is because they're able to go and they can get a contract set with us that allows them to get both global connectivity over through most of the globe along with a device management IoT solution. This just prevents a lot of work that would otherwise need to be done.

I mean, you can imagine if you were setting up a global IoT product, and you had to go out and you had to do contracts all over the world with various carriers, some in Europe, some in Africa, some in Asia, some in North America, and then you're building a product on top of that, it would be quite exhausting. So it's a way for our customers to accelerate all that getting done at the same time.

Erik: On your homepage, there's four kind of aspects of the value proposition: IoT connectivity, connected device platform, IoT versus management and edge application management. I think the IoT connectivity is fairly clear, easy to understand, so global connectivity with one SIM. What does this really mean? And how does one solution differentiate from another solution? So if we look at the connected device platform, what are the key functionalities here?

Ed: So the connected device platform is talking about the ability for you to have this portal capability that lets you manage anything that's in our IoT connectivity service and also lets you manage various updates that would be available to a connectivity device that's using our connectivity service, or the management of the SIM that's associated with that connectivity service. And also, there's a corresponding portal that goes to the device management service as well that allows you to do firmware updates and other things like that. So what they're speaking to there is sort of the gluing together of both connectivity and device management.

And then to speak to the other two, traditional device management from the Pelion perspective has been traditional application, but this will be I'm going out and I'm creating 10,000, 100,000 little widgets, and these little widgets, whatever they do, they're going to need connectivity to a cloud service that's going to be there for many, many years. And you need to be able to run that cloud service and guarantee that cloud service is going to be up for extremely long period of time, and have extremely robust over the air updates for that service. And so that's what traditional IoT device management has meant for Pelion.

And then of course, edge applications management, the piece that we're bringing, which is sort of the newer piece that I specifically am more involved with is Pelion Edge. Edge applications management is really saying, okay, I'm managing gateways in these edge boxes now, but now I want to be able to dynamically orchestrate applications on. So I want to be able to deploy this application now. And maybe a minute later, a different application or maybe a year later, a different application. And I want to be able to manage that using the same kind of DevOps techniques that you would use if you were managing a traditional cloud service. And so that's what we're offering in the edge applications management piece there.

Hopefully, and that gives people a differentiation of the four different things that you see there on the page.

Erik: And let's go a little bit deeper into Edge. This has been really quite a hot topic lately. I think there's some group of people that are a little bit still confused about what do we mean when we say Edge because they say, well, we've been using on-premise for 50 years, and then we the big shift was to the cloud, so everybody was talking about the cloud for 10 years, now we're talking about the Edge. How do you differentiate Edge from on-premise?

Ed: So if you hear the Pelion marketing and general product discussions, you'll hear the term on-premise and Edge. And when we say on-premise and our product line, we're typically talking about an entire cloud installation. So you could take our whole cloud service for device management, and you could run it and see an isolated factory where you might not have connectivity anywhere else.

For instance, if you've worked with Foxconn or any other large manufacturer, you know that in these factories, they basically don't allow any internet in there, and you're not going to probably even be able to use your phone because they want a secure environment for their customer. So if they're going to be using an IoT product, they're probably going to need an entire on-premise solution, an actual cloud in a set of boxes, set of small servers, that's running in that factory that allows them to run an infrastructure that's essentially confined to that building or that set of buildings or that [inaudible 12:07]. So that's what we mean by kind of on-premise in our product line.

But Edge, we're really talking about a much lighter weight solution that can go in any x86 or Arm Cortex A class box. And that would be a set of software that's really going to let you just deploy applications down line at a specific gateway. These days I'm trying to kind of move away from the term gateway also just as an aside because I feel like that makes people think it has to be gateway to protocols together. And I think we're beyond that now in IoT.

What we're really talking about is being able to just get an application out towards where the customer or the need is. In the security of factory, I want to be able to know how many factory workers have entered the building, and then at the end of the day I want to make sure most of those factory workers left and I want to be notified if they didn't. I can't move all that video up to the cloud constantly and expect to have a decent performance and a near real time performance on noticing people and counting and doing all the image processing necessary to do that.

So instead, we put that AI model down at the Edge. And that's an application. So now we're going to build deploy that application down at the Edge, it runs locally, and then it only needs to move the pertinent data backup to the cloud, which would be 100 people in, 100 people out, that sort of thing. On-premise is really more about running an entire solution somewhere, whereas Edge is about getting the application where it needs to be.

Erik: It does feel we're doing a tagging exercise recently, and we're looking at gateways and Edge computers as categories. But there's a lot of blurred lines now in this. There's different configurations that have different types of connectivity and intelligence and both. But it's hard to find a proper gateway for an industrial solution that doesn't have some degree of intelligence.

Ed: That's right. And what you're seeing too, Erik, is more and more of these gateways from traditional manufacturers, we don't need to name them but we all know all these various manufacturers that make gateway boxes. You're seeing more and more of those come out with pretty capable chipsets, whether that's like NVIDIA Jetson parts, which can do a tremendous amount of AI processing all the way to lighter weight kind of specific ML chips that can still do a decent amount of stuff if you're just trying to do lightweight processing and distill it down and put it to the cloud.

And it's a whole spectrum of stuff. Like, is caching technology an Edge application? Sure. Is digital signage an Edge applications. Yes. Is a [inaudible 14:47] an Edge application? Yes. And my view, Edge covers just a huge amount of applications. Could it be point of sale software, it could. And I think that really, one thing that's great for Pelion is that widens our potential footprint, the kinds of opportunities that we're interested in and helping customers solve.

Erik: Maybe we can get into that side of the business now. So, on the one hand, this is a very horizontal solution that could be deployed in many different situations. But as with any business, there's probably specific industries and types of companies that you work with, where's the bulk of your business today?

Ed: So we've seen a lot of traction so far at least in the Edge application space around industrial and smart building. And so that's been a lot of our focus. We're also quite focused on utilities as well. But let me talk about the industrial and smart building space for just a bit.

So I'm sure you're familiar with these terms, Erik, I don't know if all the viewers would be. But we have these terms, OT versus IT, so Operational Technology versus Information Technology. And what's been happening in a lot of these spaces where you have the merging of traditional old school PLCs or microcontrollers, sort of that hardware box that nobody knew much about that set the back, the control of the age back, or control the security on the doors and the ventilation in the factory, what's happened is slowly those things have become connected to the internet.

And it's taken a long time compared to a lot of the rest of other things that have been connected to internet, mostly because those things are mission critical, and you just can't mess them up without having big problems. And as they get connected to the internet, the IT folks in an organization start getting a little concerned about those things because a lot of times they haven't been upgraded in a long time, they don't know anything about them, the firmware is kind of a black box that no one understands.

So the people that are in these industries that build the boxes that control these mission critical things in buildings or in factories, they understand this, and they totally get this problem. And so what they're wanting to do and they are doing is they're beginning to create solutions that both provide a solution to the operational technology folks, but also meet the needs of a modern IT shop in a large company.

And so that's what we're helping a lot of businesses out with, whether that be folks like some of our publicly known partners, such as Honeywell or such as Johnson Controls, but also companies that are actually running factories, or companies that are doing specific vertical solutions for different industries as well. So examples of that might be stuff that's going on in factories, people that want to create security systems to monitor people or activities in a building and so forth. Anyway, it's that IT and OT merging together and this massive change that's happening is sort of the big theme I see out there right now.

Erik: But we've been hearing a lot about cybersecurity issues lately. I mean, we had the biggest pipeline in America hacked. We had then just last week the largest pig farm, Brazilian company, but with huge operations in America. And I believe in both cases, it was a bit more of the backend IT system rather than the operational infrastructure that was infiltrated. But still that shut down operations because they weren't exactly sure how is this going to impact. Edge, is their role, and let's assume you are going to be hacked, viruses are going to infiltrate it, how can you still continue operations?

Ed: So one of the things that I think's important to note in any kind of critical infrastructure that you're putting in is you've got to have security and depth. And I'm sure we all talk about this all the time, and that terms become very common. But for Pelion, what it means is everything that we've done in our stack has a security aspect to it, and is built to be highly secure. So as an example, we have a program called Pelion Ready for Pelion Edge. And Pelion Ready is basically where we work with gateway manufacturers to have Pelion Edge preinstalled and really ready for use by an end customer.

So what we're doing in that program is we make sure that manufacturers individually key every gateway that goes off a line, and every gateway that does go off the line having this unique key set, even if that gateway is compromised, it really cannot allow a hacker to easily access the rest of the system, whether that be or cloud services or get access to another neighboring gateway or so forth.

It's very important to have multiple security models really that are throughout your entire stack they're basically creating stopgap measures every time something might happen. Because the truth of the matter is if you run a global pipeline or you run a global utility, you will get hacked. And one of your devices will get compromised. The idea that it won't it's just ridiculous. But it's an issue of if it does, what is it going to do to my overall infrastructure?

And so that's where a tremendous amount of the thinking in the Pelion platform has gone into is sure something can be grabbed, something can be compromised somehow. Whether somebody gets physical access to the box, even solders chip onto it to do something, it can't be done. But if that does happen, what is it going to do to my overall strategy, and my overall infrastructure that I'm running? Is it going to kill me? Does it create a massive risk? And so we put a lot of stopgap measures in there to prevent that from happening.

So like, for instance, we can blacklist the single gateway, we can blacklist an entire manufacturer, if we had to. If we knew that a line had been compromised at a manufacturer, we could do something about that. So anyway, these are all ways to mitigate risk. But I think in all this stuff, I think what companies get asked themselves as they worry about these things is look, something bad will happen from a security perspective, but how am I mitigating my risk? And what are my stop gaps that are going to prevent it from a small fire to becoming a forest fire? That's our approach to those problems.

Erik: And then you have the reverse flow. So I think there you were talking about protecting the endpoint and making sure somebody can't move from the endpoint to the mothership. I think, in this situation, somebody hacks procurement system or some back office system, and then the concern is that this could impact operation. So I suppose they're either combination Edge computing or on-premise, that server would allow potentially operations to continue despite the fact.

Ed: Yeah, you're right. I mean, I think that's why our on-premise offerings continue to get a tremendous amount of popularity. And of course, we offer the Edge services as a part of the on-premise offerings too, So you can run Pelion-Edge services on gateways with on-prem. Obviously, with an on-prem, if you want an even more robust solution, then the clear answer is to essentially run isolated instances, or very lightly connected instances between buildings, or between major locations. And I do think that's one of the reasons that facilities like a major manufacturers, for instance, they're going to run pretty isolated systems because they’d realize there's a risk stuff could get somebody, especially an inside employee or something could allow access. And by keeping systems segmented, it prevents a lot of problems.

So, talking about going back to the military and stuff, of course, these are common practices across all militaries in the world. But for highly secure systems, you're going to run isolated systems. If they're highly secure, they're basically isolated because it's the only way to really create the ultimate stop gap between stuff getting out.

Erik: So coming back to the topic of industrial and building cases, I know you've recently signed an agreement or Pelion has with Johnson Controls, can you just give us a bit of the rationale behind this agreement? And how do you see these partnerships happen to move the business forward?

Ed: I can't speak at a super in depth level with the Johnson controls relationship. But I will say that across all of our deals, especially with an organization like Johnson Controls, it kind of comes back to what we were talking about just earlier. There's a great need to modernize industrial, and building infrastructure, and the IT and OT technologies associated with that stuff. And so all of these companies, what they're wanting to go to is a much more dynamic model where they're able to deploy applications that will very quickly.

So let me kind of give you a kind of a case study around this, but it's just sort of a general template of what we're seeing. Traditionally, these companies created a pretty rich software stack, a lot of times it was just this big monolithic stack that would go on a on a box, or perhaps it had some kind of modularity to it. But in any case, that stack was installed at the factory, and it was shipped out to a customer site. And maybe through a distributor, heck, it might have even set in distribution for a year before it got there. And it may never be upgraded again, Erik. It might have sat there for a decade and never have been upgraded.

There is stuff out there, as I'm sure we all know, that's running Linux 2.X kernels today. It's all over the place. And the bottom line is a lot of that stuff won’t get upgraded. And I think that's a lot of the things that freak IT shops out. So what they want to do, the common thing we're seeing with folks like Johnson Controls and other folks is they want to go to an infrastructure where they're going to be able to push out applications dynamically, which is a totally different game. So they want to be able to take a box, they want to be able to send that box to a customer. That box might not have a lot on it to begin with. It might just have the basic connectivity and some core applications. And then they want to be able to completely change the type of software they're delivering to that customer over time.

So they may say, well, you know, this customer needed these features from my building automation services, but now they actually want some full new service that I offer that has to do with energy management, or that has to do with access control to the building. And that's an entirely new application, but now I can provide it dynamically. And so that's a general theme that they need.

The second big theme that folks like Johnson Controls need is sort of a bigger picture, which is they want to be able to work with a provider such as Pelion that can provide them the connectivity piece, first of all, that they need throughout the world so that they can make a product and basically ship their product almost anywhere. And they want to be able to do that with a cloud service that they can choose whether they want to run it on-premise on their own hardware or their own infrastructure, or they can take the software, and they can run it on AWS, they can take that same software, they can run it on Assure, they can take that same software, they could run it on Google or whoever else.

And that provides them with a level of assurance and flexibility that they wouldn't get out of a solution perhaps if they were stuck on a specific cloud provider or if it was a solution that just didn't offer the ability to switch providers or to run it on their own metal if they want to. So I think there's two big things: the ability to deploy applications dynamically and remodel your business, and then secondly, being able to have the flexibility to go with on-premise or with your own any kind of cloud provider you want provides a tremendous amount of flexibility.

The cloud thing where I can choose which my cloud provider I can use, and I'm just continuing to use Pelion API's is super important now that you are looking at things like the changes that have happened in Europe with security, for instance, new laws that have come out of China that are changing where data has to be stored, and then a lot of other countries are following suit with those same thing. So these big global corporations that are creating products, they realize they have to have solutions that are going to be able to accommodate all these changing dynamics in the law. And of course with us, what they can do is they can run an on-premise solution in China, they can run an on-premise solution in Geneva and Europe somewhere, if they need to.

Erik: This is a very common challenge right now. So from both sides, on the operational side, but also it's a big opportunity for companies that have been selling devices in and are trying to look at how they can provide value added services on top of maybe hardware that they've been selling for decades. And this makes it much easier. You can evolve the software over time. You can add functionality over time.  Can you get into the business model of it? So I assume this is some kind of subscription model. But what does this look like from a business standpoint?

Ed: We have a couple different ways we sell our software solutions. Number one, all of our edge software, the software that actually runs on the gateway or what's called Pelion client, which basically is a library and a very flexible set of software that you can run on all kinds of different microcontrollers or different microcontrollers [inaudible 28:18] for Q and X or whatever, that's software and the Pelion Edge suite, which runs on Linux, all of that's open source, so customers don't pay for that.

But obviously, we make our revenue based on a software subscription model. Now, customers can choose to use our public cloud services, which have a well published pricing model, which is essentially based on the amount of devices that are connected to our public cloud. Customers can also choose to go with a private cloud option where we essentially run our infrastructure for them, but it's their own cloud services through dedicated resources, their own performance characteristics that they need. And we can run that on whatever cloud infrastructure they want to use. And then we also license our entire cloud itself. And that's the on-premise solution that we talked about. And that would be where we might license for instance, a Pelion cloud to run inside of a factory on the customers own bare metal or on their own Kubernetes or OpenStack architecture.

So our on-premise solution can run on OpenStack on Kubernetes. And we have quite a few tools that allow you to quickly spin up that on-premise solution. It can flex from one single, one our server to an entire rack or more, if that's what you need. So anyway, the business model is basically those two things. It's either licensing or it's a subscription model with the amount of devices. And then on the connectivity side, we basically have plans that allow you to add the amount of devices that you need, and the type of connectivity and data rates that you want for connectivity for devices.

Erik: And on the connectivity side, is there a roaming, is there kind of like there's a home country and then roaming, or is it just country by country where it applies?

Ed: My understanding is you would be able to do that based on the kind of contract you signed with us. But there's no real roaming per se, because it's a global [inaudible 30:13]. So what you're able to do is it uses a specific APN, and pretty much wherever you go, it's going to work. And our portal will allow you to make certain types of changes, and provide certain capabilities once devices are out in the field. And in fact, you can even migrate from one type of service to the next. So those are some of the capabilities that are there.

And what you're going to see from Pelion over the next year on that general line of thought is you're going to see us merge more and more of our connectivity management services with the device management services. So today, they're a little bit separate services. So I kind of go to one portal for the connectivity management versus another portal for device management. But where we're headed is a much more integrated offering. And that's going to add a lot of power because it means that I'll be able to say change this device to this type of service and also upgrade its firmware, and do that across a fleet of devices at the same time. And so those are some of the things you'll see from us soon.

Erik: Why don't we then get into the tech stack a little bit? And it's always, at least for me a little bit more challenging with a platform that it is with hardware, okay, we build this and here are the specs and so forth. And of course, you have, a big development team of very intelligent people working hard at this. But in kind of simple language as possible help us understand what are the underlying technologies, and what are the different variables where you might see a significant improvement in the coming year? So what are the big goals?

Ed: So I'm going to focus where my expertise lies, which is on the Edge class devices. So, first of all, let's just start kind of at the Edge, because like you said, sometimes it's easier just kind of start with the hardware. So Pelion Edge itself really comfortably needs about 512 Meg's of RAM, more comfortably a gig of RAM, on the Edge class device, meaning it's at least a 32 bit ARM CPU. And typically, our customers run on a 64 bit ARM CPU, or it's an x86 CPU.

One gig of RAM is usually nice just because it gives you enough headroom to deploy as many applications as you want. The way the tech stack works on the edge is basically it's a set of Linux processes, some of which do different things. If you kind of look at our offering, it's comprised of three core categories of capabilities at the Edge. One of them is sort of used by everybody and that's the systems management piece. And so our systems management components allow you to get a lot of the things you would expect with a traditional systems management system, such as remote logs, remote control of system D or other processes, configuration of network parameters, for instance, like if I want to set up one ethernet port to do this, one ethernet port to do that.

And then of course, we have our firmware update services, so that allows customers to do everything from just patch a single file to go all the way to upgrading an entire partition in one fell swoop. So it's a pluggable system so they can do any of that. And so that's the systems manager component. And then we have a device management piece at the Edge. And what that is essentially a set of software that allows you to easily publish device information. Most of our customers, they're coming to us with already having existing software and stacks that run on some gateway.

So let's say I have an existing stack that knows how to talk to some Modbus stuff that I manufacture, or that I work with that Modbus stack, if they want to get that Modbus data to the cloud, they simply need to make that process now publish to our local software bus that runs as a part of Pelion Edge. And so they just make a simple post to that bus, and then that bus will automatically move that data up to the cloud whenever the cloud’s connected, and it'll make that data available to other processes on the bus.

So for instance, the strategy here is I can keep my traditional legacy software without really modifying it much, and all I have to do is just get its data to the software bus. And then I can also build a modern application that listens to that software bus and does a whole new set of things. And so that's the purpose of the device management piece essentially. It's to interconnect processes with device management data and send that data to our device management server, which normalizes everything and lightweight them down.

And then our other big capabilities, of course is the edge application orchestration. And so our Edge application orchestration is based on Kubernetes, Kubernetes API's essentially work very similar as they would in a normal Kubernetes installation. And then we've added a number of really important capabilities to our services at the Edge for application orchestration. And probably one of the most powerful of those is a tunneling capability that allows you to form a web socket to our cloud and then that web socket lets you talk directly to a container.

For instance, if I have an existing container that holds a legacy application, in the past the way my technician might have interacted with that application is they may have talked directly to this gateway sitting right there on the land with that gateway. And instead, now they wouldn't be able to run that same application, but they just need to talk through a web socket to our cloud, and then it can let them talk directly to that application.

So it allows our customers to rapidly build remote management capabilities without having to modify their legacy stuff much. So that's a big win for customers that are trying to rapidly get stuff to the Edge. Take a breath there, that's our software stack is sort of in a nutshell at the Edge, I guess I'll just briefly talk about the cloud services that go with it.

So in terms of data management and device management, we have something called the device directory. So it's a very robust system that scales extremely well. And the device directory allows you to see all of your devices in one directory, and it allows you to see all the data associated with every one of those devices. So what we do on the gateway side of the house, and the Edge side of the houses, for instance, if I want to modify which logs I can see on a gateway, I simply use this device directory to look up the gateway, and I can just modify one or two data points them lightweight on them, and I'm able to reconfigure the way the log manager works on that one gateway.

Here's what's cool. If I want to do that now across a dozen or 100 gateways, the API calls are essentially the same. And by the way, if I also want to do something similar but it's now a microcontroller device, and I also need to update that information on the microcontroller device, by the way, those API's are very similar. So in the cloud, what we've done for customers is we've created a very normalized look at the world, even if you've got things that are very diverse out there in terms of your devices, everything from a tiny microcontroller device running our tiny stack all the way to baby a very rich gateway that has probably an attorney on it.

So that's the way configuration management is done. That's the way device data is received from different devices. And that's the way also that non-IP data that's being pushed through our gateway is published as well. So in the same device directory, you can look at your Modbus information that might be coming from those devices that might be connected to that gateway that talks Modbus. Right next to it you might also see the amount of RAM that's available on that gateway right now and the amount of RAM that's being used.

So anyway, that provides some color to the way that stack piece works. And then of course, the cloud services are there obviously to do application orchestration. Our log management, Erik, are stored in elastic search. So it scales very well, and you can use a lot of different tools to go through the logs like for [inaudible 38:36] so forth. Anyway, that provides some color.

Erik: And it makes sense that this is your focus, and I think this is touching a lot of the pain points related to the complexity of dealing with legacy infrastructure which is not going away for the next 20 years. What then is in the future? I understand that for the near future, you're going to continue to focus on integration. If you look over, let's say, 3-5 years, what would you see as the big development efforts?

Ed: Well, without getting too much into our non-public roadmap, what I can say is number one, we're already working with a number of different manufacturers with this program called Pelion Ready. And Pelion Ready for Edge means traditionally it took customers a little bit of time to get the software stack Pelion Edge it’s a variety of processes that run on Linux, got install it, got it set it up. There's a bit of a hassle.

What we're trying to get to for customers is we want them to, just be able to just like you can order a laptop that runs Windows, and the moment it arrives at your house, you can crack it open, and you can pretty much be up and playing with Microsoft Word in a second, it's never going to be quite like that for IoT, let's be honest. But where we're trying to go is that for customers, it's going to be a heck of a lot easier to get a certain kind of application running at a certain location.

So what our vision is around Pelion Ready, in terms of the hardware partners, is we want our customers to be able to say, you know what, I just spun up a new location. Let's say that I am a massive sandwich chain in the United States, and I have 10,000 plus stores, and I have a franchisee that just spun up 20 new stores in the last week, I should be able to drop ship from a manufacturer gateways to each one of those stores without ever touching on myself. It should be simple enough that my store operator can just plug in that box, and then those should light up on my network on my cloud service, on my dashboard and I should be able to rapidly deploy the applications I need running down in each one of those stores without my IT staff ever having to touch, get involved, deal with anything different than they normally would.

Now to a DevOps guy that is used to dealing with modern cloud infrastructure using Kubernetes, or a similar system and deploying containers, they get that. They're like, well, sure, that's the way our pipeline works. As soon as we wanted over there, we just decided to upgrade that one YAML file and bam, we have completely upgraded all those containers to the latest version. And we need to roll it back, we can do it the same way.

But in the hardware and gateways and an IoT, it's totally the opposite of that. So that's where we're going with Pelion Ready program is we want to make it where customers can get those gateways out the door and deploy them and put those edge applications physically somewhere with it modeling very similar paradigms as they have in in modern cloud DevOps.

And where we see that going over the next year or two is I think the natural progression of that is going to be like, okay, what other software can I put on those boxes through different partners? How can I easily get software put onto those boxes? So you could see how once I can quickly put a box somewhere, and have it connected to my account in Pelion and be able to manage that box really without ever having to do anything more than just use my mouse and keyboard, now you see how you also want to be able to choose from world class software providers where you can deploy certain kinds of applications directly to those boxes. And so that's what we're now looking at very heavily over in Pelion, is how do we enable those capabilities for our customers?

Erik: Today, I assume, it looks like with Pelion, but in many cases with a deployment system integration it's going to be 30% of the cost or some significant proportion. So getting that down will be immediately a very large savings.

Ed: And the other thing we find too it's not just the cost, which I think most the time they don't even know the costs because they're not really measuring it very well. But it's just so much time. And so then when they look at how much time it's going to take them to IoT enabled something or to edge application enables something, and then they look at their actual business case for what they're trying to do, and they're just like, oh, this doesn't even make sense. By the time we get this done, we will have missed the opportunity that we're trying to solve.

So this is all about speed. At the end of the day, with all of the stuff that we're doing with the Pelion Ready Program and the stuff that we're working on with Pelion Edge, it's about speeding up the ability for customers to get apps out there and solve problems quickly. So yeah, we got to make it easier on them because easier is faster.

Erik: Maybe we take a step back, and if you can just wrap up by walking us through given the tech stack as it is today, what does it deployment look like for a typical case?

Ed: So a typical deployment, the way it looks today is customers, first of all, need to get the Pelion software onto their gateways. And that's either happening with the help of one of the manufacturers, or it's happening at their IT shop. And so they will specked out and ordered enough gateways that they're going to be able to distribute those where they need them to be.

And the way they flash each one of them, there's a set of tooling that makes sure that each gateway is uniquely identified and has its own unique certificate. Let's just use the example of building automation. So if they're at each building or a couple at each building, then they immediately come up in the cloud for that customer's account. Because when they flashed each one of them, they were associated with that customer's account, the tooling they were using. And so they're going to see those light up as soon as they're plugged in and powered on and talking to our cloud services. And then they essentially can use all of our management features.

So they can immediately start deploying applications form, if they go run cube CTL get nodes, for instance, as an example, for Kubernetes folks, they're going to see a list of nodes, those nodes are their gateways, and they're going to be able to deploy an application to each node just like they would if it was a node in the cloud. And then in terms of systems management, there's a variety of tools and examples that they can follow quickly to be able to upgrade files to be able to upgrade sideload packages, for instance. Pelion Edge runs on Ubuntu, it runs on Red Hat, it runs on Ubuntu core, it runs on Yocto. We have customers that are using it on all kinds of flavors of Linux.

And by the way, I wanted to give another example I think that's pretty good around this typical use case style. We have another customer who's essentially in the automotive industry. And this customer, for instance, is using SOC that both has a Linux side and it also has a microcontroller side. And so the same firmware update API's can be used to upgrade anything that's attached to the Linux Os. And so in their case, they're using those firmware update API's to also upgrade the more hard real time side of that SOC which has to do with the actual vehicle specific capabilities.

And so what they're able to get out of that is, even while Linux is doing that other microcontroller side of the house is running and doing what it needs to, yet they can use Linux to manage an upgrade that critical firmware that's more on the hard real time side. So I don't want people to think about the firmware update API's is just things to manage packages in Linux. They're actually much more flexible, and customers are using them for much more richer more mission critical tasks as well. You could use those same firmware update API's as an example to upgrade the firmware on a PLC that's down line from the gateway. And we have customers doing that. And the way they would be talking about these gateways is they have a cloud in our public Pelion instance, or they may be using an on-premise solution. But that's the way it kind of typically looks

Erik: And it sounds like this is a good step forward for the market in terms of simplicity.

Ed: As straightforward as IoT can be.

Erik: Ed, I think we covered a good bit of range here today. Anything that we missed or anything else that you wanted to bring?

Ed: No, I think we did a good job of covering a lot of the bases. And I appreciate your time, Erik.

Erik: Thanks for tuning in to another edition of the IoT spotlight podcast. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy, or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.