What’s That in the Sky? An Intro to Ignition in the Cloud

00:00
You. So how many of you have run anything in the cloud? Anybody run anything in the cloud already? No. Nobody wants to hear from me. Anyway, everybody’s done. All right, so here we go. So what’s that in the sky? In intro to ignition in the cloud, we’re getting started. What you all really wanted was another picture of me. So there’s another intro slide. But before we take off on this trip to the clouds here, we have a pre flight checklist. And so our pre flight checklist is what’s our goal here?

00:47
And so, really we want to deliver three objectives, and those are to ensure that ignition in the cloud would be secure, performant, and available, because really we want to make sure that secure so people can trust the information they receive performant so that they can quickly access the information they need and available, meaning that users that need the application to be running and accessible from a variety of locations can do. So what is the cloud? The cloud could be described in several different ways. It’s a collection of servers accessed over the Internet, delivery of computing services over the Internet. My personal favorite is just somebody else’s computer. And so why would I want to run ignition or some other system on somebody else’s computer? Well, that’s a good question. Let’s dig into it. Why use the cloud?

01:45
Here you can see inside of a computer that hasn’t been maintained and is very dusty. Hopefully, your computer at home does not look like that. One thing, the main thing that people want to go to the cloud for is so that they have to do less on their side. Less of what? Less hardware, budgeting, procurement, maintenance, less configuration and migration, and at a certain scale, less spending. And so by moving to the cloud, you can take advantage of somebody else managing all that for you because it’s somebody else’s computer. Right. So another side of this is they want to do more. What? They want to do more innovation, more collaboration. They want to focus on data democratization. They want to do flexibility and scalability. Right. And the cloud gives you a lot of tools that you can tie into to do a lot more.

02:40
Also gives you a tried and true backbone with which to build on top of. Now, to run ignition in the cloud, there’s two methodologies. The first one is our new one, cloud edition. And cloud edition is something that you can actually go into the AWS marketplace, search for ignition. You’ll find a listing there. It’ll list pricing and all that kind of stuff. And so you could buy ignition without ever talking to a sales rep. You could just go, you could spin it up and you’re running. Now you say, that sounds like a SaaS model. Why does it say specifically not SaaS? Because it’s not software as a service in that we’re not then maintaining your application, building your application. Right. Once again, ignition is just a blank slate.

03:32
It’s just a platform, meaning you still need to go and make sure that you’re running the latest version, make sure that you’re building out your applications, that if something’s failing, we’re not spinning that up inside our own cloud environment, but instead you’re spinning that up inside your own cloud account. Your own account within AWS. We don’t have any access to that server. We can’t go and look at it. You own it within that environment. And so it’s not SaaS, but a couple of things that are different. One, it has a fixed module set, meaning with standard ignition, you go, I want alarm notification, and I want perspective, but I don’t want reporting or this great, you just buy what you want with the cloud. It’s just an all in one package. And also the pay model.

04:27
I talked about being a subscription, but essentially it’s based on how big of a server you spin it up on. And so if you spin it up with just a few CPUs, it’s going to be one price. If you go up to a bunch of CPUs, it’s going to be more expensive, which is just traditional for cloud deployments. Right. So if we want to deploy within their marketplaces, that’s the way you have to do it. Right. And so that’s the only offering that AWS and azure provide, other than a separate model, which is bring your own license and just deploy ignition in the cloud yourself, which is the standard way of doing it.

05:10
The old way of doing it, which is you could just buy ignition, go and talk to element eight, get a license key, and then you can go and spin up an EC two instance or a compute instance, and then you can install ignition yourself. Right now you’re running in the cloud. Which one’s better? Entirely up to you. It depends on your system, right. You say, well, I don’t want the recurring cost of a subscription model. Great. You could deploy standard ignition. You’re still going to be paying for your other cloud services like the hosting or whatever else on a subscription model, because that’s all they offer. Right. But the ignition part would be perpetual.

