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

Speakers

Brad Fischer

Sales Engineer II

Inductive Automation

Is it a bird? A plane? No, it’s Ignition! There’s enough buzz around deploying Ignition in the cloud, you’d think it would give your system super powers. But does a cloud deployment align with your organization’s grounded, realistic objectives? In this session, we’ll introduce cloud deployment concepts, discuss which architectures and scenarios benefit the most from cloud-based integration, and share real-world Ignition use cases.

Transcript: 

00:06
Brad Fischer: I would like to welcome you all to ICC 2023. Now, this is gonna be one of the first sessions that we're doing today, this is “What's That in the Sky—An Intro to Ignition in the Cloud.” My name is Brad Fischer, I'm a Sales Engineer here at Inductive Automation, and I'll be leading the session today. So before we take off, I wanna talk a little bit about our pre-flight checklist. Our primary goal when we're using Ignition is to provide information to users. And to support Ignition, a server needs to be secure, performant and available. And the kind of data that we're talking about providing to users, that information. That's not just alarms or real-time tag values, that's also history. Maybe an SFC that's been running. We've got a lot of different things that Ignition can interface with, and we want all of that to be available to our users. For it to be secure, our users need to be able to trust the information that they receive, and for it to be performant, users need to be able to quickly access that information. It also needs to be available. This information isn't of a whole lot of help to our users if they have to get up from their desk and walk to somewhere else in the plant to be able to access, say, an HMI or something that they're needing to get this data from.

01:34
BF: So let's talk about, what is the Cloud. It's a collection of servers accessed over the internet. We've got different services that that's providing to us. My personal favorite answer to this question is someone else's computer. So these computing services that are in the cloud or include virtual machines, networking all the way out to artificial intelligence and machine learning. It's an ever-growing field of services that the Cloud gives us access to. That's one of the reasons we wanna use it. We also want to do less of some of the more mundane tasks that we've been working with for a while, so I wanna do less hardware budgeting, procurement, maintenance. That also means I wanna do less in terms of configuration and migration. Eventually that brand new shiny server that we purchased last week, it's gonna be on its last leg and we've gotta replace it. Now we have to budget time and not only to procure that hardware, which got a lot harder since 2020, but we also have to migrate the operating system, Ignition, maybe a database, users, whatever it else it is that we've deployed on that server. We also wanna do less spending. By using a Cloud provider who's leveraging a data center, we're now able to take advantage of economies of scale.

03:10
BF: Cloud providers are using modern data centers to provide fault tolerance and redundancy through live node migration, meaning your application can be moved from a different physical server to another without you even noticing. They also have uninterruptible power supplies and generators to make sure that that data center continues to stay online even in the event of some sort of power blip failure, outage, brown out, whatever it might be. They also are gonna be storing multiple copies of your application and your storage volumes. The idea being if one of those fails, you wouldn't even notice. Could you do all of these things yourself? Absolutely, but it's gonna be more cost effective for you to leverage that economy of scale and let the data center do a lot of that background work while you reap the rewards. So if we're doing less of those things, we now have the ability to do more innovation and collaboration. We can use the Cloud to spin up Ignition and let our engineers start working on a project right away. Sure, you could use your own laptop or desktop, whatever development environment that you have, and we've been doing that for 20 years now, but by leveraging the Cloud, we now have the ability to have our remote workforce almost immediately be able to start collaborating and building something together.

04:41
BF: In addition, we now have the ability to get our information to a wide variety of users. And this data democratization is very important, that's one of the things that we continue to see Ignition coming and being deployed. It's one of the biggest problems that we solve. In addition, we can now leverage the Cloud to be more flexible and scalable. If we had purchased a server last year and we solved a certain set of requirements that we had, right? That problem that we had identified. Well, we just heard about the Ignition effect in the keynote. Ignition grows, it's not always easy to have your server grow with it. By leveraging the Cloud, we can now go through and re-provision that server and add additional CPU cores, memory, storage volumes and continue to make that server performant and available. We have a couple of Ignition Cloud deployment methodologies. As mentioned, Ignition Cloud Edition was launched this past spring, and that offered for the first time a pay-as-you-go model. It also gave us a fixed module set, and I wanna be clear that this is not a SaaS solution, this is not software as a service. We aren't hosting Ignition and maintaining it for you and upgrading it and such. It's very much the same way it always has been, you'd be running that version until you decide that you've gone through and vetted your application and you're ready to upgrade.

