EatSleepCode-BlogBannersWPF-and-WinForms_870x220

Learn everything you need to know about Microsoft's Azure IoT Edge in the latest Eat Sleep Code podcast.

On this episode of Eat Sleep Code, Carl Schweitzer (Software Engineer, Microsoft) discusses Azure IoT Edge. Carl shares information about what Azure IoT Edge is, and we learn what devices, operating systems, and environments are compatible with it. We also touch on where Machine Learning fits into it all.

You can listen to the entire show or catch past episodes on SoundCloud. Or just click below.

Carl is a Software Engineer at Microsoft specializing in developing IoT solutions. Prior to Microsoft, Carl was a 4-time MVP and has been developing IoT projects for a decade.

Show Notes

Show Transcripts

If you prefer reading to listening, we've got a complete transcript for you as well. Dig in below:

00:00 Ed Charbeneau: This podcast is part of the Telerik Developer Network. Telerik, by Progress.

 

[music]

 

00:17 Ed Charbeneau: Hello, and welcome to Eat Sleep Code, the official Telerik podcast. I'm your host, Ed Charbeneau, and with me today is Carl Schweitzer. How are you doing, Carl?

 

00:28 Carl Schweitzer: Pretty good. Yourself?

 

00:30 EC: I'm not doing bad. We're just getting back into podcasting mode, and glad to have you on board. We're gonna talk about some IOT today. It's something that's near and dear to your heart.

 

00:42 CS: Yes, it is. I'm looking forward to talking about it.

 

00:45 EC: And currently, you're working with Microsoft, and you also have a podcast called MS DEV Show. Why don't you give us a run down of what you do at work, and tell us a little bit about your podcast.

 

00:57 CS: Sure. I'm a software engineer at Microsoft. And what I do is I work with global ISVs and help accelerate the development of their features and products. It's really cool working with companies that have a lot of impact, and in particular, my team focus is in manufacturing spaces. So as you can imagine, there's a tad bit of IoT going on there. And like you also mentioned, I am one of the two hosts for the MS DEV Show. It's a weekly podcast where we focus on Microsoft developers, so anything that a developer who uses any kind of Microsoft product in any way, shape, or form. You don't have to be an Azure Cloud developer, or somebody who might... You think is traditionally just stuck all in Microsoft technology. If you're just using VS Code or you're an IOS developer that's using Azure Backend, I consider you to be a Microsoft developer too, so come check it out; msdevshow.com.

 

02:03 EC: I listen to the show actually pretty frequently. And you guys have some amazing guests on there. It's a great show, I suggest people check it out. Now, Carl, I've talked about IoT with folks here and there, and it seems like that space is always moving. So why don't we get a little run down of what exactly IoT is, again, because it changes so frequently, this type of technology updated. Is there new stuff coming into the space, what should we be looking out for when we talk about IoT?

 

02:36 CS: Let's just level set a little bit, and I'm gonna keep this focused towards the Microsoft thinking, since that's what I've been doing day in, day out. But IoT is kind of like any time where you have any kind of device that's not what you would call a computer, that has internet access communicating with some sort of cloud, I would say that you're in the Internet of Things territory, at least in that ball park.

 

03:02 CS: So you could... Some obvious things are like smart thermostats that we have nowadays. You might be doing things that are enabling automation in your homes. Those are some of the consumer-focus things, but if you look at manufacturing facilities, a lot of people can imagine that there's these production lines that are doing things, and made of multiple different machines. Well, these have always traditionally been hooked up to like a local network, and maybe there's some sort of control system coordinating it locally. But over the last several years, companies have been trying to get this operationalized up in the cloud. And as we've been doing this, those things that we were doing locally have become Internet of Things, and really those same paradigms that they were used to working with are very similar to how the cloud portion of it was.

 

04:02 CS: Looking forward, the things that's really changed in the last year is everybody started talking about Edge, and what is IoT Edge? And really what that is, is as we've looked at the workloads that we do with the cloud, there's some things that obviously work really well. We wanna get our data off of our device, we wanna get that in the cloud, that works well. We wanna see things that work across, maybe some trends that are working across multiple devices. That's another really cool thing that we can do with the cloud.

 

04:35 CS: As well as we wanna start doing analytics on that. We got a lot more processing power, we've got a lot more storage. Your system can expand in any of those over the course of time. But what you don't get is sometimes you need to have a really tight time restriction on when an event happens and you need to respond to it. So if you're trying to control machinery, or respond to an event that happens, you might not have time that the internet latency has to get your data up to the cloud, processed and responded to. So what has happened is, this isn't just Microsoft; all sorts of companies have been trying to figure out, "Well, how do we come across and solve those scenarios?"

 