05:46
Also, it may make sense to do standard ignition if you wanted to select specific modules, whereas Cloud edition might make sense if you’re just looking for something that is just going to scale for you. Yeah, go ahead. Are there any notable modules missing from Cloud Edition, or is it just like you said, I don’t want to report it. Are there any missing? Yeah, there are. There’s a slide later which is, I was looking at Mike, was that the next slide? It’s not the next slide, but just real quick, vision is not included, only perspective. And that’s really just because if you’re deploying stuff in the cloud, it should be in a browser. We’re just like, just use the new stuff, people, come on. People I’ve talked to recently, they’re like, are you getting rid of vision? And I was like, no, in those conversations.

06:39
That’s still true. Vision is still around. It’s just not included in cloud edition. There’s also some things with how Java works and stuff like that it doesn’t really make sense to run vision in a cloud environment. So we highly recommend perspective for cloud. Also, the next big thing is it does not include drivers because once again, don’t pull devices from the cloud, which we’re going to talk about here. But you should not have an architecture where you’re trying to talk directly to a Siemens plc or an Allen Bradley plc, for one thing, most of them don’t support encryption and even username and password. And so if you’re going to do that, it better be over VPN tunnel and all this stuff.

07:24
And it’s a better architecture if you’ve got something on premise that could be an edge device or it could be a full ScaDA system that’s doing stuff locally, but then also publishing to the cloud. So our recommendation is rarely cloud only, it’s a hybrid architecture that we would recommend. But you’re asking good questions, which is good. We’ll get to all of that also in a couple of slides here. But you’re right in line with where I’m going. Feel free to, I don’t mean that to say, don’t ask questions, please ask questions as we go. Could have sworn I changed that. But wrap, text wrap, we’ll see if these all line up here. So security is a big topic when we’re talking about the cloud, because people, which did I even. Yeah, it’s fine.

08:13
All right, so security people are like, I don’t want to go to the cloud because I can’t control the security. Well, that’s not entirely true, but it is different than deploying on premise. Right. And so we’re going to break up security into these five categories authenticatio, monitoring, networking, patching and physical. So examples, yeah, and it’s going to bother me the whole time because now the wrap is going to drive me crazy. But bear with me here. So from authentication, examples of authentication would be like password hygiene, MFA, zero trust, right. Monitoring. You can see at the networking, we got firewalls, vLans, separate networks, patching your Os, patches, antivirus, all that kind of stuff. And then physical security. How do you actually protect somebody from just walking in and starting to mess with your equipment, right?

09:05
And so for on premise, wow, that really is going to bother me. But bear with me here. My OCD kicking in. So on premise, who’s responsible for all of those categories of security? You. You’re responsible, right. Or your vendors, you bring in all that kind of stuff, right? But you’re ultimately responsible. So now if I go to the cloud, who’s responsible? You would think, oh, well, the cloud host, like AWs or ignition or who’s responsible? You’ll find that with authentication it becomes a shared responsibility. Monitoring, it’s a shared responsibility. Networking, it’s a shared responsibility. Patching, shared physical, I’ll give you that one. That one is wherever you’re hosting it, they need to take care of their own physical security. You’re not responsible for that, but you’re not off the hook for all these other categories.

09:57
And so coming into what some of those responsibilities really entail going into authentication, first, what do you need to do? You need to still manage users and roles. You need to verify, access, all that kind of stuff. But what does your cloud provider do? They could maybe store those credentials. They can route cloud resources to accounts, they can audit actions, all that kind of stuff. Right. But they don’t know who your users are. They’re not assigning roles, they’re not making sure only the right people have the right access. So you can’t just blame everything on them. Where does it come together? Well, you might leverage those cloud tools for managing those users, where they’re stored and stuff like that. And so aws, you’ve got IAm, their identity and access management.

10:39
Within Azure, you’ve got entraid, which is like their new active directory thing that they’re doing tied into all their services. But yeah, for authentication, it’s a shared responsibility. Coming to monitoring. Now, there it goes. Who’s responsible here? Well, you’re still supposed to monitor your application, right? Once again, it’s not a SaaS product. Right. We’re not monitoring for you. We don’t even have access to your system. And so you need to monitor your applications and or configure monitoring services. But what’s the cloud provider doing? They’re monitoring the actual hardware in their server centers. Right. And making sure that all of that and the networking equipment is working, making sure that the temperature is right, the power consumption is handled, all that kind of stuff. Where does that come together? Well, they do offer monitoring services that you could leverage. They come at a cost.