06:24
BF: As mentioned in the keynote, this is available today for AWS and Azure. We also have our standard Ignition Cloud deployment, and that's gonna be a normal installation, that six-digit perpetual license key that we've all known to love and deploy, but we could now put that in the Cloud instead of our onsite bare metal install or VM or whatever. And again, with this being a stand or perpetual license, you can now go and select the individual modules that you wanna use. So we've talked about what the Cloud is, why we wanna leverage it and available deployment methods. So why isn't everyone using the Cloud already? 

07:07
BF: I found that the top two reasons are security and architecture. Let's start by addressing security. So security has multiple facets, I've divided this into five categories, authentication, monitoring, networking, patching and physical security. And so some examples of those, password hygiene, multi-factor, zero trust. For monitoring, that would be various tools that are gonna be used and even staff members that are going through and reviewing logs or downloading them from one service and comparing them to another. For networking, that's gonna be firewalls, VLANs, even having separate networks. For patching, that would be upgrading your operating system or even Ignition itself, maybe the firmware for a particular motherboard or CPU chip set. For physical security, that's gonna be making sure you have locked server cages and rooms that you have audit logs and those kinds of things, you know who's been in there and what they've done and when.

08:09
BF: And when this is deployed on-premise, the responsibility is all on you. When we deploy this to the Cloud is where things get a little more nebulous, most of these things now become a shared responsibility. So let's go through and talk a little bit more about the different responsibilities of these sections. So for authentication, we have a couple of different things that we need to be able to leverage here, right? So you're gonna have to still manage your users and roles, and you also need to go back through and make sure that they have access to the proper items that you've set up for them to have access to in that cloud provider, right? Can they get back to certain networking features, can they get to an entire virtual machine, or are they really just able to log in to Ignition and utilize it? The Cloud provider, on the other hand, needs to be making sure that they're storing your credentials correctly, that they're routing Cloud resources to your account, and they probably need to be doing some auditing actions on air site as well. The bridge here is user and account management, and AWS, that's IAM Identity and Access Management, and in Azure, that's Azure Active Directory, which has been recently renamed Entra ID.

09:37
BF: We move on to monitoring here. You're still gonna be in charge of monitoring your application. Just because you've deployed Ignition to the Cloud, doesn't mean that AWS fully understands that your OPC UA module might fault and it would need to let you know. In addition, you might need to configure some monitoring services. That could be within Ignition, that could be something with a database. In terms of the Cloud provider, they're also gonna be monitoring their servers, clusters, any of their networking equipment, maybe hard drive temperatures, incoming power, their air handling units, a lot of things like that. All of that, again, goes back to that hardware that we've talked about that we don't wanna have to manage anymore, and so that's something that they can do. The bridge here is gonna be some of these services that the Cloud provides for us in AWS that's CloudWatch, CloudTrail, X-Ray, things like that. Azure has Azure Monitor. Moving on to networking, we still need to understand and configure all of our various networking resources. The Cloud provider is gonna be in charge and responsible of any of the switches, routers, modems, those kinds of things that are in their data center. They also, very importantly, are gonna be in charge of applying the end-user configuration that we've set up and making sure that it's going to the proper equipment.

