 and the edge are starting to be integrated and edge computing being especially a hot topic. And so this call, this talk is titled Integration of Edge and Cloud IoT Platform. So we want to examine what's happening in the cloud, but what is also happening in the edge and how we can potentially unify this edge for cloud continuum when we are building IoT solutions. My name is Dasko Dasković. I come with a lot of background in building IoT system and especially a long time involvement in open source community and I started this project about five years ago, the project I will mention today and together with a group of enthusiasts and open source experts built a platform that today is in wide use all over the world. And today with me is Yanko Yanko Isidorović. He's a co-founder of a mainflux company, a company that was built on the top of this project and also very important for this talk. His background is in edge computing and he's been a chairman of one big Linux foundations project called Ajax Foundry. He's been sitting in a technical steering committee and he's been chairing application work group. So a few words about mainflux project. It's an open source project that is Apache 2 licensed completely patent free open source IoT platform. And it has been growing steadily and with over 30 contributors contributing to it often it's very live project, it's very active. And some choices were made when we started building this IoT cloud. It's written in Go programming language which gives us certain features that turn out to be important also on the edge. Mainflux is deployable in Docker and through Kubernetes it can be scaled out, can be maintained orchestrated and it is used today in production in the industry. On the top of this open source project the company was built a startup that offers professional services simply because when you build an open source project you're looking for a business model and then there are a lot of companies that are addressing you, they start using the software. And so basically in order to have a continuous support to the open source project a company called Mainflux Labs today exist and it's building solution on the top of the mainflux but it's also maintaining together with the community the core of the project. And now with this introduction in place I would like first to address the cloud portion of the IoT middleware and the way that we are building in general the IoT solutions. And then I will leave the floor to Yanko so that he drills down into edge part of what has been done with Dejax Foundry project. And then we'll talk again about the integrations of those edge solutions and the cloud solutions. So the cloud architecture can be seen as a few blocks that are always repeating when in building IoT platforms. And modern software is often architecture with microservices in mind in order to get this modularity and scalability fault tolerance and so on. And what's interesting, I'm using Mainflux as an example just the typical IoT platform. But what we did is as I mentioned that we used Go programming language whenever we could and basically structured it around one project that is called GoKit, which gives us a domain driven design all over the implementation of each microservice. So this has a nice consequence that actually the microservices themselves are very small and very tight. They can be a few megabytes maybe in size. So it's good for the cloud because you easily distribute those microservices not necessarily only with Docker's but Go builds a statically compiled binary that you just take it, put it on some other server run it and it runs, right? The everything is compiled into the binary. And this is a nice consequence also has that you can actually deploy the same code on for example, IoT gateway. You don't have to change any single line and have the same code base that runs on the in the cloud and on the gateway. And this is like the ultimate destination where we are going at least with this project is building a unified IoT platform that can spread all around this continuum from the edge from the modest gateway that can have maybe a few, few mechs of RAM. So we've easily run the whole solution on the Raspberry Pi type of computer and also the same solution we scale it out to hundreds of machines in the cloud geographically distributed. But to go back to the architectural blocks is that usually there are some clients which are actually the things and those things are connecting through some security through some proxy via different protocols to the back end of the system. And then usually you have some device management, right? And then there is a plethora of what we call protocol adapters. The point is that the things, what we call them the things the clients part of the IoT are different devices, right? And those different devices speak different protocols and those protocols in IoT are mostly unusual for a typical cloud solution. So you have, for example, MQTT protocol or constrained applications protocol and those protocols are a bit specific. Some are pure TCP like MQTT, co-op on the other hand is UDP so it demands a DTLS as a encryption mechanism and so on. So you need to have those protocol adapters in order to simply connect all these variety of different things. And then you would probably like to pump these messages to all your applications in the back end somewhere in the cloud. And what we did also is that we added one service that is called Normalizer so that we can actually process those streams as they come. And this is like a big, big picture of what one cloud infrastructure might look like. And you can see a different blocks here. Like there is, there are of course clients on the input. Sorry, I'll just go back. It's clients on the input, but there are, there is a part which can be a proxy security authorization, user management, device management and so on. One big part is of course messaging part. This is where you accept all those connections from different devices and then sending those messages internally in the system. You can have a storage part where you want to store those messages that are pumped from the devices and finally maybe you would like to visualize the content and of course any decent industrial platform must have a logging instrumentation, metrics and so on. So to go deeper and to see how this all works, to get at how it is interconnected in the cloud, here we see those same blocks like clients connected to a proxy, like it has a security, different security mechanism that you can apply. Once the device is authenticated, it then sends a message to one of the protocols. Let's say it's an MQTT device. It's going to the nuts which is extremely performant message broker. It's a cloud native message broker and then it sends it to a different applications, different consumers, or write it in a database and so on. And all these here are the microservices that we implemented. So they are there, they are in the Mayflex core, they are already available in the repository. But I put in a different colors here, as you can see the blocks that are related to the device management, the block that is related to the messaging, the data persistence, or the storage block, and so on so that you can see those patterns appearing in an IoT middleware. And in the ideal case, what we want to do is take the same architecture, the same blocks, and try to put them on the edge, try to distribute them or just send them as is, in the ideal case on the edge gateway. Because if we succeed to do this, then we don't have to change any line of code, we don't have to change the APIs. The engineers who are used to these kinds of platforms would understand it easily and operate it on any computer, whether it's a very complex cluster in the cloud, or it's just a simple IoT gateway, right? So going deeper into the details, as I mentioned, what are the users? Let's take a look at this part here. So these microservices, which is mostly user and device management. The users are the owners maybe of the devices or the admins of the system or the builders of the solution. And basically they go through this very standard procedure through the REST APIs of creation, the entities and supplying credentials and so on. But things are more interesting, like they are actual devices, and then those devices must be as well represented somehow into database so that you can, as some entity, so you can manage them, give them specific attributes and so on. And one interesting thing with the main flux, IoT platform with this cloud is that for messaging, in order to simplify and to make it very abstract and practically abstract away all those protocols, we, it's not invented, but introduced a notion of channels. So channel is basically very similar to a topic on a broker, let's say a topic on an MQTT broker, but it's parallelized for any of the incoming protocols so that you can actually use this channel and make two different devices communicate between them. They post on the same channel two completely different protocols so that you can subscribe on MQTT, for example, protocol, and then send some messages via HTTP and you will get those messages on the device. And basically with this, we completely abstract away the protocols and simplify the creation of the applications and the firmware on the devices. A very interesting part is definitely security and the IoT platforms are coming with different implementation of the security primitives. One of the typical that we've saw so far in the open source software, in open source IoT platforms were certification, authorization via some tokens, some credential that the thing have. And very nice example of very high security is something that typically Amazon AWS IoT had. And what they did is they introduced a mutual TLS for authentication and authorization of the devices. So we started going through the different IoT platforms that are out there today to find a similar implementation and when we could not find it, we implemented it in mainflex. So I think that it's, the mainflex today is pretty unique in that sense that it implements a mutual TLS for the device connections. And basically what it means is that you create a certificate for the device is a client side certificate and then authenticate the device via this certificate so that every device practically has a different certificate. It never leaves the device's hardware chip, for example, but only the public certificate is sent to the cloud, to mainflex in the cloud, which authenticates the device via MTLS so practically on a transport layer and establishes TLS encryption. So in order to do this for different protocols, we had to introduce some tricks or rather specifications. Where should we keep some information about the device itself? Where should, in which field of the certificate we should put this one? And this is all well documented on the project documentation, but nevertheless, it's a building block that we are very proud of today because it introduced really an industrial level of security into this open source platform. But as I mentioned, the platform itself, like building an IoT middleware, it's not only about messaging, there is a lot of things to do about device handling, but also those difficult infrastructural plumbings. And when I talk about this, I mean mostly about DevOps, right? How do you deploy platform? How do you maintain it? What do you log? How do you log? And so on. So all the stuff that you need in order to have a reliably running cloud platform today, right? And so main flux itself implements by design through the domain-driven design I mentioned and through those features that Go and GoKit offer us structured logging. It provides all the metrics and we are capable today to push those metrics into Prometheus, for example, or pump the logs through a FluentD into the elastic search and then visualize them with Kibana. But one other very interesting thing is so-called event sourcing. It's basically that whenever some event happens, device connects or disconnects or sends a message or something like this, you would like to inform the other microservices that this event happened. And we use for this a new Redis Streams. So Redis 5.0 recently introduced so-called Redis Streams, which is a log-based broker or storage that you can use for this kind of integrations. Very useful and already present in this implementation. So this was the cloud portion so that you have an idea of what we are talking today when we say an IoT cloud or IoT a middleware and I'll let Yanko now focus on the edge. So as Raskar said, you are perfectly capable of running Memflex on the edge. But you might find that at this point, Memflex does not have support for all the protocols that you need on the edge, like Modbus, Backnet and other industrial protocols that have been around for decades. So what we did, we got involved with the Adrix Foundry Project, that's a Linux Foundation project that aims to solve the issues that we have on the edge. And it's open source, it wants to be, it is vendor-neutral and architecture is quite similar to the architecture of the Memflex. So it really fits well with what we do on the cloud side, on the server side, with what we do with the Adrix Foundry on the edge side. Adrix Foundry is a set of APIs, loosely coupled microservices and Adrix Foundry has implemented those APIs using Go language. So Go programming language, so it's the same programming language that we use on the Memflex side. You can also deploy Adrix Foundry using Docker containers, so the same way as you can deploy Memflex, it's hardware and operating system agnostic, you can run Adrix on ARM or Intel or on Windows, Linux, Mac, even real-time operating systems if you need. And as I said, it's Linux Foundation project, it's Apache 2 license. The goal of the project is to enable companies to quickly create edge solutions and to integrate a different type of sensors to be vendor-neutral and to help reduce time to market with using Adrix Foundry. So in essence, when you take a look, when we talk about architecture of the Adrix Foundry, it's a set of 10 plus microservices. Initial implementation is in go, but there are a few microservices that are developed in C. And the data flow is like on the bottom side, you have devices that are connecting to the system using one of the many protocols. And we have REST, OPC, UA, Modbus, Backnet, ZigBee, Bluetooth Low Energy, MPTT, et cetera. And then those device services push the data to core services and then core services push the data to distribution services. And distribution services then can push the data out of the edge to next year in your IoT platform or to cloud. You have management and you have security also in the system. So how would that work? If you have a thermometer that records temperature and it would send the data using, what is this, Backnet to the Backnet device service, then device service would do its part and push the data to the core data. Core data would push the data to distribution microservice. And then you can connect this distribution microservice to many different clouds like Azure, AWS, Google, et cetera. And main flux, of course. However, distribution can also push data back to local analytics. And then this local analytics can do some processing on the edge. So in case you lose internet connectivity, your edge would still be able to do some computing and do some decisions independent of the internet connection. And if required, then the local analytics could issue a command to a command microservice, which would then push that command to MQTT adapter and maybe let's stop machine because it's overheating. So in essence, that would be the data flow to the adgex. And this is as short as possible overview of how adgex would work on the edge. And I'll let Draschko speak more about the integration between Edge and the cloud, if we did. Thanks, Yanko, for this presentation of the adgex foundry. And so let's now take a look at the possible integration of one system that has main flux in the cloud, it has main flux on the edge as well, and it has adgex foundry running on another Edge computer or IoT gateway. So we connected, so what are the scenarios that can actually happen when we talk about the device connectivity from just from the connectivity perspective? We can connect devices directly to the cloud, right? If we have some, a little bit more powerful sensor, let's say Wi-Fi connectivity on it, it can go directly through your home router or through some industrial router and connect directly to the application in the cloud. Or you can connect, let's say something that produce much more data, a connected vehicle, or some other machine. But what happens when you have devices that maybe don't have the IP connectivity, a Bluetooth devices, ZigBee devices, and so on, you would like to connect them first to the local gateway and then connect them to the cloud. There are many reasons why you need those Edge computers. You need them for local connectivity, you need them to save the bandwidth because maybe you don't want to send everything on the cloud, you want to do some processing here, right? To save the bandwidth of what's between the edge and the cloud. You want to have a low latencies between some mission critical machines and the decisions that are made on the Edge processing. So there are many reasons why you would have things connected through the gateway. But when we were talking about the gateway, here we said that we can use the same system that we use in the cloud for the simplicity. But sometimes it's good also to put the Ajax Foundry system as well because there are differences and those differences are mostly in the device protocols and the way that we can connect devices. So what will main flux as a initially cloud platform but now looked more in this unified IoT platform context provide you on the Edge? Well, it will provide you all those characteristics that I mentioned before when I explained what main flux has. So it has 509 certificates, mutual TLS. It has a very small footprint of around 5 megabytes per microservice. And so it will provide you also very important feature of unification of your system, meaning that you will deploy the same code base on both IoT gateways and in the cloud. And for this to happen, we had to implement a small demon, a small IoT agent, an embedded software also written in Go that runs on the gateway itself and basically is a bridge or a connector between a main flux running on the Edge gateway and main flux running in the cloud so that two main fluxes can actually communicate between themselves. On the other hand, what would EdgeX Foundry provide you on the gateway, all those great things that Yanco mentioned. But also, it will provide you mostly importantly the plethora of device services. And this is this layer here. So main flux was not so focused so far on implementing those device services. But EdgeX is one of their main activity is in building all those industrial protocol support, backnet, OPC UA, Modbus, all those industrial protocols that are really used on the factory floor in the industry. And basically, through the integration, if you put this system on your Edge gateway, then you can connect a huge number of various different protocols, devices that are talking different protocols to your Edge gateway and then send data to a main flux in the cloud through these distribution services as Yanco mentioned. But when you do these kind of integrations, again, you will need some kind of IoT agent, a small microservice that is running on your gateway to enable this kind of communication on the control plane, not only on the data plane. OK, you can use this microservice to pump data out to the cloud. But how will you control your gateways? How will you manage thousands of gateways that you deployed? But you use this for this in order for this to happen, you have to have some kind of firmware that is only used for a control plane between the cloud and your gateway. And in EdgeX, this is the set of microservices here that are related to the system management. But typically, it's one microservice that is called SMA or system management agent. And in order for this system management agent to function correctly with the main flux cloud, we, again, can deploy the Edge D demon, the same one that I mentioned before, a small piece of firmware that we deploy on the gateway in order to have a connection with the main flux in the cloud on this control plane layer. So what's missing today, but is coming very soon for the EdgeX is a UI so that you can actually have a nice user interface of all the systems that are running on your gateway. And typically, all those microservices in EdgeX, as in main flux, run in dockers. So you can actually deploy them with either Docker Compose or maybe Kubernetes, some Kubernetes variants. And basically, with this integration explanations, I would like to finish this talk because I would like to leave a few minutes for eventual questions if you have one. Thank you very much. Yes, please. Maybe, Yanco, you can. Thank you. So in our project, we already have a device management system. But we don't have IoT facilities. So is there any way we can integrate with the main flux? Yes, and the main flux itself provides, as I said, the facilities for integration through event sourcing. It is very easy to use. So whatever happens in the system can be connected and sent as an event to other parts of the legacy systems. And then one other point of integration, if you need it, would be on the very edge or on the gateway themselves. OK, thank you. Another question is that you mentioned you use channel to communicate with the device. So I suppose each device will have a channel, right? So channel is an entity that you provision in the system that you configure in the system. And it's up to you as a creator of the system to provision as many channels as you like. So typically, you can give maybe your device two channels or 10 or hundreds. Because it's analogous to MQTT topic, you can imagine that one device can be connected to many MQTT topics. And analogous to this, your device can subscribe or publish to many main flux channels. That's the idea. And very often, for the gateway, you would have, for example, two channels. One that you will use for the data plane, for communicating data, maybe sending it to the cloud. And the other channel can be used, for example, for the control plane, where you would set some control messages over this channel to the gateway so that it can stop, start local services, give you backlogs in the cloud, and so on. Just to add a thing. You can also have a single channel where multiple thermometers send the temperature. And then you have one channel where multiple devices send the pressure. And you will, main flux has the notion of publisher of a device that sends the data. So you can have a single channel for the temperature, the other channel for pressure, third channel for voltage, et cetera. So it's up to you to configure it the best way you need it. It's really flexible. And you can have multiple channels per device, single channel per device, multiple devices per channel. You can do it any way you need to do it. I believe we have just one minute left. OK, so my question is that your slice is mainly focused on the technical. So could you please tell us about any customer reference case with your project? Yes, so I think I put it on one of the slides. But so far, we saw one big deployment with one of the biggest retailers in USA, which is deploying a main flux practically in every store. So we are talking about 2,000 stores, and then connecting those main fluxes and managing them with another main flux instance in the geographically distributed cloud. So this is a scenario of unified IoT platform that I spoke about to which we want to go to. Yeah, so this is one example. The other example is one big company in the domain of oil and gas that is using main flux in managing a lot of gateways as well. The gateways are not a main flux gateways yet. But they have their proprietary software. But they have some pieces of the software that is necessary to communicate with main flux on the control plane, the EdgeD IoT agent that I mentioned. So this is another, let's say, use case or business case. And then we saw main flux applied in smart buildings, smart offices as well, to control a lot of sensors that would be connected either directly through two main flux in the cloud or through some kind of gateway. And did I miss something? We're out of time. We can take the topic offline. One more thing, with the main flux EdgeD, you don't need to have VPN to your gateway anymore. Because this EdgeD enables bi-directional secure communication. So you don't have to manage virtual networks anymore. You just put the daemon on your gateway and you take it in the field, connect it, and it's going to be fine and secure. And we have just a single port that is used for all the communication. So attack footprint from the outside is as small as possible. Thank you. Thank you very much. We have to stop the conversation here.