Modern Cloud Deployment Strategies

Speakers

Travis Cox

Chief Technology Evangelist

Inductive Automation

Kevin McClusky

Chief Technology Architect & VP of Sales

Inductive Automation

With the systems getting larger and the need for flexibility increasing, effectively running Ignition in the cloud can be a powerful deployment strategy. In this session, Inductive Automation’s architecture experts will talk about how to utilize the cloud for modern deployment strategies.

Transcript:

00:03
Travis Cox: Alright. Hello everybody. Can you guys hear us okay?

00:09
Kevin McClusky: Testing, testing. We are coming through.

00:10
Travis Cox: Alright. There we go, there you go. Welcome, welcome.

00:14
Kevin McClusky: Alright.

00:14
Travis Cox: To our “Modern Cloud Deployment Strategies” session. I don't know if we need much introduction, but I'm Travis Cox.

00:18
Kevin McClusky: I'm Kevin McClusky.

00:20.
Travis Cox: And we're happy to be here today. We have a pretty good agenda for this session. To talk about how we can leverage a cloud in really meaningful ways with Ignition. So we're gonna look at why leverage a cloud. Why is... What kind of benefits does it give us? Look at some security guidelines around that, so of course, you're gonna have a security-first mindset when going to the cloud.

00:40
Kevin McClusky: Sure.

00:40
Travis Cox: And then, we'll show you some of the deployment strategies that we've been working with a lot of customers on and ones that have been very successful. From extending on-premise solutions to full cloud-native solutions, how we can do redundancy high-availability in the cloud, how we can scale with the cloud, scale Ignition in the cloud to serve very large systems, as well as extending on to use cloud services, a lot of services that Arlen [Nipper] showed in the previous session here. And then, we will touch on infrastructure-as-a-code and platform-as-a-service here as well.

01:16
Travis Cox: So I wanna first start out here with why leverage the cloud and why we are having a session here. The cloud itself provides a lot of opportunities for us. Not saying we're moving solutions to the cloud. There's still very much a need for on-premise solutions, but being able to extend your on-premise solutions to leverage the cloud for what it can do, it provides a lot of additional value to your overall system. So whether that's providing broader access to data. That means that there's more visibility across the enterprise, more people will be able to get access to data, especially on their phones and tablets, that is gold, especially during the pandemic, being able to... A lot of people... A lot of companies wish they had more remote... The ability to view that data remotely, the cloud can offer an easy way to do that, we're gonna share that today.

02:09
Travis Cox: But it also allows to provide true scalability. It could be a great long-term storage of data. It gives us the ability to scale to hundreds if not thousands of people that wanna look at that data and then additionally get into a lot of other services like ML and AI and other analytic functions that happen to be up there. So you kinda get that unlimited storage, unlimited computability with the cloud. I'm sure a lot of you have taken advantage of it so far. And the real thing here, the message is today is, it's gonna help kick-start our Digital Transformation journey in a real meaningful way to take what we've done, all the work that we've done on-premise and be able to leverage this for a lot of real... Solving a lot of business cases that you may have.

02:53 
Kevin McClusky: One of the important things that we've tried to do in putting this presentation together is take a lot of the lessons learned that we've had with companies that we've worked with over the years. Take some of the best architectures, infrastructures that folks are using today and have found a lot of success with and introduce those to you so that if you're starting your cloud journey, you're going to be able to take advantage of all of these countless hours that have gone into this, both from the Inductive Automation side and from other integrators and end users who've gone through this journey as well.

03:25
Travis Cox: Absolutely.

03:26
Kevin McClusky: So if we take a look at the cloud, you really should start with security. Security is the bedrock for everything. You wanna make sure that security is in place, the right security is in place, if you spin something up on the cloud that doesn't have any security, which actually is kind of hard to do these days because these cloud platforms encourage you to have the security. But really focusing on security. If you were to spin it up and it has no security, then that is a useless system. So you really wanna make sure that you at least understand the security technologies and you utilize them.

03:57 
Kevin McClusky: HTTPS, TLS 1.2, 1.3. You'll always, If you have a cloud system, something that's publicly accessible, you'll always want to purchase a domain and trusted SSL certificate or a TLS certificate, and you wanna encrypt all of the connections that are coming out and that are going into that system. You do wanna leverage outbound connections. So basically, the connections can be outbound from systems, and we'll show you a few architectures here where we can talk about this a little bit more, but they're going to your cloud system, you're not having connections from the cloud system going back to on-premise because you have to poke holes in the firewalls, and that's not a very easy thing to do from a networking standpoint. You wanna take advantage of the federated identity providers. So two-factor authentication or something. If you have these federated identity providers that you can just do, that's often just a little check box option for these things, and then you can set up a few pages of configuration, and you're good to go. Automated Session Timeouts. Those are supported inside Ignition across the board at this point. We... A few versions back, we added them for a number of additional sections that we were missing them for, for example, for log out from Gateway Configuration pages and so make sure that you have those set up.