11:06
BF: The bridge here is a fairly lengthy list. We have a lot of networking management resources here, and AWS, that's VPCs Route 53, Elastic Load Balancing security groups, Azure, we have VNets, public IPs, network and application security groups, as well as Azure Firewall. And this is not an exhaustive list. As you can tell, there's a lot of content in this area, and it's one of the things that a lot of people struggle with. In terms of patching, if you've used and chosen to deploy Ignition into a VM in the Cloud, you're still in charge of updating that virtual machine and the Ignition application that you've chosen to deploy on to it. The Cloud provider on the other hand, has the responsibility to update any of their underlying hypervisors, firmware for those computers, even hardware itself. Things will eventually reach end of life, or there's some sort of critical security bug that comes out and is affecting a particular chip set. It would be their responsibility to monitor those, and they replace that hardware with something that's not affected by that particular vulnerability. The bridge here is gonna be access to VM or the database, and so in Amazon, that would be the EC2 dashboard, AWS system manager, in Azure, that's gonna be update management or Azure Database for Postgres, MySql, whatever you're choosing to use.

12:44
BF: And then we come down here to the last one, physical security, this one's pretty easy. The Cloud provider is in charge of everything. They're gonna have a secure facility that they have created, most likely fences, checkpoints, guards, cameras, access logs. The only thing that I can see where you would have a responsibility for physical security, if you're doing something like writing your passwords down. So now that we've taxied out to the runway, let's get this plane in the air.

13:19
BF: Driven by Industry 4.0 and accelerated by the recent pandemic, remote access and monitoring is becoming more and more commonplace. So let's talk about how to offer users remote connectivity, after all, that's part of our primary objective. Right? To provide information to users. Remote accessibility can be provided purely through networking. In the simplest form, we could use port forwarding, exposed port 8088 over the internet, so that we can have external connectors coming in and accessing the Ignition web server. And this comes with a few hurdles, outside users would need to know that external IP address or a host name that you have associated with it, and that means you may need a static IP address or a public IP address from your ISP. And then you also need to configure your modem, make sure that the spot is being forwarded correctly. If you do have a dynamic host name or hosting that you've purchased rather, and you need that to connect to a dynamic IP address that your ISP provides you, you might need to go and leverage something like dynamic DNS.

14:29
BF: So now we've kind of made this a little bit more complicated, but the tools are out there, they're well understood, and so this could certainly be done. Seems pretty easy. Why do we need the Cloud? Problem here is that we don't have any real security that we've added to this, so anyone with that external IP address or a domain name could connect to the Ignition Server. In addition, none of that traffic coming from those clients to Ignition is encrypted in any way shape or form. So we could add an SSL certificate to our server. This could be self-signed, we have that option in Ignition that we could do a self-signed certificate, but a lot of today's browsers aren't really happy with self-signed certificates, they'll yell at you and make you jump through a bunch of hoops so that you can get connected. So we could go with a signed certificate, and that's certainly something that we could go with. You could purchase one through a variety of different vendors, you could also use something like Let's Encrypt, and we do have a Let's Encrypt guide for interfacing with Ignition on our website. So now that we've got security figured out, we can just move the server to the Cloud, right? 

15:45
BF: It's green. We've got it figured out. Not so fast. Now we've got the opposite problem, everything coming from the server back down to our plant is now insecure because it's now also exposed to the internet. While we could go and secure the database, maybe our clients, our PLCs become the real problem here. Most of today's PLCs don't have protocols that they've implemented that have any sort of security layer that can be applied. In addition, we've now introduced a lot more network latency between Ignition and those PLCs. And so if we do lose connection to those PLCs and then it gets re-established, Ignition is actually gonna go through and re-subscribe to every single tag on that device all at once. So that can lead to additional load on our server and even end up knocking other PLCs offline. So let's take a step back. We'll pull the server back out of the Cloud, we like this idea better. And while this is a valid solution and we're using SSL, we've still had to play around with some of that port forwarding, possibly maintain that dynamic DNS entry, and now, all these outside connections are putting additional load on the server that we're using to drive our OT operations.

17:13
BF: One of the solutions to this will be deploying a DMZ, secondary gateway that could handle those outside connections. And as you can see, those two servers would be able to share information using what we call the Gateway Network. By default, this is on TCP port 8060, of course, that's configurable. And by default, the Gateway Network requires TLS encryption and approve only connections. The remote services that this provides to us are things like real-time and historical access for tag providers, history providers, alarming and alarm notification pipelines, even the audit log, an alarm journal can now be transmitted over the Gateway Network. For those of you familiar with our enterprise administration module or 2-node redundancy, you'll know that we also leverage the Gateway Network for these.

