[0:00] Spyros Sakellariadis, ICONICS Global Director of IoT Business Development
All right. So, with that, we've got a few minutes left for a Q&A. And let's see if we have any questions from the audience here.
[0:15] Megan Courtney, ICONICS Marketing Coordinator & Social Media Specialist
You did receive a couple questions. The first question is, “ Can you talk a bit more about the difference between using IoT WorX and GENESIS64 as an on-premise gateway?”
[0:26] Spyros Sakellariadis
Sure. So, if you remember, in one of my earlier slides, I said there are multiple ways of getting data out of on-premise devices into the cloud. Up until about a year ago, the way we did it is we deployed some of the services of GENESIS64 onto an on-premise computer, configure that the data connectivity to the devices, pull them in and decide which points we're going to publish and point it to IoT Hub. This is something that worked flawlessly. I had one small, Intel nook, pulling 15,000 points from a couple of buildings, pushing it up to IoT Hub. Now, the advantage of that is very simple: deploy it on anything; if you have local access to it great, you could also RDP into it, great. The disadvantage of that is you have to deploy it locally; you need someone that's going to go and install all the software. And if you have to maintain it, you have to either have remote access into the box, or you've got to be able to get locally onto the box. Now, in some cases, that's a problem. Other cases it's not. IoT WorX is our more modern version which you can deploy from the cloud. You can deploy and manage it from the cloud. And you don't have to have any local access to that box. So the functionality of the two is very similar. You're again, discovering devices that you are going to publish data from. You're deciding which of those devices you are going to send up to the cloud and in what we call a published list, and off you go. So, the functionality is very similar. The difference is: do you have an environment where you have local access to the devices, and it's not prohibitively expensive to you to access them locally, or your security processes allow you to RDP into them. The advantage of the IoT WorX is that you don't have to have local access. You can deploy 1000s of them using templates from IoT Hub in GENESIS64 in the cloud, so it's much more efficient with respect to management and deployment. But it all depends on which way you want to go on that.
[2:56] Megan Courtney
Alright, our second question is, “How does GENESIS64 scale as you add more devices?”
[3:03] Spyros Sakellariadis
Well, the answer is, “It does.” You can have a very small GENESIS64 sitting in the cloud that's managing one very small building. In my case, I have GENESIS64 in the cloud managing about 10 devices in my home. As you scale up, we take the example that Tearle was showing you: 456,000 objects around in that case 125 buildings in the Microsoft Puget Sound campus. And essentially if you think of the scale elements, on-premise, you scale the gateways. You can add 1, 2, 3, 4, 5 gateways, any one gateway, depending on how often you’re getting data and so on. You might put 20 objects on it. You might put 20,000 objects on it. You'd have to actually test it to see how many you could run. And you've got to work out the licensing about how many devices you're going to license on it. But on-premise, you scale by adding gateways as you need them. Pushing it up to IoT Hub. IoT Hub scales just by increasing the number of units of IoT Hub you use. That one is essentially, for our purposes, infinite. I mean, there's is an upper number, but it's got too many zeros to know how to call it a number. Once we push it into GENESIS64, you come up with architectures: a small one, for example, you might just have one box that does all the functions. As you grow larger, you might start to differentiate the functions. You might have a front-end server running some of the services and a backend box running other services. You might decide to have four front end servers, two historians, and some other boxes. So, you can deploy those boxes in a number of different ways. And you optimize it depending on what you want to do, but it scales basically at the moment by adding VMs. And in our future product, it'll scale the product that Bouygues is running, you're scaling by increasing the number of units of the various services.
[5:13] Megan Courtney
Thank you. It looks like we’ve received one more question. They asked, “Why would you use ICONICS rather than writing your own fault rules in Azure Stream AnalytiX in using applications such as Power BI?”
[5:31] Spyros Sakellariadis
Well, I tried it. And you really don't want to write your own. Writing your own means essentially you're still deploying some sort of gateway in Azure IoT Hub, and so on. But then you are subscribing to the Azure IoT Hub with either an Azure function or Azure Stream Analytics. And you've got to start writing code. And this can be quite simple, or it can be hideously complex. Your Azure Stream AnalytiX T SQL code might be three pages of SQL code. Now, that's one thing. But imagine you have 3000 fault rules. You don't want 3000 separate jobs, all with two pages of SQL code. And then of course, you have your operator engineer who happens to be on an oil rig and wearing a hard hat who wants to get in and change a fault rule. You really don't want him to have root access to your SQL Server, no T SQL, and be able to work out “line 306 of your procedure that needs changing”. So, you can write your own, but it's a horrendously complex thing then to manage. It's a standard build versus by comparison. What ICONICS does is it makes it simple. It takes care of the security. It takes care of allowing people with the right level of skills and the right security level to manage the system and use the system as opposed to writing your own which is for a bunch of IT coders, will hopefully work.