05:12
Kevin McClusky: The Principle of Least Privilege is a security principle that is really good to follow, really if you're doing anything, but especially on the cloud where security is more sensitive, so that idea is that if an engineer needs to be able to turn something off, he should have permission to do that. If an engineer doesn't need to be able to turn something off, then he shouldn't have permission or an operator or a supervisor. Just because somebody is there and they have the title engineer, it doesn't mean you should have the keys to the kingdom, you should have everything open for that person. It should be someone who you're carefully vetting and putting in the right security roles to make sure that they have the security that they should, and they don't have the security that they shouldn't. Not necessarily because it's a trust thing. If there's a disgruntled employee, that's always a possibility of a security problem, but largely because it's also if these systems or these accounts get compromised. So if you have an engineer, and all of your engineering accounts have access to the whole system, if just one engineer's account gets compromised, their password gets stolen, they... Somebody gets into their system, they could take down the whole system. So you wanna make sure that you have those security levels set up well, and then, of course, turn on auditing, that just kind of goes across the board for all projects you have in Ignition.

06:25 
Travis Cox: And it's important to know that at least with Ignition when you first install it, not all these things are turned on. That's why we have the Security Hardening Guide so that you can go through, kinda see all the things that need to be adjusted so that we could put our best foot forward in terms of our security stance. When deploying these kind of solutions, especially when going to the cloud with all of the ransomware and attacks and things that are out there today, it's really important to follow these best practices that are out there. So we're gonna look at some the deployment strategies here, and this is the kind of main part of this, but these are just ways that people have leverage of cloud. How to deploy Ignition, whether it be extending on-premise or fully cloud-native, but we're gonna show you the details of how this works and how you can scale that out as we go forward.

07:11 
Kevin McClusky: And we're not gonna spend a ton of time on each one of these because Travis has a cool demo that we wanna show off, and we wanna get through all these slides, but we'll start out with extending on-premise. If you take a look at just on-premise there on the left-hand side, and then the center says AWS cloud. So if you start with something on-premise and you just want some additional visibility, but you want that visibility from the cloud, the easiest way to get into a cloud deployment is to do this.

07:37
Kevin McClusky: So you just take something. In this case, it's AWS, it could be Azure, it doesn't really matter what cloud platform, it could be Google Compute Engine as well, and AWS is called EC2 for the compute engine where you run basically virtual machines up there, but you take Ignition, you put it in a virtual machine or in an EC2 instance, as we have pictured here, and then you have a remote tag provider going back to your on-premise in a read-only connection. So that system is completely separated out, the connection is going to be an outgoing connection from on-premise to the cloud, and then you can have anybody with Perspective clients, or Vision clients that is sitting wherever they happen to be connect into that cloud server, seeing the things that are happening, seeing real values, real tag values, but in a read-only way where there's no possibility of anybody who has access there writing back to those tags or affecting the live system in any way. So it makes it easy to just tap something on and give people visibility into the actual live system that you have on-premise.

08:35
Travis Cox: Yeah, this was a really important technique, especially during the pandemic. When it first started, a lot of companies, a lot of manufacturers wanted to get data to people remotely and didn't have access. Some had VPNs they can get in, but it might have been difficult to get down to the OT layers. And so just by simply being able to put a system in the cloud and being able to connect, this case maybe a gateway network, it could be MQTT, but connect up, it provides a lot of value very quickly, and you can leverage the exact same project you built on-premise just literally bring it to the cloud and be able to query all that data the same way as if you were on-premise by going through our gateway network.

09:15 
Kevin McClusky: If you don't have this in place, you can do it today. You can... If you have somebody who knows AWS they can spin it up in two seconds. It's super easy.

09:22
Travis Cox: It just means one more license of Ignition in the cloud with really just the Perspective Module. That's all you really need up there to make this happen. And because for tag history there in that system, you would get Tag History Query Mode, which would come with that when you're trying to query through the gateway network or to a database directly.

09:41 
Kevin McClusky: That means that it streams all the way from on-premise, so if you're looking at charts and graphs on your cloud system, it'll automatically stream all that history from your on-premise database up through those charts and graphs and reports and whatever else that you have from the cloud visualization.

09:58 
Travis Cox: And as I did in the previous session, you can query the data through the gateway network, but a lot of people are saying, "Well, there's an opportunity here to be able to store that data long-term and be able to do that in the cloud where we can have data for many, many years in a much more scalable environment." And both Azure and AWS they provide services for this, and in native AWS, they have what's called RDS, it's their database service, and you can use Postgres or MySQL or SQL Server as a service there, and it could be very easy with Ignition to mirror the tag history splitter to mirror that data from on-premise out to the cloud, have that storing in that database long-term where then you can, especially, if you had multiple sites aggregating data up, you could then query that in your Perspective dashboards, get people more access to that history, and that's not gonna affect anything on-premise. It's gonna be purely all in the cloud in terms of that data.

10:48
Travis Cox: And then having it there means that there you can go and start leveraging other systems or services that can query that data as well, so a very simple step in both, and just extending on-premise, literally, we could do this... We have shown customers doing in just in 10 minutes, we can go up there, get these things connected, or get Ignition installed, get it connected to the on-premise, and we bring that project in, and we're off and running. It's really that simple.