18:05
BF: So, now that we know a little bit about the Gateway Network, we got a crash course there, I wanna go back to this diagram and note that that's what that orange link is that you see, that's that TLS encrypted pipeline between two Ignition gateways. And one of the very interesting parts about the Gateway Network, the way we set it up, while it is bi-directional, you only have to establish that connection from one server to the other. So that would allow us to do something like create the connection, the originating gateway would be our OT on-site gateway, and it would reach out to the DMZ, so we haven't had to open any ports into that server. But once it's connected, we now have a bi-directional method where we can share information between those two gateways. We can even use service security here to set up our tag providers, so they could be read only, for instance. So now there's no way, there's no admin user or anything on that DMZ gateway that would be able to write back to the tags on our OT gateway.

19:11
BF: Now that we've introduced another gateway into the mix, we've really opened up our possibilities. With the security provided by the Gateway Network, we can confidently move data between the gateways, not only on site, but across the web. So we can simply move our second gateway up into the Cloud to leverage Cloud computing, while retaining the same overall architecture and data flow. Once again, our OT gateway is configured to establish that gateway connection outbound to the Cloud gateway. And now we've finally arrived in an architecture that requires zero open ports on our router.

19:47
BF: Well, technically we are paying for a second router in the Cloud, but the idea is that we've reduced our attack vector at our site. We no longer need to open incoming ports, worry about dynamic DNS or anything like that. Instead, we're now leveraging those Cloud computing services to deliver and maintain these. With a gateway in the Cloud, we can now easily leverage additional services provided by that Cloud vendor. This could be an additional database that's in, say, a private network that only Ignition can connect to. And with that, we can now configure something like a tag history splitter on our OT gateway. And this would give us the ability to write that data to the local database, as well as that cloud database through the Gateway Network. Keep in mind, since those are now two database connections, they'll each have their own store and forward cache.

20:39
BF: So we have the ability to cache that data in the event that we can't get to the Cloud for whatever reason. Once we're reconnected, that information would be streamed back up. Cloud providers also have a variety of tools that we can interface. Things like artificial intelligence, machine learning, predictive analytics, data lakes. The list goes on. You've probably heard network security likened to an onion, in that there are many layers. We can combine our two previous architectures by deploying an on-site DMZ, as well as a Cloud deployment. And while this might seem like overkill to some, it may seem like the bare minimum to others.

21:14
BF: The good news is that Ignition can handle this easily, again, using our good friend, the Gateway Network. The key to this is allowing that new on-site DMZ gateway to act as a proxy, allowing our OT gateway to reach the Cloud gateway without a direct connection between the two. And once again, we can apply all of our service security rules to prohibit write access and things like that. So the Gateway Network proxy is actually set in this allowed proxy hops setting. You'll find other Gateway Networks in the config page of the Ignition gateway. This is specified per gateway. It does allow those indirect connections. And all of our Gateway Network services benefit from that. So tags, the audit log, alarms, everything like that. And so you can see a quick diagram of this, right? Agents two and three are connected through agent one to get to the controller.

22:14
BF: From the controller, we can actually create a remote tag provider targeting agent two or agent three, and it's simply proxied through agent one. We don't need to create layered tag providers or anything like that. So with that available, we can now really start to take advantage of some of our Cloud services and the benefits that they offer. One of those is scalability. Vertical scalability gives us the ability to add processing and memory, even storage to an existing server. But depicted here is an example of horizontal scalability, where we can spin up additional instances to distribute the workload across multiple gateways. For Ignition, this is primarily applicable to perspective sessions. And note that we could have simply implemented the same architecture on premise, but we would need to acquire the necessary server hardware to do so.

23:11
BF: Again, we can leverage the Cloud to get this spun up in a matter of minutes, whereas speccing, procuring, and preparing a server could take us weeks or months. This diagram shows three Ignition gateways behind a load balancer, and with sticky sessions set up on that load balancer, whenever any one of those clients comes in and connects, the load balancer will forward it to a particular gateway, and that entire session will continue to go between those two. That allows us to use authentication, make sure that we're having people log in to the application and they're not being redirected to a different server and going through some sort of looping process like that. So, our plane's in the air. We can set it on autopilot and just kick back.