11:33
You have to pay for those, right. But you can do that coming on to networking. So you’re still responsibility for understanding how the networking should work and configuring it, figuring out which services you want to be able to leverage. What does the cloud provider do? Well, they’re going to provide the actual hardware once again, right, for all of that. And also they will be taking the configurations and actually making sure it is implemented correctly. But what’s the bridge together? Well, what are the services you’re going to be using? You’re going to have to set up VPCs, virtual private clouds, their networks. Their private networks, setting up route 53 for DNS and domain name stuff. Global accelerator. So if you have people logging in from all around the world, they come in through global accelerator.

12:20
Like our online demo project, if you log in here, you’re going to get to one server, whereas if I log in from California, it gets to a different server. Global accelerators do all that kind of magic for you, elastic load balancing, all that kind of stuff. Right. So they have all these services, but are they just configured automatically? No, you’re responsible for going and configuring them. Coming out of this, we go to patching. Who’s responsible for patching? You’re going to be responsible for updating your OS, you’re going to be responsible for updating ignition, all that kind of stuff. With Cloud edition, it doesn’t just magically happen for you, but they’re going to be updating the stuff behind the scenes, the firmware, all that kind of stuff. Right. Which you would have to do if you’re using your own servers. Where does that come together?

13:00
Right. You’re going to be able to do all that inside their interface that they provide. They also have scripting interfaces, their clis that you can leverage for those things. All right. And physical cloud provider does everything there, right. And that’s kind of tied into everything else. So that’s your main selling point on going to the cloud, right, is you don’t have to manage all the physical stuff. So let’s get this plane in the air. What are we talking about here. Well, a lot of people say, I want remote access. That’s why I want the cloud is because I want to be able to access my application from somewhere else, and remote access could be done. We see this happen too much.

13:38
Somebody’s like, great, I’m just going to set up on my router port forwarding so that people can come in through the router and they can access the server bad. Don’t do that. Right. There’s a lot of problems with you just letting people get onto your network. This is how you get hacked, folks. And so that’s all not protected, right. All that traffic there. And so a little bit better is to say, okay, we’re making people. Where do I show? I don’t know why it’s not showing, but setting up, like a VPN tunnel, right? So they’re not just getting there through the Internet through port forwarding, but instead they do a VPN tunnel in. And so now they have remote access, and at least you can encrypt that and secure that. That can be okay.

14:34
When people talk about remote access, that’s kind of the first tier, but it’s not a really elegant solution, because now you’ve got all this infrastructure for it to maintain and who should have access? And when they get onto your network, what else can they do? You’re actually giving people real access to your network and not just to your application. So this is good, but we can do better. So that says, all right, well, now should I just move ignition entirely to the cloud? And we would say, well, sure, you could encrypt the traffic between your clients and ignition, but now what about your devices and your database, all this stuff over here, that gets us to what we talked about in the beginning, right? Where are you going to be polling those PlCs directly over the Internet? Or is that now a VPN tunnel?

15:20
If it’s a VPN tunnel, maybe you would do that. But is that efficient? Do you want to be polling? There are better protocols to report by exception up to the cloud, that kind of stuff. So this still is not really the architecture we’re looking for, right. Because once again, everything is in danger on that side, or at least inefficient. Right? And so instead, we could have just kept ignition here, and then we can have people VPN in, but they’re on the network. Then I said, that’s not ideal. What if we separate our internal network, though, and we say we’re going to set up a DMZ, and when people vpn in, they’re getting to a jump host or just something inside the DMZ. Right. And then from there they can launch applications.