11:14 
Kevin McClusky: If you're less familiar with AWS side of things, RDS, those are all SQL-based databases.

11:18
Travis Cox: Correct.

11:20 
Kevin McClusky: So that's... They've got a Postgres and a Microsoft SQL Server and their own database, their... Help me out here, Aurora.

11:29
Travis Cox: Aurora.

11:30
Kevin McClusky: That they have that's compliant with a couple of those, and there's a whole variety of them. But those are SQL-based databases. Every cloud service that's out there has SQL-based databases that can be spun up in the same way.

11:39 
Travis Cox: Yeah. Again, we're just using the AWS as an example to illustrate the idea.

11:46
Kevin McClusky: Yeah. And then if we extend this one step further, and we take a look at cloud-native Ignition as we have it labeled here, this is taking the same idea. You can see there's Ignition running in that EC2 instance, and you have RDS. But now you've taken advantage of IIoT. So the connections right there in the middle, MQTT, MQTT Sparkplug connections, and those are going, same way, it's an outgoing connection from on-premise, but now you get data models that are flowing through, you get data that's being sent over in the Sparkplug-compressed format, and it's a format that also other systems can tie into. So it's not a proprietary Inductive Automation format, it's one of those standard formats, and it's actually an Eclipse standard that manages the spec, and it has a technical or a TCK and Sparkplug-compliant logos for different things and all of that, so you get to take advantage of that piece of things, and then that opens up even more as you put Sparkplug in place too.

12:45
Travis Cox: And there's a big difference here. Just to emphasize between the previous slide here where we're really extending that, we're using Ignition's gateway network to bring that data and that project to the cloud. And ultimately, there's nothing configured in the cloud in terms of data. It's just a gateway network connection. Now, the project does exist up there, but when you look at going cloud-native and leveraging MQTT, you actually are publishing that data, and it's available in the cloud. It's discoverable by Ignition other services, but then that's where your configuration can actually live. So you can have separate history and alarming, and the configuration. So it can mean that you may have a full presence on...

13:28
Travis Cox: At your site, you may have a full-blown Ignition server where you're doing all that locally, or you may just simply have Ignition Edge, and that could be it where you're going edge to the cloud, where then that could be your main application that you're providing to people, and all that configuration of the application lives up there. But then you can take advantage of the fact that we are now publishing data through MQTT. And we're seeing a lot of momentum in this. In fact, Discover Gallery this year has quite a few applications where they are cloud-native, leveraging Edge out there, getting data securely to the cloud through MQTT, and fully building out scalable and robust architectures in the cloud. And that's what we wanna go through here is kind of show you how we can go progression from something as simple as this.

14:06
Travis Cox: This is a way of getting started. Takes no time to put a server up there and to make a connection, whether it's gateway network or MQTT. But then, how can that scale over time? How can we leverage more to make this a much bigger system? So this is a starting point with one server there. Now, before I go into looking at the different ones, it's important to understand in terms of how we scale in the cloud, how this works, and how AWS and Azure, how their infrastructure works. So there's a notion of regions and availability zones that the cloud has. A region is a physical location around the world where they have, or they provide clusters of data centers. So if you're familiar with AWS or Azure, I'll use AWS as an example.

14:51 
Travis Cox: They have a Northern California region like US-West-1, or they have an Oregon region, or they have a Virginia region, or of course, they have stuff in Frankfurt and Sydney, all around the world. They've got these different physical locations. And in that region, they're gonna have availability zones. And these are separate data centers that they have that are all networked together. They're extremely., They have extreme fast connections, really low-latency connections between all of those data centers. But the reason they're architected this way is because, as you know, they... We try our best to keep data centers running with redundant power and all of that. But if we had natural disaster happen, it's possible for a data center to go down. And if you talk to any AWS or Azure professional service person, they tell you to use their well-architected framework. And that means that you wanna set up a resilient system so that if there was an issue with a data center going down, that a system can keep running. So we're gonna show a little more about how this works, but it's important to understand how these are organized so that we can put Ignition in there in a way that's gonna ensure that it will, A) be reliable and, B) be scalable going into the future.

16:06
Kevin McClusky: In these example of regions, as you can see there on this slide, the A, B, and C availability zones. In AWS, that's how they're actually listed out. There are three availability zones per region, and that becomes important in our next slide here.

16:20 
Travis Cox: And that differs on different regions, but you'll see like, US-West1-A, US-West1-B, and C, and it's... So that when you go, and you actually use their cloud console, you would see this terminology there in play.

16:34
Kevin McClusky: Yeah. Each availability zone has a high amount of uptime, but it's not 100%. And so there's the idea of availability zones is if one goes down, another one's gonna be up. You can have your system separated out. And if we take a look here, this is taking advantage of that. So inside AWS Cloud, this is the same architecture we just looked at, except it's taking advantage of these availability zones. So you have availability zone A, availability zone B, each one of those availability zones. If one goes down, the other one basically takes over. And this happens to be using Ignition's redundancy as part of this. So you can use Ignition's built-in redundancy along with the servers that are up in the cloud. You have one server from redundancy and one availability zone, one server, and another availability zone. And if one of those goes down, the other one takes over. If you're familiar with Ignition's redundancy, it works the same way as if it was running on-premise on two physical systems. Or if you add VMware and you've got the two systems side by side because you might wanna take one down, update the operating system, bring it back up, and have zero downtime. So it's the same idea here. If that availability zone goes, it automatically fails over to the other one, and then it can automatically fail back.