24:03
BF: We've successfully solved our customer request for remote access to our existing Ignition deployment. In addition, we've found a way to do this in a secure manner, while ensuring both our OT and Cloud gateways are performant and available. Now let's take a look at some of our other use cases for Cloud computing with Ignition. You'll note here, before we dive into that, we're gonna go over the core modules that are offered with Ignition Cloud Edition. As I had mentioned earlier, it's a standard set of modules opposed to your quintessential list that you could pick from whenever you have a perpetual license that you purchase from us. And you'll note here that OPC UA is included here, and that's because we have the ability to encrypt communications between an OPC UA server, and that could be something like Kepware, Matrikon, even another Ignition gateway.

25:06
BF: We do not, however, include device drivers. They're explicitly removed from Cloud Edition because industrial devices really aren't designed to be connected directly to the Cloud. Again, that increased network latency, the way that subscriptions are gonna be done in the event of a connection loss, it's typically a tough move to try to expect a PLC or PLCs to maintain a subscription up to the Cloud. We also have additional modules that we're offering. We have the trifecta of Cirrus Link modules, MQTT engine distributor and transmission. And we also have new Cloud connector modules that we're deploying with Ignition Cloud Edition.

25:52
BF: Today, that's MongoDB. We have a growing list of Cloud connector modules that we want to develop and start to include with future Ignition Cloud Edition deployments. All these modules will be available for standard Ignition for a fee. In Ignition Cloud Edition, they're simply gonna be rolled into a new subscription. So now that we've talked a little bit about Ignition Cloud Edition, we can get into some of those examples. So one of the things that we've talked about is elastic remote access, right? Being able to spin up additional Ignition servers on the fly to meet customer demand, right? Additional perspective sessions. And so this gives us the ability to spin these up as we note that our first server is becoming overwhelmed, right? 

26:42
BF: And again, we can use Cloud services that are being provided to do this. And a great example here is if we have a large influx of upper management or engineering staff that suddenly need to investigate a problem with a certain process, right? And so maybe we have suddenly 60 more people that are trying to jump on and open up Ignition clients and pull data from last week when we had some sort of quality issue. Once that fire's been put out, and those sessions start to finally get closed, the Cloud could automatically sit there and spin down those additional instances. Since Cloud Edition is pay-as-you-go, as soon as we're done with them, we aren't really being charged for them anymore.

27:29
BF: We could have done this with perpetual licenses, but we would have had to have paid for that license up front, and we might see very, very little use for that second or third server. Cloud Edition also makes POCs very easy. There's no need to download and install Ignition, set up port forwarding or configure your internal VPN to allow access. Instead, the Cloud provider handles all of this for us. It allows us to quickly set up an environment that multiple developers can easily access, and even potential end users, be it upper management, project directors, even outside clients. After the POC, you can export all of your specific resources, the entire project, tags, even take an entire gateway backup.

28:17
BF: You could also simply spin down that instance. You'd probably be charged for some storage by the Cloud provider, but then if you needed that machine again in the future, you could simply spin it back up to continue that POC, recover any kind of scripts that you wanted to from it, even complete another demo with it if you wanted. Just as an example here, I've got a screenshot of what we can expect to pay for Ignition Cloud Edition. As you can see, that's based on the instance. Let's say we used a T3 medium instance from AWS for two weeks, and it was on 24/7. We're looking at a cost of about $330, depending on the region that it gets deployed to.

29:09
BF: We also have the ability to expand this out, and now include an industrial device in the mix. Maybe we want to show that we have the ability to connect to a local device, a local panel, an IOT or edge-enabled device. And so we can show that we can securely communicate that up to a Cloud gateway, and in the event that we lose network connectivity, we can even show that edge is automatically gonna go in and start buffering that data to its local store and forward cache. Which again, is good for one week or ten million records. We can also have an on-site panel or a client application fail over using perspective workstation, and retarget our edge gateway, allowing us to continue to monitor and view the process that we have been trying to keep eyes on, right? And so now we don't have this problem where our data isn't available because we've lost our connection to the Cloud.