05:22 CS: Well, by actually moving those workloads back from the cloud to the device again, is been the way that we're solving that. And so, Microsoft has a technology called IoT Edge that helps solve that. We can get logic, cloud logic as well as custom logic, running on the devices. And then there's also a few other things. We might need to do Protocol translation. In the manufacturing industry, there's a lot of different standards on how to communicate with each other, and when we talk about communicating with the cloud, those standards are different, so we call that protocol translation. Just like you'd have a translator to change what you're saying in English to somebody speaking Spanish. If you don't have that, that's what you can do in addition with Edge technology. And you can help kinda keep your data private. There's a few other capabilities you get with the Edge, but at the high level concept, we need to solve some of these problems that the cloud can't solve just because it's far away from the actual devices.

 

06:33 EC: Yeah. This data protocol stuff sounds very interesting to me, 'cause I come from a manufacturing background, and I can imagine every device manufacturer that's out there, they have these machines with some kind of Internet connectivity on it, and all the different companies... In manufacturing, they don't tend to work well together on standards. Each one of them has their own way to collect data, communicate the data, storage formats, all that fun stuff. So that sounds like a pretty critical piece of that today.

 

07:03 CS: Yeah, and even with protocols, like you said, there's OPC and Modbus and all of that. There's hundreds of variants of each of those. Just because each company wants to do their own unique thing on top of them. But when you communicate, for say with a over an IoT hub, now you're really limited, you speak MQTT, AMQP and over web sockets. We need something to translate from those industrial protocols into a web protocol.

 

07:35 EC: So what type of tooling does the IoT Edge provide to help with that situation? What does that look like as a developer?

 

07:40 CS: So there's a bunch of modules out there for IoT Edge that handle all of those for you. So if you're trying to, say, Interop with OPCUA or a device that speaks another protocol, there's quite a few modules out there out on GitHub, where you can kinda download that code and wrap that up and deploy it as a module. We'll get into what that is I think in a little bit, it's a little quick to get into what a module is. But at the end of the day, what we're looking at is how do we do a lot of this on the device instead of up in the cloud? I think that's the number one thing that we're looking at when we're architecting for IoT Edge.

 

08:33 EC: Does that mean we're using more non-computer type IoT devices and doing... What type of work are we doing outside of the cloud that you're talking about? What exactly would that be?

 

08:56 CS: There's custom logic that you might need to do to do a bunch of different things. So I look at it like we might be having these sensors or an array of sensors that would be very costly to send lots of messaging up. What we can do is we can aggregate those values. Now obviously, Microsoft and... We don't know your sensors, your whatever. We provide a way for you to write your own code to do that aggregation and maybe only send the result of the data up. Some of the other things that we're doing with Edge is we're allowing you to take your Azure services that have been pre-configured for Azure stream analytics, Azure functions and machine learning, and containerize those, and have those run on the Edge.

 

09:49 CS: Now, the one little caveat here is, Edge runs across a variety of device types. We classify IoT Edge or IoT devices kind of like on a range of low capability to high capability. So if we look at it, a lot of people are familiar with what a Raspberry Pi is. That's part of a tier called... What we call an interactive tier, and that's like the middle of those five kinds of devices. Above that, you can get all the way up to like a gateway tier. So if you're gonna be aggregating data from a lot of different sensor, instead of the sensors talking directly to the cloud, they'll talk to a gateway, and then the gateway will handle that communication with the cloud.

 

10:39 CS: And generally those gateways can be more powerful than your average PC. So you might have a lot of storage, a lot of processing power, but once again, we're looking to solve problems, like what happens when there is no internet connection to the cloud? We might have to start storing these messages and when we get that internet capability back we forward them on. That's a very common scenario that we see, as well as, like I mentioned before, taking those modules from the cloud and when they do get updated, they can be automatically redeployed with the changes to them. So if you update the logic in your Azure function, when those changes get made, those can get redeployed on-the-fly.

 

11:35 EC: So we kind of have a concept of, we can have logic running in the cloud and we can also containerize some of that stuff and push it down directly on the device, and run it locally there in case connectivity gets knocked offline or something for the moment.

 

11:50 CS: Yeah. So I kinda wanna get to what is the IoT Edge? And because a lot of people look at Microsoft and a lot of things that it's done in the past as like, we may have made an operating system in the past that has all these functionalities, but what we know is, when we go into the IoT space, there's a lot of different kinds of hardware and there's a lot of different kinds of scenarios that people wanna run in, and we don't wanna get in the way of any of that. So instead of creating an operating system, we've created a runtime that sits on top of an operating system. So you can bring... It could be a generic Raspberry Pi device or it could be your own custom version of Yocto Linux or something like that, and Azure IoT runtime sits on top of that, and it does a few different things.

 