17:48
Travis Cox: Yep. Alright. So, going back to this diagram here for a second. We are using MQTT, and with these two different, we get Ignition redundancy. So the application is redundant across the two, and if one goes down, of course, the other takes over. But there is... We are sending data to the cloud through MQTT. And so that means that there's MQTT broker, and the cloud's gonna... That we're connecting to. In this particular case, we have two brokers. We have one on Ignition primary and one on Ignition backup. And ultimately, our Edge side would know about both of them so that if its job is to send it to one of them, it doesn't matter which one, just send it to one of them. And ultimately, it's guaranteed that it's gonna get to the actual application that we have here. So Ignition's gonna connect on the engine side to both of those as well. And by having two in there, MQTT is set up by default to be highly available. And so that way, we'd never skip a beat. We'd be able to get that data. So looking at this, I wanted to put out here that there are different broker options you can go with.

18:53
Travis Cox: There is a module that goes into Ignition called MQTT Distributor that you could use. It's part of Ignition. People like that one. However, you could use the cloud broker as well, like AWS has IoT Core, which is a 3.1.1-compliant broker. Azure's is not, so be careful about that one, but you could also just deploy up there a Chariot broker, you could deploy up there HiveMQ broker. They're here at the conference this week. And so the idea is that you wanna deploy that and put it up there in a highly available way. So I would recommend that you break away the broker from Ignition, so you have that be its own service layer, you have maybe a couple of those different availability zones so that ultimately the data will get there, and we're not gonna have a bottleneck if the broker was to go to down. So you could see this diagram, it can have two or more, basically, we're gonna publish to one of those, and Ignition on the other side will go connect all of them, it will aggregate all that data into one common namespace.

20:02
Kevin McClusky: So then the next step in taking a look at this is if you were to take Ignition scale-out architecture, probably most of you are already familiar with the scale-out architecture and apply it to the cloud. So the scale-out architecture allows you to split up your backend, your IO, from your frontend, your Perspective, your Vision, any visualization that you have there, and this architecture is just showing that right here, so it's basically taking, on the left-hand side, you have the left-hand side, in the AWS cloud there, you have the availability zones of A and B, and you have a single server that is doing the MQTT that is taking the tags it's putting those tags in place, making those tags available for the frontend gateways, and the frontend gateways are on the right-hand side there, and that is, in this case, a master and a backup right there.

20:53
Kevin McClusky: So we have a couple of different ways to do scale-out. That's one of them that the frontend could have a master and a backup. And so same type of thing, if the master goes down, the backup takes over. If the master comes back up, then you can have it automatically switch back, or you can manually trigger it if you want to. It's up to you in that case. This gives you that separation, so you can have a lot on the frontend, you can have a lot on the backend, and each of those loads is separate, and they talk to each other really seamlessly over the gateway network. Now, if you need more than a single frontend gateway can handle, there are options for that too.

21:29
Travis Cox: Yeah, so we can think of this as a progression, right? We're gonna continue to scale this up, and a lot of times we've customers, they start out with one server, they then moved it to the backend, one backend, and one frontend. We might then add some redundancy in there, and we might then later add more frontend servers because we need to have serve more clients to more people. And so it's really quite easy to do that. So going back here, that frontend is a redundant pair. So only one of them runs at a time. There's two redundant pairs: backend and frontend. So it's just resiliency so that they go. But if you need more than one frontend server, that's gonna be independent frontend servers, independent Ignition servers with the Perspective or Vision, whatever you wanna use for your frontend, and you could put a load-balancer, and in fact, AWS has what's called the elastic load-balancer. Azure has obviously a very similar methodologies here, and now you can get to a place where you can serve out hundreds, if not thousands, depending on how many frontend servers you have, and this is precisely what our demo server does here at Inductive.

22:30
Travis Cox: So if you go to demo.inductiveautomation.com, you're going to a load-balancer. That's where that domain is terminating, behind that we have, I think, three or four now frontend servers that are behind that so that we can have lots of people on a demo project at the same time; however, we got our backend that's processing all the simulation, and we have data coming from our site up there with our building automation data is being sent up there, and this is very much architecture that we're using. And we then not only deploy this within the US regions, we've also deployed this around the world, and there's global accelerators that help get to the right data center based on your location. We're not gonna share that here. There's the way that goes even further, but this is a great way. So just if you're going cloud-native, you want a resilient system, you want a highly available system, you want one that could support lots of people. If you start out this way, at least could just be one frontend, one backend, then you could easily add on to this as you go forward. It's incredibly easy to do that, and you can keep scaling out as you look at the need and the performance that you have on there.