30:14
BF: Of course, once this network outage is resolved, that store and forward buffer will automatically get cleared and sent up to Cloud Edition for storage in the database. So we've covered a lot of use cases for deploying Ignition in the Cloud and using Ignition Cloud Edition. So which one's the right choice? So what we need to talk through and answer that question, we need to consider the architecture that we're gonna be using, in addition to modular requirements. I know that there's still a large installation base of Vision, and if you're still trying to use that with Ignition in the Cloud, you'd need to go with Cloud deployment, where you'd be able to select Vision.

31:01
BF: We also need to consider budget here, and this is where we get into talking about OpEx versus CapEx. So instead of spending capital on servers and those perpetual license keys, we can now use operational budget to subscribe to Ignition in the Cloud. And so no matter what you've selected here, we've tried to prepare some Cloud formation templates that can help you understand what all would be deployed. Azure templates will be coming by the end of the year, but AWS templates are available. So let's take a look at those. So we've got our plane in the air, we've set it up for autopilot, now we're able to take advantage of formation flying.

31:46
BF: So for our Cloud formation templates, we have standalone and cluster architectures, and we even have the ability to deploy this into an existing VPC or a brand new one. And these solutions today require Ignition licenses, these will be perpetual licenses. Coming soon, we will have these available where you'd be able to harness Cloud Edition. And as always, there's no additional cost for using these partner solutions. These are something that we want to provide to the community to help them get Ignition up in the Cloud, take advantage of those extra services. So in our standalone architecture here, we have two Ignition gateways that are gonna be deployed, they're gonna be connected to primary Aurora DB, two replicas, we'll have VPC that gets created with public and private subnets.

32:34
BF: We have NAT gateways, bastion hosts, we even have security groups, key management, CloudWatch, and then we're using Amazon SNS to be able to send out alerts from Amazon when a particular gateway has become unresponsive or the CPU usage has spiked through the roof, something like that. We also have the ability to deploy Ignition into a cluster environment. This will be very similar to the previous slide. Note that we'll have two Ignition front-end servers along with a redundant pair for the back-end. Of course, we have NAT gateways, we've also added an application load balancer here. And then of course, we can access the gateways via a VPN.

33:20
BF: So, now that we've reached cruising altitude, we need to ask ourselves, did we achieve our primary goal? Have we discovered and been able to deploy Ignition in a way that would allow us to provide information to users in a secure manner, in a performant and available way? We're able to use and leverage the Cloud to securely extend Ignition's functionality. The Cloud gives us flexibility to ensure that these solutions are performant and data centers simplify or even remove availability obstacles. At this time, I'll turn off the fasten seatbelt sign and our flight attendant, I mean, mic runners will be coming around to answer any questions that you may have.

34:12
Speaker 2: Requirement or the suggestion for the proxy, what is that benefit? 

34:20
BF: Yeah, okay, we can talk about a proxy. So, you're talking about this one right here, we've added one kind of in the middle.

34:27
S2: Yes.

34:27
BF: Yeah. So, that's just something that I've seen some customers kind of almost require from an IT standpoint, where they wanna have an additional gateway that's now the internet facing one, right? And then, right, for security, exactly, absolutely. And so, my point, I guess I wanted to bring this into the architecture diagrams here and talk about that because this gives us the ability to proxy through that from the OT all the way up to the Cloud while maintaining that additional layer of security. Yeah, absolutely. Yes.

35:01
Speaker 3: So, I just had a quick question according to like the AWS pricing. So, looking at AWS, it's amount of money per hour. So, does that not include the Ignition license? Like, you're saying it's not SaaS, so, is that just including the infrastructure for running it, but you still have to purchase a license for Ignition on top of that? 