16:07
At least I can control what they can do on the network, and they’re not able to access everything. This is once again better. This is still a decent approach. Right. And we see a lot of people do this. When I talked about earlier today, I talked about the ISA 95 model, where this is like 3.5, where we’re coming in at a DMZ, and then they can get down to three, but outside applications can’t talk directly to three. They can just talk to 3.5, which 3.5 is a crazy concept. They’re like, oh, yeah, the purdue model didn’t work because we need to add another layer in between three and four. And so now we have a 3.5. So you can do this. This is a little bit better, but something I want to talk about here.

16:56
So in ignition, we have a gateway network, because once again, if you’ve got these two ignition servers there, what’s actually happening between there? What’s that orange layer? How are we actually sharing data? Well, the main way would be our gateway network, and that is by default going over port 80 60, mid ignition. It’s encrypted. It’s an HTPS port going through, or traffic going through. You can establish it as a one way connection, meaning you could just go outgoing. So you could be pushing out to the DMZ. And for this you can do all these different remote services. Right. So I could have tag providers. So I can actually share the tags with the DMZ server. I can have history shared, I could have alarms shared, I could have audit logs shared my alarm journal, historical alarms.

17:52
I could actually push out patches to different servers over the gateway network, all that kind of stuff. But our gateway network is our own proprietary protocol for ignition to talk to ignition. And so if we look at this architecture again, that orange layer there is our gateway network. So now I’m saying this server doesn’t need to pull PlCs directly, it doesn’t need to talk to the database directly. Instead, it’s able to get all that access, just an outgoing port to this one in the DMZ. And you could also restrict it to be read only, or it could be read write. You can configure all that in the gateway network. So you’re creating a layer of separation between what you have at the OT layer and what you’re now doing at a higher layer inside your DMZ and remote access.

18:42
Now that we’ve talked about having two gateways. If you were going to go through all that trouble to do that separation on premise, well you could also do that separation to the cloud. Right. And so with this part you can do that because this can be encrypted, like I said, the single outgoing port so you don’t have to open up any incoming ports into your network and having that be encrypted because you use HTTPs with SSL and all that stuff that works. Now this can be a decent architecture, but you have to make sure this is encrypted. And some people even take it a step farther and set up a VPN tunnel there. But for these services. But now you have a server in the cloud that your applications can access. And does that mean that this one is now exposed to these clients?

19:36
No. Right. You have local clients that have access to this server. And once again you could set this whole connection to be read only if you wanted to, so that any clients connecting to this can’t actually write to anything. Right. And also over this tunnel, if something was starting to hack, you could completely cut it off and you’re still able to run everything locally. Right. So you don’t lose compatibility if the cloud goes down or whatever else. So this architecture is pretty common now. Yeah. And also the data can flow up, which we talked about. Really. So other people like to do this with multiple layers.

20:23
This is where you start really getting into like that Isa 95 standard again, where they say, yeah, that’s great and all, but no, we need this server to be at level two and then we’ve got another server that’s in that DMZ or whatever and we need one hop there. And then this one can just act as a proxy to this guy. Then this one exists outside of that network. Right. And you can certainly do architectures like that too. What do you actually need to buy there, though? How much am I paying for this service now? I keep adding more servers. Right. Well this one could have zero modules on it. This one could just be the platform and that could act as a proxy. So all gateway network traffic would just flow through that server from the front end and back end.

21:03
Does that make sense? Any questions so far? Great. That means that I’ve lost you. No, you’re like, no, this guy’s crazy. Nobody’s going to go through all that. No, but it’s surprising how much people are doing this. They really are saying, we’ve got a server or maybe even multiple servers that are all pushing up to a DMZ server as a proxy and then that’s going out to a cloud server. And once again it’s all outgoing, but they’re socket connections, meaning that the ports are open, outgoing, but if you need to write back for whatever reason it’s supported. But you may want to lock down that functionality for security purposes. Right. All right, so this is the proxy setting I was talking about here. So how many hops do you want to allow people to do that’s all configurable, right?

21:59
Like, all right, now do I need actually more tiers in between to make sure I hit every level inside the purdue model in IsA 95, right? Maybe not, but you can specify this per gateway and whether you want indirect connections and all that kind of stuff. So that can any gateway that’s connected to proxy see any other gateway on the other side or whatnot, you can come and lock all that down. All right. Scaling out even more. So I talked about that you could have multiple servers here. Now I’m running in the cloud, right? So I’ve set up my architecture here where I’ve got ignition locally running. I’ve got this DMZ server now in the cloud. I have all these business users that now get these dashboards and they’re super excited to use ignition.