23:36
Kevin McClusky: And one quick note on that regional scaling, so Travis mentioned that our demo servers are in several different places around the world. We have those and about a third of the world each, so we don't have those one over here and one over in Kansas, and one over in New York. You don't need that. So if you're just covering North America, a single region inside North America is generally fine for that type of thing. If you're covering Europe, a single server-server architecture infrastructure, this type of thing, a single one of these over there is probably fine. You don't need to have a lot of these speckled around the world, and 90% of the cases, just having one of these is all that you actually need to do massively scalable architectures.

24:24 
Travis Cox: Yeah. And ours, we do have it in the Oregon region, so for North America. We have it in Frankfurt for Europe. And going down to even South Africa, and then we have Sydney for Australia and Asia-Pacific over there. Alright, so we're now scaling out, we've got adding that load-balancer. We can add lots of different frontend servers, and I wanted to mention, of course, that all these servers you see up here in the cloud, those are additional. Those are separate licenses of it, but only for the modules that are required on that side. So if I introduce another frontend server, it's just gonna be for Ignition platform and the Perspective Module, and you can keep adding those, and you get unlimited use of that. And your load-balancer will be the one to actually balance that load across all of them, hence the name, but with that, the one thing to consider with load-balancers is make sure you use one that supports sticky sessions. Of course, AWS and Azure, they already have that as part of their thing, but the idea of that is if I make a connection to that load-balancer as a client, I wanna stay on that Ignition server that's behind it for at least some time period, I don't wanna keep switching back and forth because that session has to keep reestablishing.

25:34
Travis Cox: And it would just be like loading every single time. You don't want them to be loading. You wanna just stay that way. So usually recommend about sticky session of a couple of hours, eight hours, maybe a day. And it's super easy to get configured here, and we can really scale this thing out.

25:47
Kevin McClusky: And if your IT is setting up that load-balancer for you, just tell them that. They'll know what sticky sessions are.

25:54
Travis Cox: Okay, so we can go from there even further, and this is where we can... If we have Ignition in the cloud and we just made the architecture smaller, but imagine it could be as big as we had before, but if we have Ignition in cloud, we've got data flowing into it, we're using it, we're making it available to people and through the application. There's other things that we can do with that data, right? And one of the first things that a lot of people have taken advantage of is the injection modules that we have four different cloud services. So AWS, we've got AWS Cloud Injector which can put data into Kinesis Streams or DynamoDB, and that's what you're seeing in this diagram here, and from there, you can go into ML, you can go into streaming analytics, you could do a lot of different things that Amazon services provide. Now, you have to obviously configure that, it's not part of Ignition at that point, but we're just sending that data off into that. And if you go look at Azure, very similar services, going to IoT hubs or event hubs where you may wanna move it into different places there. And so it just can allow to kind of democratize that data, right, get it into more places. So this is kind of some people like these services. We're seeing a lot more traction though, with the next one.

27:08
Kevin McClusky: Yeah, and what this looks like is taking Sparkplug directly into a service called IoT Core over there and then being able to subscribe. So IoT Core is going to have an MQTT broker that's built-in. You're gonna be able to send that Sparkplug data in there. MQTT Engine can subscribe from Ignition, as you see on the bottom there, but then you can also have other services tap straight into that stream. And one of the big services that folks are looking at are the AWS IoT SiteWise that you see there or Azure Digital Twins. And so these are two services that these companies have started putting out in place to try to help enable manufacturing and to try to help provide a way for their other services to tap into manufacturing data. They finally realized that manufacturing data is different from IT data. It looks different, it's timestamped, it has quality codes, it has important pieces, and it has structure in a way that you're going to have a motor, and that motor is gonna be an object out there that you wanna do something with.

28:13
Kevin McClusky: In Ignition, you define those as data types. And then you can turn this on so that it's going to publish that out from your Perspective dashboards. You'll will be able to see those same data types in that same data and that structure inside MQTT Eengine inside your Ignition Designer there in the cloud, and then you can also see the exact same thing in IoT SiteWise, pulls over those models, streams over the data so that you can feed that into the rest of the AWS ecosystem, and on Azure it's Digital Twin on that side.

28:43
Travis Cox: And you have data that's stored against context, and that allows to go to ML and analytics a lot better. If you guys didn't see Arlen Nipper's presentation here on the stage before our session, definitely go back and watch the pre-record. He did a live demonstration of this, and there is a lot of power to how we can unlock a lot of opportunity, a lot of new doors for what you can do as you go forward. So again, easily you start putting in Ignition in the cloud, just to solve some challenges you have for yourself, leverage Ignition there, you can then go a lot further. And these are all just drop-in modules, configurations, no coding here with these things, makes it really, really easy to get going. So along with that, I wanted to talk about when we go to the cloud, I'm sure a lot of you, it could seem like a little daunting exercise to go into AWS or Azure and learn all the services, learn all the things, they have a lot of stuff. Trust me. We went through the certification process. We are certified. However, there is... It's a lot of training, understanding of those systems. I understand what virtual private cloud networks are, and being able to get the firewalls and security groups and getting the compute, getting load-balancers set up, all these things are a bit tricky.