12:46 CS: So we mentioned before modules and containerization. If you're familiar with running Docker at all, your modules are just Docker containers that the runtime knows how to access. You'll keep these in some sort of container registry, it could be Docker Hub, it could be Azure Container Registry, it could be your own third party hosted one. They could be public, private. It will lock these down behind any kind of authentication scheme that you need to and the runtime, when it's configured properly, will see what containers that you have, and which ones it should deploy, and it'll pull those down and deploy them locally.

 

13:33 CS: The other thing that it does is it provides a communication channel between those modules. So what you'll wanna do is, you might have a module that is reading your sensor values. So it might be looking at all the different sensors that are coming in. You might have another module that sits downstream that you'll communicate to, that'll do some prep work to do some machine learning, so you might wanna massage the data a little bit, and then hand it to a machine learning module which will then determine if your production facility is in a good state or a bad state. And if it's in a good state, you might just say, "Hey, everything's fine." You don't have to pass all of that data. 'Cause a lot of times when we feed data into machine learning, that's a lot of data to have.

 

14:26 CS: And it might be expensive. You could be in an area that has... It's in a remote place. You could be working one in of those oil fields or something. If you're communicating over a satellite or cell phone, that's gonna be expensive to get that data up. But instead, we can just report the result of that. If something's bad, we can take action on it right away. The machine learning algorithm can pass that off to another module which will take action locally to maybe shut down the equipment or to send off a notification to somebody.

 

15:00 EC: Yeah. I've done a lot of studying on machine learning. And one thing that's really interesting about this scenario is it takes a lot of horsepower to create the machine learning models, but once those models are created, you don't need that kind of horsepower anymore. So some of the less heavy pieces of hardware, like these IoT devices, like you said, some of them can be more powerful than your computer, but often you have these simpler machines that don't have as much memory and storage or processing power and they can still run these machine learning algorithms efficiently. It's the training that takes a lot of guts to get up and running.

 

15:47 CS: A lot of times what I'm seeing is... You're exactly right. When you have your machine learning trained and running on one of these devices, it's how much memory does it take up, because these can be quite extensive in their memory footprint. And if you're on a Raspberry Pi, that means that you're sitting... Your module needs to fit within three gates, and that's actually a pretty good size. But for machine learning that could be pretty small. So you've gotta be aware of what the limitations of your hardware are when you are working with some of these bigger workloads.

 

16:23 EC: So how do we get started with some of these technologies? For example, if I was interested in creating a module, what does that look like to a developer?

 

16:33 CS: What's really cool is now, IoT Edge, as we're recording this, came out last week. You can create... It doesn't have to be.Net. I'm a.Net person, but you can go into VS Code, create a new project, you can do.Net or C#, C++, Java, Python, and Node. So you have a lot of technology options. But if it's from a C# world, a.NET world, it looks a lot like a console application. You just import the device client for the IoT Hub SDK. And when you're working with devices, which is very similar to how the IoT hub works, but in addition, when you wanna create a module, there's a new class called the module client. And the module client is, once again, really similar to what all the capabilities of the device client are. So for people who have worked with IoT Hub using C# or one of the other SDKs, you could do things like you could send a message, you could have or work with a digital twin, which is a way for you to have state of your application both on your device and in the cloud.

 

17:54 CS: There's a module equivalent of that as well, so you can have Module Twin that has your state of your module being synchronized up with the cloud too, so you can interact with those. Your module can send its own messages, your module can route messages to other modules. And these are the kinds of things that you can do, as well as put your own custom code in there.

 

18:19 CS: Now, I think the one other thing that I wanna add on top of everything else, is now that we're sitting in a world where we're doing images and Docker and stuff like that, we don't have to use the SDK's built-in message routing system, which if you look at looks a lot like interacting with an IoT hub message base. But if you have already some existing code that might be like a REST API, you can, using the same Docker capabilities for networking, you can open up ports and communicate directly between two modules via REST as well. So if you already have some existing code that does that, you don't have to modify your code just to work with this. So this is one of the cool things, like if you already have a web API that's built out to perform this other service, you don't have to totally re-write your code to this other communication paradigm just to get working. And what that means is it's a lot quicker for you to get your existing code base running on the Edge if it's doing something that makes sense for an Edge module to do.

 

19:31 EC: Nice. So that kind of shortens the learning curve a little bit for folks, so they don't have to learn these other message protocols and stuff. You're using familiar technologies that you would if you're on the web.

 