22:45
I can’t do that one server, so I want to scale out. Great, because we talked about cloud edition is licensed based on how big of a server you use. So I could just keep adding more resources, getting a bigger and bigger VM to run in the cloud. Sure. Or I could use several smaller instances and treat them separately. You can do whatever you want, but eventually you’re going to end up with multiple servers and bigger servers as needed. Or with standard edition you could just deploy them as needed, but that’s going to allow you to handle more and more clients. But now when I log in, how do I know which server I should talk to? Do I need to, as a user, have a separate URL for each of those servers that I hit? Ideally no, right.

23:35
It’s like I just scaled this out, but I’m going to put the same applications on them. I just needed more users. And so all the users should hit the same URL? Well that is possible. All you need to do is use this thing called a load balancer. And so a load balancer is a networking piece of equipment so that you can have traffic just flow into one point and then it’s going to go back and say, let me look at these servers, which one’s available? And maybe just as round robin assignments where it just says, going to assign the next user to this one, the next user to this one, then repeat. Or it can be more intelligent. You can set up load balancers to actually look at CPU and memory usage on the servers and assign users to ones that have fewer.

24:15
Or you can look at active sessions. Who has the fewest active sessions? I want to assign it based on that. But yeah, this load balancer becomes a critical piece of your cloud infrastructure to make sure that as you scale to the user, it still feels like one application that they’re accessing, even though now when they access it’s really touching five servers, if that makes sense. All right, looking at time, we’re going to cruise up to cruising altitude here. Climb up to cruising altitude, pardon the analogy. As we go here, we already talked about this. What modules are included? A bunch of them. Notably missing is vision, but also included that I didn’t mention is all of the MQTT modules.

25:02
And so if you want to leverage MQTT, that’s all part of Cloud Edition, including a broker, and then not included would be drivers for all the reasons that I talked about. All right, so now in this architecture, we’ve said, all right, now this is Cloud Edition. We could also have a cloud database, which means instead of just spinning up another VM and installing a database yourself, you could use a cloud managed database. And that can help you with elastic scaling and all of that kind of stuff. But say you wanted to actually try this, you want to experiment with this a little bit. You could go and experiment with Cloud edition. So Cloud Edition, apparently people don’t like to review things on the AWS marketplace. So you should go try it. Give us a review, tell us what you think.

26:01
Sad zero there, which is very uncommon to see reviews on AWS Marketplace. So it’s not like we’re special there. But you could go and spin up Cloud Edition, you could spin up a managed instance and it’d be a simple environment. You can come and you go in there, you’d see the pricing per hour. There’s going to be a cost for the software, and then there’s going to be a cost for the EC two instance, which is the server you’re spinning it up on. That’s your VM. So it gives you a total cost per hour. So if you wanted to go and spin this up for two weeks, what’s that going to actually cost you? This is in US dollars. So times this by 19 or whatever the conversion rate is right now. Right.

26:46
But you could go and do like an actual proof of concept where you actually spin up cloud edition, play with it, do this, and this is going to cover the database side as well. And you could see this. So the intent of this is like, I don’t need to go and buy the whole solution to go and try it, right? But instead you could just go and pay for it for a short period of time, see if it works with a relatively low amount of cost to do a proof of concept. But to go even farther with your proof of concept, you could also come and have ignition edge or standard ignition running locally, and you could get a trial version of that from our website.

27:28
But a common use case we’re seeing that people are trying is they spin up cloud edition, they put an application there and then locally they are running a client against that. So on premise, they’re just using an Internet connection to talk to the cloud server. But they also have this edge gateway that’s talking to the device, that’s actually the one that’s publishing the data up there over the gateway network, or it could be over MQTT. And then they say, all right, we’re going to set up local client fallback, which means if my connection to the cloud goes down, then I’m going to retarget my HMI here to now point to my local edge instance.