29:55
Travis Cox: So these cloud providers provide infrastructure, the ability for us to write infrastructure-as-a-code, and that is a way of just provisioning your infrastructure. So all that Ignition stuff that we showed up there in the cloud, we can provision that through simple configuration files that can automatically generate that infrastructure for you. And in AWS, they call it CloudFormation, I'll show a small demo of this in a moment, and in Azure, they have Azure Resource Manager but allows you to apply best practice, allows us as a vendor to give you templates that you can use, that already have all these things in place, it allows for eliminating a lot of mistakes, and you can provision the right thing every single time that you want. So with that, you could also safely tear down the entire stack, and everything would have been removed. And so with that, you gotta remember all the different pieces that make it up to go and move those individually.

30:46
Travis Cox: So one of the things that we are doing, and we're in the middle of this, I was hoping to have it ready for the conference, but it was on me, I didn't quite get it completed, but we are working with AWS, and we'll do the same thing in Azure. We are working with Quick Starts, which is... It's basically exposing their confirmation templates, but vendors can actually put a page up that talks about Ignition, and then we can have example templates in there to spin up Ignition in a standalone environment, spin it up in a clustered environment. How many backend servers do you want? How many frontend servers do you want? So you just answer questions, and it will spin it up. Of course, you gotta pay for the services that you're using in the cloud but ultimately makes it really, really easy to get that up. And our Quick Starts not only get Ignition going but pre-configuring it as well, so that database connections, alarm journals, gateway, network connections, all of these things are already going. So...

31:43
Kevin McClusky: As Travis gets that demo going, one of the tricky things to do if you're not an AWS expert is getting these services right, so if you have things in different subnets if you have different pieces and different availability zones, how do those route together, how do those get going? And this is going to be a cool demo where you can see that you don't have to be a cloud expert to be able to spin up some of these architectures we were just talking about.

32:05 
Travis Cox: Yeah, I'll make this a little bigger here. But the Quick Starts, that's there... Oops... If I can type up here, nope, not Quick Sight... Boy, I'm failing typing over here, but Quick Starts, you'll see Ignition here soon enough, and I'm just gonna pick one of these as an example, but the idea is that I'll explain how you could deploy the different ideas for deploying and there will be a link that will then take you right over to CloudFormation in particular, that will load up a template that we've already defined, that we've already built in there. So to simulate, to show you that, I can just upload the template myself, but I can go in. It'll be creating a new stack, there will be a template file, so I'm gonna use our redundant demos, I'm gonna get an Ignition redundant system in the cloud really easily set up, and all we gotta do is just answer some questions.

33:00 
Travis Cox: So this one is. I’m adding to an existing infrastructure. There's another one that will sort of spin up the entire infrastructure for you, but basically... Let me just answer a couple of questions, specify some things where it's going. And if you want to spin up a database, we can specify the username and passwords. We're gonna agree to Ignition's ISLA in here, put the Ignition password, and I don't think it'll finish in time here for us to actually show the final effect, but ultimately, once I create that stack, we're gonna see this thing, and I'll give it a couple seconds for, you see more progress on it. But this thing is going off, and now building all the things that we need to get Ignition, a primary and backup server in the cloud, up and running, connected already sets redundant, have a database connection involved, all the things, all the security settings in place, and it's just done, and you don't have to do anything.

33:58
Travis Cox: Now, when Carl, in the keynote this morning, mentioned that we have the Cloud Edition of Ignition coming. When that comes, that makes us even more powerful because you can go use these templates, and you can spin up Ignition, and at that point, you're actually paying for the service as you need it. If you tear it down, you're no longer paying for it within your AWS or Azure environment.

34:23
Kevin McClusky: Right.

34:23
Travis Cox: So it's really exciting. The opportunities that it's gonna have to make this thing just even easier to deploy these solutions clouds, one-click deployment, really, it's all that we're trying to talk about here.

34:33 
Kevin McClusky: If you've ever gone through and set these things up yourself, you know that none of them are terribly difficult if you know what you're doing, but each one takes some time, right? And so we're saving a lot of time those creating progress, create complete, you can see if we scroll down here as well, there's all sorts of things that it's doing in order to get these set up and some fancy things that is doing with Ignition to set up that gateway network connection as it goes in, as it creates the... Installs Ignition on these systems automatically and sets up that configuration, sets up the certificates that are needed to go back and forth, all of those things, invisible behind the scenes for you.

35:14
Travis Cox: Yeah, it takes a few minutes for everything to get spun out, but for sake of time, I think we'll go on, you get the idea. At the end of the day, once this thing is done, what it would give us is our outputs, and the outputs would have been here's the IP address to Ignition. So you just simply go there and just now experience, it's there, you start going, open the designer and start making it your own at that point.

35:40
Kevin McClusky: I know we've got a couple more slides, and we've got about 10 minutes, and we've got probably some time for Q&A. So we might be done in the next 10 minutes.