19:48 CS: Not just with messaging, but like we had talked about, with it being Docker-based itself, that's another thing that people assume is a web technology, which I think was really cool, 'cause in the past I'd wanted to learn more about Docker, but at the end of the day, I'm not a web guy. I didn't have a reason to learn that. When this came around, I was able to all of a sudden have tons of documentation on how to use Docker because people had been using it in the web for years. So this is one of those things that we sat down and looked, what's the best of all the available open source technologies, and how can we leverage them to make this product that's gonna make people's lives easy?

 

20:31 EC: Yeah, people are really using a lot of open source things within their stacks these days. So it's nice to see that Microsoft's embracing Docker in this situation, and allowing that to work on an IoT level. That's a real game changer in the terms of the IoT space. That's something that is fairly recent, at least I haven't heard of that being done outside of last couple of years.

 

21:05 CS: IoT Edge itself is open source on GitHub now. So this is technically V2 of the Edge, and when we went GA, the code was put out there on GitHub as well. So if you look on the Azure GitHub account and search for IoT Edge, you'll find that there as well.

 

21:22 EC: So that kind of leans towards a cross-platform ability in that type of thing as well. So how does that affect cross-platform and security and stuff like that?

 

21:36 CS: I mentioned earlier that you can use this on Raspbian Linux with a Raspberry Pi, or if you have your own custom thing that works with Yocto Linux. I don't know the edges of the compatibility with all the different Linuxes, but with all the major ones that IoT vendors are currently using, it works with all those major ones, and it also runs on top of Windows 10 IoT Core as well. So if you do wanna run Windows containers on a Windows-based operating system, that will also work. So we could move a little bit more "Microsofty" on this and use those other technologies, or we could stay in Linux. And what's nice is if you use.NET Core, you could be using the same code that you wrote for a Windows instance and now using it in a Linux Docker image because of the cross-platform capabilities of.NET Core.

 

22:38 EC: Nice. I'm a big fan of.NET Core. Getting to the point where you can write business logic and put it in a DLL, and be able to ship it across IoT and Linux and the web and maybe use it on Xamarin, it's some pretty powerful stuff to have your code that portable.

 

22:58 CS: Yeah. But I only half answered your questions. You also asked about security. And this is one that I've been really familiar with for years, 'cause any time you talk about IoT with somebody who's not really familiar with it themselves, the first thing they ask is how is this secure. So when we look at IoT Edge, there's security of the device and security of the cloud services. For the device, there's a lot of things going on. If you're working with hardware that supports a TPN and secure modules, the Edge knows how to work with that and use that hardware attestation to secure itself further. Data is... Whenever you're using the APIs to store data, at REST, it's always encrypted. And when we pass it on to the cloud services, the cloud services have always been encrypted by default as well. And if you are more interested in the security side to this, 'cause we're gonna stay pretty high level for this talk, you can go to aka.ms/edgesecurity, to learn about how the security of this has been baked in at every different level across the way.

 

24:22 EC: And we talked about cross-platform, but we haven't really talked about other types of hardware. So we talked a little bit about Raspberry Pi. What other types of hardware do you think you might see in the IoT Edge environment? And is there anything custom from Microsoft that you're working with?

 

24:43 CS: Alright. This, like we mentioned, runs across a bunch of... A spectrum. And it's always fun as a developer, I think, to push the edges on like how constrained can we run on? And there is a tier, if we get too far below the Raspberry Pi, you start limiting what you can do. You're not gonna run full machine learning workloads on those more constrained devices, but you can still work with these different modules to provide maybe that protocol translation, your own custom logic for batching, or doing stuff like that.

 

25:31 CS: And Microsoft has recently released or announced its release, or future hardware coming out called Azure Sphere. And this is a hardware chip, a micro-controller unit that has been designed from the ground up with security in mind and IoT workloads in mind. It also comes with its own Linux operating system that's had all of those same philosophies. So if you want to get as constricted as you really need to be, Azure Sphere is a micro-controller unit that you can use to talk with Azure cloud services as well. And I'm not really sure about the specs, but it gets pretty constricted on there. So if you're interested in that, Azure Sphere is another interesting piece to the IOT puzzle that there is. But...

 

26:32 EC: I think we may have discussed this briefly at Build, when we were at Build together. But one of the Azure IoT Edge devices that is... I don't think it's released but it was announced at Build, was the Azure Kinect sensor. I thought that was really cool.

 