28:11
And this is a really common architecture for the cloud as well because they say, all right, I still need the data collection to happen locally, but I want to scale out with all the visualization options I’ve got in the cloud. But if I lose connection to the cloud, I still need to be able to run locally. I don’t need to be at full capacity. I mean, I don’t need every HMI to work or whatever, but I need key cells to still operate. You could go and test that with ignition edge at those key cells. Local client fallback is built into this. And so you go and try that. Highly recommend it, and it’s pretty easy to set up.

28:47
Looking at time, some of the advantages here, I know I’ve kind of bashed subscription models over the day, but there is some advantage to opex versus capex operational expenditure, meaning you’ve just got a monthly or annual budget and you want to be able to leverage that for buying your software rather than waiting for a capex budget. That every three years, every five years I get a big budget to buy my new system. If you don’t want to wait for that for the big upfront cost, just having some monthly costs may be manageable inside your budget. You figure out what works for you. Formation flying. This goes even farther, talking about clustered architectures and things like that deploying into multiple VPCs. And also eventually we’re going to be supporting docker containers in the cloud instead of just VMs because right now we just support VMs.

29:43
So it can be Linux or Windows, but it’ll be even cheaper if you want to run it eventually in a docker container. So that’s coming soon. And one thing I wanted to mention is so cloud formation templates, these have been rebranded now within AWS to partner solutions and they’re called something similar in Azure. But essentially if you wanted to go spin up cloud Edition, you could just manually spin up just cloud Edition. But we have on our website, or if you go to AWS and look up partner solutions and find ignition, then it’s got the ability to spin up one of two architectures for you where it’ll do all the networking, all of the other services in AWS that you’re going to need all out of the box.

30:27
And so it’ll actually spin up ignition, it’ll spin up database, it’ll do it replicated across availability zones. So if one goes down, you still got the other one. It’ll set up auto scaling groups for handling the bastion host, which is how you remotely access this for development and things like that. Or there’s another option where it’ll actually do a scale out architecture with a front end and back end in each availability zone. But the nice part about this is if you’re like, well, how am I going to set up a load balancer? How am I going to set up my VPC and set up my nat gateway which is going to allow the Internet access and all this kind of stuff. You don’t know all that. That’s fine, that’s what this is for. This can just spin it up for you.

31:09
Now be careful, there is cost associated with all of those extra services that get spun up, right? So don’t just play around, spin this up and then leave it. You’re going to want to go and make sure you’re aware of the money that you’re giving to AWS at that point, right? Or to Azure. Same thing. We have one of these coming for Azure, but they can be a really useful tool to get you visibility into how it should be architected, if that makes sense. In closing here, we talked about security, that it’s a shared responsibility, right? That you can’t just say I’m going to the cloud, and now my cloud hosting provider is going to do all the security for me. You still have some responsibility there, but they can handle some stuff for you. Is it performant?

31:54
Yeah, but if one server is not going to do it for you can scale out as much as you need to and then also availability. We talked about different availability zones, so if a whole data center goes down, you could still be good to go. And that’s what we do for our online demo project. We have one hosted in Australia, one in Germany, one in the US. I think that’s the only three right now. But where you log in from sends you to the appropriate environment. And then within each of those environments, we have multiple front end servers behind a load balancer. And so there’s lots of cool stuff you can do. If you had become a global enterprise organization. All running ignition in the cloud, it gets pretty fancy, but we’re out of time. But any questions?

32:41
It seems like I’m being encouraged not to find questions that we got places to be. Oh no, he says we’re good. Any questions? Who’s interested? Who’s considering looking at deploying in the cloud? Few people in the back. Thank you, I appreciate you. Yeah, I’d encourage you to go play with it. Should you move to the cloud just for the sake of moving to the cloud? No, I talked about like, don’t just throw data in the cloud for the sake of moving data to the cloud. Right. But there are some real use cases where the cloud can make sense. So make sure you keep it in your tool belt so when the right opportunity comes along, you’re ready. Thanks everybody. Have a good one. Thanks.