35:46 
Travis Cox: Yeah, we might come back to... There we go. But this is an effort that we're really excited about because we've helped customers deploy in the cloud in these ways, and we've shared our expertise with everybody, but we want people who especially aren't... They don't know all the details of AWS and Azure to be able to deploy this. Applying all the security best practices that Kevin was talking about and to get things pretty configured and ready to go, so you don't have to worry about all that stuff, just worry about the application you need to put on the system.

36:15
Kevin McClusky: Just another way we're trying to make things easier for you.

36:19
Travis Cox: Alright, so that then brings us to... Kevin, you want to talk about platform-as-a-service here a little bit?

36:22
Kevin McClusky: Sure, yeah. So it was Carl in the keynote who actually mentioned that we're not doing software-as-a-service, right? So Ignition Cloud isn't software-as-a-service. We're not spinning up Ignition and maintaining it for you where basically Ignition Cloud Edition is going to let you spin up your own copy of it, and then you manage that. You run it as yours, right? Platform-as-a-service is a little bit different idea than that. The idea is that is complete development and deployment platform inside the cloud and so designed to support the entire software lifecycle, testing, building, deploying, managing, updating the different pieces there. So the Ignition platform, if you spin it up yourself, you're maintaining that yourself. If somebody else were to spin it up for you and just give you that platform, that's more of a platform-as-a-service type of architecture.

37:18
Travis Cox: And that could be, if you don't want to spin up in your cloud environment, you would rather have somebody else manage it for you. Make sure there's uptime on this. Have all these things behind the things and their well-architected framework already set up for you. And basically, it's a service to you that would make your life a lot easier. Now, we don't... We're not providing this platform-as-a-service here at Inductive Automation. We just provide the product. And with having the Cloud Edition, all that's going to make, I think, enable this a lot more. But there are companies out there who are providing a service to give this platform-as-a-service so that you can literally get Ignition spun up and in whatever way that you want with all of these best practices and security things in place. Especially with like things getting to like SOC 2 compliance, it's important to be able to do that.

38:03
Travis Cox: So I would encourage all of you guys to take a look at a session that we're having tomorrow called “Git Serious: Hybrid Cloud Deployment with DevOps” with 4IR Solutions. They're going to talk about how you can leverage a platform-as-a-service and talk about hybrid-cloud, edge orchestration, DevOps in particular. How to do like development to testing to production systems, identity management, time series data, and monitoring, and disaster recovery. All things that platform-as-a-services provide make that part a lot easier. Check it out. You can see more about this. So if you want to deploy Ignition into your environment today, definitely do it. But if you want to leverage a service like that, they do exist, so.

38:49
Kevin McClusky: They're a company we've been working with for a while too, so yeah, it'll be a fun session if you get a chance. Definitely take a look. Check it out.

38:56
Travis Cox: Yeah, so hopefully, you got a good sense of some of the ways that you can deploy it, some of the things that are possible. We get really excited about the opportunities that are there. It's helped us do a lot of things from our demo project and even things that we use within Inductive Automation. So hopefully, you found it useful here, but thank you, and we'll open up to your questions.

39:25
Kevin McClusky: So we see a couple of hands. There's a mic runner who's coming around right now, so if she hands the mic, go ahead and speak.

39:29
Audience Member 1: Hey guys, thanks a lot for that presentation. I had a quick question. Actually, I had two questions, but I'll just stick with one real quick. You said that if you have spun up a single Ignition server and as you've grown, you've outgrown just running it on a single server, you wanna move to a multiple approach, that it's really easy, and you can do that. It's been my experience that there's a little bit more complication behind the scenes there. Do you all have a document, or best practices, or step-by-step guide for how to move from a single Ignition server to a frontend/backend combo?

40:08
Travis Cox: So there was one ace in the hole that we have with our diagram, which was we're using MQTT first and foremost up there because if you have a single server, the biggest thing in terms of being able to split it out, the biggest complication is typically the tag paths, right? Like if you're not using MQTT, if you have tag providers and tag paths and you try, and especially if it was all in a default one, it'd be very difficult to split those out and extend on to that, in particular though, with MQTT you get a common namespace, all your screens and whatnot are on using those fully qualified tag paths, so it's a lot easier to then break out the frontend piece, the frontend away from that backend there, and then even introduce more of those going into the future, but that, I mean, that's... People who try to do it from one on-premise with one server with a default, and then they wanna add more IO servers, it can be a challenge. You may have to reorganize your tag structures and use those fully qualified tag paths. Anything you wanna add to that?

41:06 
Kevin McClusky: Uhh, no.

41:08
Audience Member 1: So no document? No document on how to do that?

41:11
Travis Cox: Oh, the document, right. We don't have a document right now. In terms of how to split out properly. It is one that we are wanting to do, has been requested by quite a few people, so hopefully, stay tuned. We're gonna be working on that. Give you some... Give you some of those small detail pointers behind the scenes, right? And a process by which you could do it. I could tell you quickly that we typically use... When we do a scale, when we separate out the server that you have right now, keep that the backend, it's much easier to move off the frontend pieces of that than it is to actually move the backend pieces over. That's one of the biggest ways to start out with that, but then you gotta consider a lot of other little details that the document would help, like if your screen was doing a system at OPC function call, right? And you move the frontend over here, that OPC server doesn't have those tags unless you're pointing back to the original OPC server, so there are little gotchas depending how you build your application, which we hope to put in that document, so you'd know all the little details.