35:31
BF: So, that would include the license for Ignition and then the EC two instance, and that's where you get your total. When I said it's not SaaS, I meant you aren't subscribing to a service from Inductive Automation where we would go and maintain that server. So, you'd subscribe to Ignition 8.1.31, and that's what you would be running in the cloud until you decide that you want to spin down that particular instance and move to 8.1.32, 8.1.33. Whatever it might be.

36:00
S3: Okay. Thank you.

36:01
BF: Yeah. Does that answer the question? 

36:03
S3: Yeah, I believe it does. Yeah. Thank you.

36:04
BF: Okay, fantastic. And, so I think there's a question behind you real quick.

36:13
Speaker 4: So, in this example that you're showing, the 91 cents an hour for T3 medium, I would pay AWS that, and then you have an agreement with them for whatever the value of your software is. Is that correct? 

36:27
BF: So, you'd pay them the 96 cents an hour? 

36:30
S4: Yes.

36:31
BF: Five of that cents is going to the EC2 instance, and then the other 91 would be coming to us for the software. That's correct.

36:38
S4: Thank you.

36:39
BF: Yeah, absolutely.

36:41
S4: I have one more question, not to hog it. But, so I have dealt with AWS services with my internal IT group, and they've been really helpful with like the serious link broker and the IOT bridge. So, for configuring for a virtual private cloud, is there like YAML files that can be modified in order to set it up so that it can run on like our virtual private cloud easily? 

37:09
BF: Yeah, so part of those kind of formation templates that we've got would be a good place to start with that. And that's something you could also contact sales engineering. We could probably work with you to develop those YAML files and get everything integrated into your VPC. Absolutely.

37:22
S4: All right, thank you very much.

37:23
BF: Yes. Yes, sir.

37:28
Speaker 5: So, you've got Azure and AWS taken care of. Are you going to make a version for Vultr? 

37:36
BF: So, I believe we've looked at some of the other Cloud providers like that, Google Cloud Platform as well. And I think we're trying to wait and see what the demand for those would be. So, if that's something that you're interested in, I would suggest posting either on Ideas, right, the Ideas portal, or contacting your sales rep and letting them know that you have, you know, strong interest in deploying it somewhere else like that.

38:00
S5: Or I could just ask you, which I just did.

38:01
BF: Sure, yeah. But it's going to help us to know and have a head count of how many people are really interested in that kind of stuff, right? If we have a thousand people that are interested, that's going to obviously move it up in dev's timeline because we've got a lot of customers that are asking for this. Today, we've kind of identified AWS and Azure as the two primary Cloud providers in our area. So, that's why we targeted them first.

38:28
Speaker 6: So, ideally, in a few of our architectures, we have a backend server and a frontend server. So, ideally, would it be ideal that we keep the backend server in the in-prem and we move the complete frontend in Ignition on Cloud? Would that make sense or what all should we consider? So, for instance, I'm talking about 100 controllers under one gateway in-prem. And likewise, we have four different gateways, which connects to around 400, 420 controllers. And we have two perspective frontend servers with load balancers. So, can we remove the load balancer and the frontend perspective server and move to Ignition Cloud? Where I can also have a similar gateway at another site, which basically talks to the same application in Cloud, rather than having two perspective in-prem.

39:19
BF: Yeah, that's absolutely possible. And that's one of the perfect use case that we would see for Ignition in the Cloud. You need to be cognizant, right? If you move all of your perspective servers up to the Cloud, now if you lose that internet connectivity, your site might be flying blind. In some cases, that's okay, right? You might have deployed Ignition there. You were doing a lot of data logging through the backend. Your frontend servers were just kind of there as ancillary information. Could be that they're very critical to the operation. So again, that's one of those things where you have to kind of look at the architecture and decide what the appropriate deployment methodology looks like for your site. But you're right. I'm already seeing a lot of interest from clients that want to utilize Ignition Cloud Edition as a way to tie multiple sites together in an enterprise environment while allowing for a local perspective client to exist at each of their various sites so that that is now a segmented system, right? That entire site could continue to run in the event of a network outage.