26:53 CS: Yeah. And what that's doing is it's replacing some of the hardware of the original like Xbox style Kinect with Azure services. So you can give it your images or video and have it feed back to you the analytics that the Kinect would have given you. So that's also another really interesting kind of... It sits on the edge of what IoT is. When we start blending local hardware with limited capacity with infinite cloud computing and maybe a little bit of Internet leg to it, if we can figure out what constraints we need to optimize for, it's really interesting some of the things that we can do. Because back in the day, you could only do that kind of processing immediately with a lot of expensive hardware, and now we can really use a lot more commodity hardware, and back-fill that with Azure services.

 

27:56 EC: And it's still very early on in this IoT Edge space. Like you said, this is what, Version 2 that you're working with right now?

 

28:05 CS: It's Version 2, but this is the first time we've really been able to blend custom code, Azure services, and the flexibility to kind of switch between them and manage them in a secure way. Previously in Version 1 it was very limited on what you could do. And it was really more for like a gateway style of operating. So you would really have your IoT devices talk to a Gateway, and then the Gateway talk to your cloud. Now we can really mix and mash that up. Your devices could hook up directly to the cloud, but they could also talk to a gateway. And it really is what makes more sense for your needs and your architectures.

 

28:54 EC: Yeah. It looks very developer friendly too. It looks like we're able to use our tools of choice, whether it's Visual Studio Code or Visual Studio, and then when we're going to deploy these things we can do it with the Azure portal. And the Azure portal is a very visual tool to get in there and look at analytics and stuff like.

 

29:18 CS: And in addition, you can also use your traditional CICD processes like VSTS to automate that. So when you check in changes to a module, those could be built using your CICD pipelines, deployed to the various container registry where they need to be, have your IoT hub be made aware of these changes, and now your Edge devices are pulling down the new module binaries as they need to.

 

29:50 EC: That's very cool stuff. It looks like it's all very command line-friendly. So developers aren't locked into some type of tooling. They don't have to necessarily go to the Azure portal if they don't want to. And like you said, you can use your CICD tools. It's very interesting stuff.

 

30:09 CS: Yeah, it's very exciting. And this is still a very new technology, and as we go forward, there's a lot of plans to make the developer story and developer tooling a lot more friendly so we can be as productive as possible.

 

30:28 EC: And like we said, it's early on, so I can't wait to see what cool things people start making with this. I would imagine a lot of this is being done in the big industry sector right now. So there's probably developers out there listening that might be dealing with some of this, but I don't think we've quite seen the impact as consumers as to what this stuff is capable of. I'm sure there'll be some really nice case studies coming up here in the next year. Like at Build or something...

 

31:00 CS: Yeah, there's definitely a lot going on. And one of the things, I think, as a consumer that's really neat about this is, as a consumer you don't always see all the cool things that are going on behind the scenes. I have a few different smart thermostats in my home, and me being as super techy and connected as I am, I know some of the internals of them. But at the end of the day, I kinda just don't care. They're there and they work and they're making my life a lot better than before I had them. So as these are coming out and they move from the industrial areas and to the consumer ones, it's just some of the stuff that we get for free, and technology just seems to be on that ever expanding march. So this is one of those things that I think is giving us more opportunity for more advancement a little bit more quickly than we would have had without it.

 

31:54 EC: Absolutely. Carl, I think we're about running low on time. So I wanna thank you again for making time to be on the show. Again, make sure you check out Carl's podcast. Carl, you wanna kinda give a brief overview of your show and give a shout out to the URL again.

 

32:14 CS: It's MS Dev Show, and you can find that at msdevshow.com. That's where myself and my co-host, Jason Young, talk about a variety of Microsoft topics. We've recently talked about stuff like what's going on in the future of.NET, to Microsoft Teams and how you can interact with that, as well as other services like VSTS and Azure and mobile and Xamarin and stuff like that. So we really just try to cover it all.

 

32:46 EC: Again. It's a great show. I listen myself. So I recommend everybody check that out. And Carl, where can we find you online?

 

32:54 CS: You can find me on Twitter @carlschweitzer.

 

32:56 EC: Alright Carl, thanks again for being part of the show. Hopefully everybody can check out IoT Edge if that's something that they're interested in. And we'll see you again soon.

 

[music]


Ed Charbeneau is a Developer Advocate for Telerik
About the Author

Ed Charbeneau

Ed Charbeneau is a web enthusiast, speaker, writer, design admirer, and Developer Advocate for Telerik. He has designed and developed web based applications for business, manufacturing, systems integration as well as customer facing websites. Ed enjoys geeking out to cool new tech, brainstorming about future technology, and admiring great design. Ed's latest projects can be found on GitHub.

Related Posts

Comments

Comments are disabled in preview mode.