42:16 
Kevin McClusky: Right, and for things like that, if you have the OPC read directly, then you can pipe that through gateway network scripting, so system utils, send message and have that be a remote call for those types of things, so the document can cover the best options for each one of those different things that you might need to consider individually.

42:35
Travis Cox: Yeah, it just really understanding what actually is backend and what actually is frontend and being able to separate those two. One quick recommendation, by the way, when you're doing... When you're building projects, I'd like people ask, “How do you organize projects itself?” Put things like transaction groups or SFCs, things are like logic engine type functions in their own dedicated projects, because if you have the application, it's like Vision or Perspective, keep that by itself, 'cause then you know it's purely that project if you export it is purely just the visualization, it's not additional things that you forgot about, like your timer scripts the top or tag change scripts that happen to be in there that are part of that project, because then you move that overnight, you've got two of them running you don't realize it or something like that.

43:20
Kevin McClusky: Alright, other questions? I think we've got time for one or two.

43:25
Audience Member 2: Two questions. One is, what does licensing model look like for cloud architecture? Is it different than on-premise architecture? And then this pre-configuration step really interests me. I'd like to use that for my non-cloud systems. Do you have a way of doing that?

43:42
Kevin McClusky: The licensing looks... As of right now, it looks exactly the same as on-premise licensing; however, if you're using scale-out architectures, as we mentioned, you're only on the backend gateways. You're only licensing the things that you need there, which is going to be some of the data and Tag Historian, and SQL Bridge and things like that. And on the frontend, you're only licensing the platform and Perspective or Vision, but the licensing, other than that, it's the standard perpetual licenses, so each one of those servers that you see, if you're familiar with Ignition licensing already, just run it through what your knowledge is of how it works on-premise, it's the same in the cloud.

44:20
Kevin McClusky: When Ignition Cloud Edition comes out, that's when we're looking at the possibility of making it so that you can spin it up as part of the AWS marketplace, for example, or the Azure marketplace, or the container registries there, so that you can pay by the hour, pay by the minute, pay by the day, whatever it happens to be. So if you wanna spin something up and you just wanna test something out, right? You just wanna see if this is gonna work, spin it up for a day, have some sort of a demo system, and then take it back down or spin it up for a month, or spin it up for six months, or you have companies that you're working with that you're trying to sell your stuff too, and you want them to basically pay for their infrastructure on a monthly basis, you would be able to do that type of thing. So that's one of the things we're excited about with Cloud Edition.

45:08 
Travis Cox: And to be clear too, like now we're buying licenses from us. If you're gonna deploy the cloud, you're buying a perpetual license today, and with the Cloud Edition, you would simply just use your Amazon or Azure spend. It's gonna go through their marketplaces and you're paying through them and getting access to our Ignition, so it opens a lot of cool opportunities with that.

45:29
Kevin McClusky: And there was a second question there, right?

45:34
Audience Member 2: The pre-configuration process.

45:36 
Kevin McClusky: How do you get access to that...

45:38
Travis Cox: Ah, so the Quick Starts. We're gonna be publishing the Quick Starts pretty soon...

45:40
Audience Member 2: Independent of the cloud, can we do that today?.

45:44
Travis Cox: Oh yeah, we have the CloudFormation templates that we could provide that we've written, so you could contact us. We can make that available.

45:50
Kevin McClusky: Yeah, the things that we were showing are for AWS specifically, so you can load those in, those CloudFormation templates, we'll send them over to you, you can pull it into your own AWS infrastructure. Yeah.

46:00
Travis Cox: You don't need to have... It doesn't need to have the Quick Starts there. Yeah, we can do it in both Azure and AWS. Yeah. Yeah, good question. There is one more. Maybe one more, and then we'll wrap it up here.

46:12
Audience Member 3: Thanks. You mentioned Amazon and Azure quite a bit. Were you planning on having Ignition Cloud Edition function with Google?

46:24
Kevin McClusky: Good question. It is the third one on our list. The amount of demand that we've had for Google Compute Engine and the whole Google Cloud Platform hasn't been high, frankly. So it's AWS and Azure right up here, and then Google is kind of down here. We like Google, and we're happy with the things that they have, and I have a server of my own running inside Google Compute Engine. Yeah. We would love to support that at some point in the future. It's just definite... It's not the top two of our targets right now...

47:00
Travis Cox: At start. At start.

47:00 
Kevin McClusky: Yeah, yeah, at start. So when we first release Ignition Cloud Edition, I'm imagining AWS and maybe Azure at the same time, and then some point in the future, we'd love to... I would love to have Google Cloud Platform added and support it as well.

47:18
Travis Cox: Alright, well, that... Sorry if we didn't get to all your questions, but if you wanna come up to us afterwards here, great, but we appreciate your time. Thank you very much.