40:23
S6: And additionally, while sizing, the sizing architecture suggests that for a perspective, we have one server for around 100 clients, 100 concurrent clients, let's say. And what kind of limitations should we look at when we do it in the Cloud? So for instance, there are like 400 users. So how many such instances would I require in terms of Ignition Cloud? Can it run in one large instance? 

40:48
BF: Great question. So standard Ignition and Ignition Cloud Edition share the same code base. And I would say that you would basically go and look at the server sizing and architecture guide that we already have to get an idea of how much a single server would handle. So I would still say, you know, you'd probably get 100 to 110, maybe 120 perspective sessions out of a specific gateway. And so then you'd wanna go through and horizontally scale to handle more sessions than that. And of course, when you put them behind a load balancer, right, we aren't using redundancy now. So I always suggest that you would do kind of n plus one, right? So if you need 400 users, that would be four gateways just to handle the 400. I would add a fifth as a spare, right? In the event that one of those fails or you're doing an upgrade or something like that, those clients could be moved to that fifth one.

41:39
S6: Fantastic, thank you.

41:41
Brennan Jewett: Brennan Jewett here with Flexware Innovation. We have a question about modules. So you said that there's a fixed module set. Are we allowed to use other third-party modules? Or in our case, maybe this is a two-part question, we have a product called LIFT where we create our own modules for integrating with AGVs and AMRs. Is there like a certification process to be able to use those or are we allowed to use any third-party modules? 

42:07
BF: Yes, a third party modules can be used with Cloud Edition. You wouldn't be able to use additional Inductive Automation modules. So there's no option to go back and say, purchase Vision and use that in Cloud Edition. But certainly, third-party modules like Canary and things like that could certainly be used, yes.

42:25
BJ: Thanks.

42:30
Speaker 8: Hi, I do have a question regarding when does a Ignition in the Cloud get spun up and when does it becomes dormant? Let's say that I have, well, if I wanted to think about this in the Ignition kind of way that I have a gateway event or something that is scheduled, just wanted to figure that out. When does it get, when does it, yeah, get spun up or when it becomes dormant? 

43:04
BF: So is the question more like elastic scalability or just when you go and you actually tell AWS that you want to start a gateway? 

43:11
S8: Exactly, yeah.

43:12
BF: Okay, so typically how long that process is? I found it to be anywhere from 3-10 minutes to kind of depending on the load on that particular server cluster availability zone at that time.

43:25
S8: Okay, so yeah, the purpose of this is, well, at least what I see in my head is if I want to be collecting KPIs or something from gateways across the globe. Or just seeing if all of them are like downtime and see if any of my sites are down. Having an EAM controller on my personal or on my company's network, if that site just ever goes down, I lose visibility to all of them. So if I put that in the Cloud, just wanted to make sense of how long it's gonna be running or to determine the cost.

44:09
BF: Right, right. Yeah, so you could certainly spin that up when you need it, right? Conduct any of your EAM tasks and then spin it back down. And again, that typically is, yeah, 10 minutes or less is what I've found. I think if you were trying to do something like spin up a particular gateway with a gateway backup that you want to seed into it, that's gonna be a little more custom code. Depending on the size of that backup, it could take longer to start Ignition.

44:38
S8: Is it gonna spin up or is it basically that's just bad architecture? That's not something you're gonna want to do with this Cloud Edition.

44:44
BF: So you're talking about implementing a gateway timer in the Cloud. Or are you saying in the...

44:49
S8: Yeah. I've got a gateway that's in our plants. We have gateway timers that may be running every 10 minutes once an hour, once a day. If I'm gonna move that up to the Cloud, is that gonna be a bad practice or is it gonna be able to spin up? 

45:03
BF: So it's probably not gonna spin up dynamically to run those timer events.

45:06
S8: So it's gonna be a 24-hour...

45:07
BF: You could try to orchestrate that with the Cloud but...

45:10
S8: So if I'm gonna keep gateway timers, basically it's gonna be running 24 hours a day? 

45:14
BF: Right.

45:14
BF: Okay.

45:14
BF: Right, yeah, absolutely. Well, that's all the time we have for today. I want to thank you all for attending the session.

45:22
BF: Have a good rest of ICC. Thank you.