 Good afternoon everyone. Thank you so much for coming. So today I'm going to talk about EdgeX and it's the action at the edge. So we're going to cover Industry 4.0 and Edge. Maybe nobody in this room needs to know about it. Everyone here knows about Edge and IoT and Industry 4.0. But I do like those two slides, so we share them. Then we talk about EdgeX and what does EdgeX 1.0 have in it and what's coming beyond. So briefly, we are at the lucky point in life where there's Industry 4.0. This digital world has spanned everywhere, anywhere, and it's getting faster and faster, and it's going to enrich our lives so phenomenally. Back when I started in computer science and was doing my PhD, AI was something I was very, very interested in, but the time hadn't come. Computing wasn't ubiquitous, it wasn't cheap, there wasn't a cloud out there. My little TI explorer used to struggle and it would get hot and things like that. So things have come a long way and it's come even further from the 15 years back when I used to work on IoT and Edge and embedded systems when it was not sexy. So today is a very special day and that's why I like that Industry 4.0 slide. Earlier this morning, during the keynotes, we heard our pre-talk about all the different possible applications and they're trying to come up with a glossary of what an edge is and the size of the edges and I'm going to say I don't care. An edge is an edge, it can be a little edge, you know, just a little water molecule kind of thing, it can be a whole drop of water, it can be a bigger drop like a rain drop or can be a mighty cloud. So for me, the edge is something distant from your data center but something very close to the source of data. You're going to process your data right where it's created so you don't have response latencies that are large, you don't need a lot of network bandwidth to transmit it somewhere but you have your smarts where you need it and we're actually in an agent space where there's going to be a data deluge and you don't want to really be transmitting every boring thing you're doing up or seeing or hearing into a cloud for processing and storage and we heard another talk this morning at the keynote about how data centers are competing with the airline industry for their carbon footprint. You know, I'm bigger, I'm wider, I'm going to heat up the planet faster type of thing. So some of this is also going to relieve that by not having to transmit so much data by processing it sooner, by not having to store everything and making some kind of storage arrays that are taller than Mount Everest. So the edge will depend on the application, the compute that it has, the hardware acceleration it has, etc, etc for the problem. So that's why the edge is important because we want to do stuff close to where the data is and all the other good stuff it brings like reducing response latency, network bandwidth, and also preserving privacy. So this brings us to what is edgex and I wanted to start out by saying what it is and what it is not and on day one of our keynotes we were talking about mascots and whether they're cute or cuddly and edgex has a cute mascot. It's this octopus, beautiful purple, can't touch it so we can't know if it's slimy so let's assume it's a nice, soft, cuddly, happy octopus but it also says something about the octopus's arms. They have intelligence at their edge. It's not like there's only a central brain that does a lot of thing and that's the sort of stuff we wanted to carry over when we were talking about IoT and edge, that there is intelligence at those pods and those little sucker points all across your network where those edge resources lie, where those sensors lie etc. So let's see what edgex is. It's open source, it's part of the Linux foundation, it's part of the LF edge umbrella. It's been there for over a year now and it's picked up momentum, picked up more people, more developers. It provides data ingestion. It can do some amount of store and forward, it can forward everything, it can store a lot, it can process it, it can chew it up and throw it out or it can export it to any different cloud endpoint of yours. It provides multi-protocol connectivity and we'll come to that in a little bit like the different protocols. It's extensible, it's customizable so you can add different profiles for different kinds of sensors and it's chiefly written in Go. Originally it was in Java so it was a little bit of a chubby footprint. Most of it's moved to Go. They're pros and cons of having used Go. We don't quite get the plugin architecture that we were used to with Java, the plugin play kind of thing, the JVM does its class loader thing and loads the classes when you need it. Lost some of that with the Go but the footprint is much, much smaller. There's one component still in Java which is our rules engine. It hasn't yet reached the priority level like, hey, we need to replace this with something else so it's Java based, it's rules right now. There are a few services that are in C. It's cloud native, it's all microservice based so we can drop in new microservices, we can package maybe a machine learning model and drop it in there in a pipeline, et cetera so it's very, very modular in that sense, cloud native in that sense. It's event driven because as some sensor data arrives it triggers certain actions. This is temperature about 100, do something, the pressure is about something, turn on a valve, close, open something, et cetera. But what is it not? Now, it's not an orchestrator so it would fit in with another orchestrator, something like K3S, that's the talk I just attended, something like that I could work with or could just be one central cloud level manager saying launch the software on a certain node or a collection of nodes. It isn't a management plane so there will be some other central brain that will say do something, load something, et cetera. It has no opinion about the hardware it runs on. It will run on a Raspberry Pi 64 bit right now. It will run on X86 from any vendor type of stuff. It's not operating system opinionated either. Currently we're using Ubuntu but anything could go. It's not a problem. We just have to work on it and test that it works. So this is the picture of EdgeX. It will spend a few extra minutes on and it kind of captures what EdgeX really is. As I mentioned, it's an infrastructure. You know, one time we said when we're getting into this IoT space, let's develop a little IoT app and see what it takes. You have to have some kind of southbound protocol support whether it's serial bus, USB, RESTful API, whatever, some sensor data is to enter. You process it, you might save it and then you might export it somewhere. But always you can't assume you're going to have network connectivity and we were thinking about this from the automotive space. Let's not even worry about self-driving cars. What are the different kind of automotive applications we could have had there? We might want to have an insurance application. Was I driving too fast? Was I, you know, hitting the brakes too hard? I mean, those will result in different kind of wear and tear patterns on the car. You know, if you keep hitting those brakes often, those brake pads will erode away. If you're going to accelerate and speed a lot and do something else, your insurance rates go up. But if you're idling somewhere, not only are you just wasting fuel, but it's also indicative for a smart city that maybe you have to adjust those traffic lights. Maybe you have to build another lane. Maybe you have to kind of give some incentive to people to do some kind of shift in their work hours, whatever. So there's a lot of data you can pull out of a car and the way people are driving it without even worrying about autonomous driving. But that problem triggered a lot of other thought processes. What's speeding? Am I on that service road next to the highway? Am I on the highway? You know, that makes a difference. Do I get that GPS coordinates and map that to the speed limits in real time? It's not necessary for this sort of thing. It can be just collected, stored and processed later. Likewise, do I want to have a separate network connection in the car for this sort of data? It's not real time. You know, then I have to change some behavior based on that. It's perfectly fine to store it, process it and pump it up to maybe that insurance endpoint or my driving concur kind of application that wants to track how many miles I've driven or to a smart city app offline when the car's sitting in the garage. So there was like many thoughts like that that prompted us to say, hey, you know, do I need a data persistence layer? Do I need a data persistence layer that is as simple as a file system? And if so, how much space do I have on the system? Do I consolidate and make some higher level aggregate kind of information? Like if I'm driving at 60 miles an hour and let's say that's 15 miles over the speed limit, I don't really need to track that it was, you know, what it was at every second. I can consolidate and set, you know, Malini's speeding from two to three and she was driving at 60 miles an hour so you can collapse that information and kind of control this data dilutes kind of situation. So all those sort of processes that went through our head when we were thinking about an IoT application, we want to be able to support in a framework. So multiple ways of saving, multiple, you know, ways to look at the data and trigger certain actions. So that's where Rules Engine is useful. Then some notification alerts. Not always are we going to be like going to a cloud, but you still might want to notify this driver saying, hey, you're really speeding out here, beep, beep, beep, or do something else or in a factory scenario, some pressure or temperature has gone too high. So there's a notification component in there. Then everything you do, you want to be able to log for audit purposes, for tracing, debugging, et cetera, et cetera. So EdgeX is a framework to help you build those IoT applications and what will that end deployment on an Edge node look like? There will be the framework and then there will be the application software. The application software would also just be microservices over here. So with that, we're getting to the point about where's this code? How many of you have used EdgeX? One? One hand? Okay, I hope a few more join and get on board later, okay? So thank you for using EdgeX. So the codes available on GitHub, we have a good wiki and this was also mentioned in a keynote this morning about, you know, summer of docs. Getting on board EdgeX initially, there's a lot of recordings but it takes a lot of time to go through a recording. One hour meeting, not all of it is useful. Even my 35 minute talk, not all of it is going to be useful. There are a few nuggets that are useful. So it was important that we started building more documentation, writing the salient important things instead of expecting people to listen to a one hour talk for each little subcomponent. So wiki has improved significantly. The documentation has improved significantly. We have a Slack channel with a lot of friendly people ready to answer your questions and it's a total open source project with most decisions, maybe all decisions and all arguments in pros and cons, all of them coming up in our work group meetings. So we have weekly meetings for each of the subcomponents like the system management agent, the core services, the device services. So they all have their own work group meetings and then there's a weekly technical steering committee meeting and, you know, that's some of our developers who've made contributions. Ah, a lone person's picture's not here and there's Jim White too but that's where our code lies and some of it has been archived and I'm just showing you the go ones. So let's look what this EdgeX 1.0 is and how long it took to get here. Well, it started back in 2017 and another thing mentioned in a keynote today and at other talks in the same room is there's a big difference between a proof of concept and a product and all of that is here in EdgeX. There was an initial proof of concept way back in 2017 called Barcelona then came California and there's no real pattern in this other than they start letters of the alphabet. Next came Delhi and this 1.0 version is called Edinburgh. It stems from the fact that we met in Edinburgh about a year back when we were nailing down the features of this release and I just briefly mentioned here a few things, the blue box, but we'll get into more details. So EdgeX foundry 1.0 with our beautiful purple octopus and now we're getting the details. It's got enhancements in a component called the system management agent. This component will let you through, it's all API, REST API calls, you can say, hey, how much CPU am I using? Is there enough resources here to meet all my workload requirements? Am I at like 90%, 100% pegged? Is something else going on? And that's also useful for anomaly detection. If something weird is happening, some workload is doing something odd, consuming excess resources, denial of service. So we're collecting metrics and we can pump it out to some management plane, whatever your favorite management plane. It could be Amazon's, you know, AWS IoT or Azure or even VMware's Pulse IoT Center. It also allows you to check the status of all the different services. Like we mentioned, there's a registry service that I didn't quite mention. There's a notification service, a logging service. So each of these services is up and about and ready to do their business. Do I need to restart them? So the system management agent allows you to do that kind of, you know, visibility into the system. We introduced a correlation identifier, which helps you to trace end-to-end what's happening as the sensor data arrive. Let's say it's some camera input or a light bulb input. How did it go through the whole stack? It came in, it landed in the core data, it got saved into maybe the database. It triggered some rules in action. So that was an important thing. And most... At least when I worked in OpenStack 2, that wasn't something that they thought of first and I wonder why. But that's a very, very important thing. We've increased the number of unit tests and that can be a plus and a negative. There's some people get so excited about unit tests, they write it for the most trivial things. But a lot more unit tests have been introduced. There are now more black box tests and one other important thing is we've got black box testing now for the devices, for the core data, but we want to increase it to the other components and that's all going to be part of the next release. We have a new performance test framework in place and we have Linux Foundation resources to test these things, which is nice. We have made some improvements to the microservices. Now, what do I mean by improvement to microservices? These are going to be running sometimes on very constrained devices. Sometimes they might be on beefy devices. It's fine then. You can do anything and waste resources. No, we still want to be using things optimally. And one of the initial ways this was coded was a lot of data was being transferred between microservices. And we had a similar comment earlier today in the AI talk. Do you want to keep all the little components in your pipeline in a single container or in our cross containers in efficiencies, pros, cons, modular, non-modular? But when you're going to cross microservices you've lost that power, that joy, that shared memory gave you that you could have just used a reference and gotten everything you wanted. Things now have to either be an ID that you go to a database and retrieve or you have to send it all down that pipe in your JSON or whatever or your GRPC and it has to be dehydrated and rehydrated to make an object. So there have been some inefficiencies there in the initial design which we're improving and working on, but we cannot mess with the API and all because we're now at 1.0. We have to be respectful of that. So we're trying to do things keeping that API fixed. We also upgraded to go 1.11 and now we're using go modules. What else did we do in the HX1.0 release? We have beefed up the device SDK. Why is this device SDK important? Software development kit? It's important because we are not anticipating or thinking of every different device that somebody will imagine up and want to use in the IoT space. It could be a heart monitor. It could be a diabetes sugar monitor. It could be your heart rate just about anything and your happy little light bulb. Is it on, off? Is your winter buying doing something? What else is it transmitting? Those are some very complex systems. So the SDK lets you create those device profiles and once you've created them you just launch it as a device service and every field it transmits it's part of that profile and then the type of that value is it a string, is it a boolean, is it a 64-bit integer, whatever all that sort of stuff you get to specify in your device SDK. And eventually the commands, what can I do? Is it to turn on or off that light bulb? Do I have to maybe give somebody a little shock to get their heart beats in sync? So that's where the commands come in. And then we have introduced and this is really like 0.1 version the application SDK. Now that was at the device side but what do you do higher up in the stack? You might want to process this data differently. If it's heartbeat data something if it's blood sugar data something else but that's in the space of the application. The domain knowledge comes from those people who create these sort of applications not as edgex framework people. So we want to make it easy enough to introduce a pipeline drop in a different machine learning model maybe do some other kind of smoothing alerting whatever so that piece will fall into the application SDK and I think that's a very, very important piece and that's maturing in this next upcoming release. Another thing with any open source project is you shouldn't be opinionated you should be inclusive in allowing different products to be dropped in and used but what does that mean you need another layer of abstraction you say I want data persistence and you should have commands but underlying that how does it get saved? Do you use a Redis database? Do you use a MongoDB database? Or like that simple automotive application for insurance that I was talking about maybe you don't even want data persistence and triple copy etc. Maybe the file system is enough or maybe you just want to pass through data so part of this Edinburgh release was he started offering different layers you know options for persistence so with all things open source great you can look at the code but is that what anybody wants to do and they want to just take it for a test drive, use it see if it makes sense for them you know figure out its pluses and minuses no they really want some documentation so I launch it is there some Docker compose file that I can just say run and then you know it pulls the right images and launches it, are there tutorials is there a dev kit and yes you can run EdgeX on a dev kit from there or by your own Raspberry Pi for about $35, $40 and get going and definitely you can run it in a VM which is what we did initially you can run it on your laptop so we've done a lot more you know support in there to onboard new users so that's a big big invitation please come and use it it's really friendly and if you find an issue and say hey your documentation sucks please drop an issue and we'll fix it we really wanted to get stronger, better and be more used another very important thing is we've introduced a lot more sample device services so Alex who's in front who you know put his hand up saying he used EdgeX, he contributed a GPS device service this was born from our work when we were doing that automotive insurance application and we said well now that we know about EdgeX and that it has all the framework requirements we need and we adopted this as the project we're going to work on we said hey let's put in a GPS device then we wanted to put an OBD device and that's going to come later but it also has some random devices an MP1 for network devices so a bunch of things and you can start using the device simple as your template so what are all the different southbound protocols that's one of the advantages of you know leveraging EdgeX you don't want to be building all the different protocols yourself that's the power of community so we have backnet support in there that's the one used typically for building automation there's Modbus which is used by the industrial internet of things there's BLE and there's MQTT so most IoT systems have MQTT that's been around for 4-5 years a lightweight messaging system but the other two were very important to break our way and path into the industrial space and the housing space another very important thing that came up with the 1.0 release is support for binary data it's all fine if you're just talking about temperature and pressure and you know the number 64 bits whatever but when you're talking about video data or high definition camera data that's a lot of data and this was contributed by Intel so I must call out it's not just as VMware with our team but there's a lot of input from Dell there's a lot of input from Intel and you know the industry is coming together to make this happen not only the gateway vendors camera vendors, hardware vendors but we're trying to make this something that anybody and everybody can adopt easily and I think seaboard data support was to help make all this image and video data support possible without you know busting all your resources and making that serial line etc work so last but not least you know all of IoT can have mud on it if it isn't secure and 1.0 release started talking and getting a little more serious about security wasn't just about some functionality and hey I got my you know light bulb to talk and I turned it off type of thing but we've started really addressing security there was a talk yesterday by Ting Yu Zheng from Dell who's done a lot of the threat modeling and he had a talk which covered all the things that are there today and coming up we've essentially used the stride threat model where leveraging proven patterns for security like you know have a secure gateway don't let all the rest api endpoints be visible to the outside world for people to poke and prod like you don't want some somebody coming and touching the system management agent and saying hey services restart or poking into the database and pulling out data so we have a gateway and behind that it's like a reverse proxy all the other services are there behind it so that's in place already with the number O today we have just one certificate for that gateway and then one for the secret store but tomorrow in the future release the next F release we'll have different certificates for each of the services and they'll have their own private channel for communicating with the secret store and outside then the secret store today it has an encryption key but we want to beef that up further with hardware layer for security under it something like a TPM based solution so that's our plan and this is where we are today with eject security we do have a security gateway we have a single set of keys and certificate for the main gateway and then we are looking at the threat model and trying to make it much stronger so to summarize security today secure communications PKI secret store this uses hashicorp vault it also uses hashicorp Kong for the gateway we have created because it's our one or release a security incident response you know process we have a small team of people so it's on need to know basis you know like mission impossible if you know it you better know it because you have a reason to know it and then we will triage it like any hospital type of thing see whether we can resolve it whether we can mitigate it and document it and publish it as necessary what else can I say about it so that's a private email only a few people get to see it and it's really controlled and will be responsible with our disclosures so this brings us to what's next October 7th to 8th we have a hackathon Henry Lau might be somewhere around and I said hey you know you should say how about a ten thousand dollar prize you didn't say the prize money but we're inviting users of IOT or anybody eager to try it out to you know apply it to a real world problem is it retail is it healthcare or something and see how it can meet their needs and in the process we also learn like what did we miss what else should we build because you can't imagine everything November 4th to 7th and I hope some of you will decide to adopt Ajax income everyone's welcome we have a face to face where we will decide the next features the G release features prior to that by the end of October or early November maybe around the time of that face to face we hope to release our Fuji version and I mentioned earlier we have our weekly meetings now I'm going to give you a little peek of what's coming in Fuji already hinted they're going to be security enhancements today's secrets if you have 10 services over there actually they're 12 they can see each other's secrets so it's like a trusted cabal of services but when we want to go more secure they're going to have their own secrets their own public private key pair certificates so that's the plan and as you launch the system they'll get their own keys or you can import those keys Alex over here is working on a command line interface for Ajax it was born of his own frustration when he was building the GPS device services oh my god I have to have all these curl commands I have to maybe keep them in a script and execute them and most of the developers had gotten used to doing that and they say oh you know I don't need it but then once he started pitching he said we need it we want it and this is so awesome so when he demoed it there was a lot of positive feedback and that's coming up soon Fuji release we'll be building cloud connectors to some of the well known clouds and you know Alibaba 2 may be in for the China market so we have plans for AWS Azure and VM Web Pulse IoT Center now there's a certification group so is this going to meet our API somebody's deployment or someone's reference implementation beat on a Raspberry Pi with XYZ amount of RAM or whatever so there'll be a certification process we're going to introduce more manageability to the APIs one of my special interests is to be able to update the software on an edge device we've seen this spectrum there's meltdown there's a new go module security you know CVE and I need to update my edge nodes and that's one of the places where you can have the major attack that's why you know IoT is hard because of the threat surface and so I would like to see in those APIs one could you know updating the software on my edge not just the application software mentioned earlier a leaner meaner inter microservice communication you know solution also mentioned earlier a richer application pipeline more black box testing testing testing testing always good and definitely performance testing so I'd like to call out that tomorrow my colleague Alex has a talk is he's going to be running EdgeX on a Raspberry Pi and he calls it as easy as Pi there were some not so easy moments and the Pi was burning in the oven type of stuff oh and I have it as Raspberry Pi okay anyway so tomorrow his talk is there please come he's an excellent speaker and he'll give you a good demo of EdgeX too and his CLI his CLI lets you even do meta level commands like dumping the database seeing what's in there etc and yesterday Tingyu Zeng from Dell spoke about security in EdgeX and his slides and his talk will also be available so please take a look so you feel more comfortable about using the system and with that I'm open to questions thank you for coming thank you