Travis: So, that's a great question. So, with Ignition, we have redundancy built in, so that you have a two-node system. If one fails, the other will take over automatically. That would mean, for redundancy, especially around I/O, that you have to have two either different embedded computers, or two different areas where you can run the master and the backup. Now, that means double the hardware. Of course, there's extra licensing costs and things like that. And ultimately, it's something that people are trying to avoid as much as possible.

This is one of the areas where containerization gives us a huge benefit, in that, if you have the right infrastructure in place, if you have multiple nodes where we could run these containers, then it is possible where, with these orchestration platforms, they could be watching that, and seeing if that system is up, or if that service is actually running. And if it's not, we can move it around to a different resource.

So, Ignition doesn't support high availability per se, especially from the I/O standpoint directly, but if we have multiple machines, we can kind of get that highly-available architecture. We can move things around. Now, you might have some bit of downtime, as you're moving your service to another machine, but ultimately, you get to leverage those resources more efficiently.

That's one of the big benefits that we're seeing a lot of customers taking advantage of, is that they can deploy minimal amounts of compute out there to handle all the services, and failovers that may happen as well, or these different real-life scenarios, connectivity issues, and so on. So, it's pretty exciting to be able to do that, and do it in a way where then you also get notified by the orchestrator, "Hey, these things are happening," you get notifications. You can check the status of that. And all that's managed from a central location, so, while Ignition doesn't support high availability directly, we can get to a more highly available architecture with this kind of technology.

Curt: That's a great question. Digi ConnectCore actually runs a different version of Linux. My email is on the screen if you want to reach out. You can also connect with our OEM teams supporting ConnectCore by going to our Contact Us page or our Support page, and we can have a discussion about the possibilities of running containers within that environment. I don't know offhand, and I don't think I have anybody on the phone that can cover that, but we would be happy to follow up on that.

Travis: Again, we’ll have to follow up with the OEM team from Digi, and get somebody that can answer that question for you. Please reach out via our contact us page or our Support page.

Nate: So, yes, but then you're managing the container locally on the device. The device itself has an admin CLI, and a local web UI, where you can configure the network settings for the container and load the container onto the device. But then the complexity comes in when you're managing multiple devices and multiple sites and fleets remotely. It becomes a challenge, then, to always have that direct access to it, and a tedious task to update the container in the field, when you're doing that all on a per-device basis. Whereas the power of Digi Remote Manager is that it allows you to do that in a fleet-wide template setting, so you can have the configuration set up in that central management portal. But, again, there are ways to do it locally as well. And today, with Digi 360, Digi Remote Manager is included in your Digi device purchase.

Mo: Yeah, I'll add to that a little bit on the INS side. INS has done it in both forms. So, still found that it was still intuitive, and still very functional to do if you're doing it standalone. And then, as a secondary test, we removed that, and then we came back in and used the Remote Manager tools. Again, I'll say I enjoyed the intuitiveness of the remote management tools. It was very, very efficient for us to use.

Travis: Yeah, I have one more comment, which is that the real beauty around this technology is these remote managers, these orchestrations, where we can manage our deployments, and check everything from that central location. Because, if you think about how we would deploy this architecture, we literally can drop ship a device, like Digi IX40, out to a site, and have somebody simply just get it plugged in, power, and then we can really control what, from a central location, what gets pushed out there, from Ignition or other services that you may want to work with.

It makes that very easy to manage, especially if you have lots of these out there, these fleets, because then you can do lots of different tasks, all from a central place, and really keep things consistent across the board, which is really important for a lot of people. So I just want to mention that. This kind of architecture is really becoming more prevalent, and especially getting data to the cloud, and leveraging remote locations to get the data efficiently. It's really exciting, how quick and easy it is, and the benefits you can get, the ROI you can get, from doing this. Not to mention that later on, if you want to add additional tools or services, it's a matter of just deploying something new. So, I just wanted to add that comment.

Mo: Yeah, I'm going to tack on to that a little bit, Travis. We have several customers who, because they have field operations technicians, may get called in the middle of the night, in order to be able to go replace something that maybe had a large electrical hit or something like that. When you're rolling a truck at 2:00 in the morning, to go replace communication devices in the field, you know… let's take it from a hardware perspective. Having to replace multiple devices is very tedious and cumbersome, because there are different ways to have to replace each one of them, configure each one of them, and then get that back online, and then include the application, rebuild the application, and get a project backup in place.

Here, if you have your pre-configured Digi, and it just has its capability to attach to your private cellular network, or to your static APN, where you have your own remote... or a private API, just by having that join the network, and then logging into your remote manager, that allows the field technician to just quickly go in and put the new device in place, it boots up, and connects to the network. And now you can use a remote manager tool to have other people do the checks and balances, push the containers, get the application up and running, and it takes a lot of that tedious load off the field technician.

That allows consistency in knowing that wherever you push it to, if you organize your containers right, and you manage your containerization management tools right, through the remote manager, it's very easy to recognize what you're pushing to a site, and then make sure the application's up and running, and do a quick check and balance, from the remote manager, that allows you to get a status of it when it's back up and running. So, when you stop and think about the power of those, A, it's going to help your field technicians, and B, it's going to get you back online faster, and with more consistency.

Curt: We have customers today using Digi Remote Manager with tens of thousands of devices. So, this is new containers, it really shouldn't make any difference. Digi RM should be able to scale in the same fashion supporting containers as any other type of application.

Mo: So, I've kind of highlighted that in a few different areas, but I would say the use, the ease of use of the containerization that Travis has touched on, I really enjoyed, again, Digi's intuitiveness of being able to configure and manage that. And then, with Remote Manager being able to categorize things in a way that helps us deploy, and see how we're helping the customers kind of think through that process, and being able to use Remote Manager in a way to manage, entire regional fleets, and the subset underneath that, and see the devices underneath it. To be able to have that intuitiveness takes the complexity out of it, and lets you kind of really see the way you're configured as a company, and all your remote devices the way you want to see it.

So, that was one of the things that I liked about the Digi platform and the way we're doing it, because a lot of customers oftentimes will not think about the remote management, and then how they're structuring the way that they're viewing their devices, and the way the containers are deployed.

When you start scaling to a large quantity, kind of what that question was that Curt answered earlier, if you have thousands of devices out there, you know, 10 devices is probably easy to see in a single pane of glass, but as you start to organize things, you have to really stretch it out more, because if you have thousands, well, now you're having to really think through that a little bit more.

By being able to have something like Digi Remote Manager, where you can very easily configure your containers, but also then visualize how they look and feel, and being able to go in and region by region, look at them, I felt like it was a really good way to be able to see the way things were deployed, and help customers really think about, like, “how are we going to support this, and how is our support team going to view all the different devices we have out there, and quickly navigate them, to troubleshoot?”

And then, not only that, be able to get alerts. If you can set alerts on things, and know when something goes down or is not available, you're more proactive than reactive, in that sense. And the fact that you can see resource management and things like that, it kind of helps you to realize, because sometimes people will go out and, you're doing expansions and things, and you may not be necessarily in tune to following what's happening with the resources. So, as you add additional tags, you bring on a new area where your Digi's out there monitoring in, say, maybe 5, 1000, 2000 tags, and you start to add new sections, well, now you can sit there and watch the resource allocation that's going on as you increase tag counts and things like that on expansions, and then set your criteria in order to manage that, and make sure you're not creeping over that level where resources might be an issue.

Mo: So, that would be in regards to the container deployment itself, or more specific to the data store and forward? If I took it from both approaches, the containerization is usually...and Travis, I'll have you chime in here too with me on this. I'll start with containerization. It's usually easier to deploy containers, because they're usually lighter-weight, so getting them over struggling networks with those configurations is typically a better approach, so that you can push the container out there. If your coverage is really spotty, being able to go and then take the container — which you can very easily give to people, because you're not having to do a full install and things like that — you can instructionalize, and use your field operations crew to go in and show them how if you need to add on a container manually, through, say, a backup device, containerization is a great method.

If you're using something like Digi, that has the intuitive interface, and you documented it well with an SOP, again, that container's lightweight, easy for them to get on, use the local web interface, and then get that container added to that device pretty quickly, and have it back up and talking. And then again, if you do connect it to Digi Remote Manager at that point, then you can still see that, remotely, that you've got it back online.

From a store-and-forward standpoint, using things like Ignition Edge with MQTT Sparkplug, we've noticed that if you use some of the cool built-in features, like aliasing and things like that, you get the benefits of what the Sparkplug protocol brings to that, with MQTT, and that is a smaller footprint on your packet traffic, which allows you to take struggling cellular networks, and get throughput that you normally wouldn't get on a traditional polling model, with a heavier structure on the packet on what you're posting via the Ethernet protocol. So, those are kind of two things I have for that, and then plus you also get the store-and-forward capabilities with the Ignition Edge and the MQTT protocol.

Travis: Yeah, I think it's important to note here that this is designed for this scenario, where the Remote Manager is disconnected. I mean, the idea of that is to help manage it, and do initial deployments, and see what's happening over time. I mean, you would know, via Remote Manager, that you have a device that's disconnected. And so, maybe you can look into that, right, through alarms and notifications, to say, "Are we having weather issues? Why is it disconnected?" But, during that, your device, your containers, will still be running, and still be functioning the way that you expect them to run. As Mo mentioned, data collection, store and forward, all that's happening there while it's in that state. With Ignition Edge, you use the panel, which is the local HMI, so they can open up a local display, in the case where they need that fallback in this kind of situation.

So, it is very much designed for the scenario, but once that connectivity is restored, data gets pushed through, and all of a sudden, now you can, of course, manage that from your Remote Manager side. Ultimately, with Remote Manager, if you do your job right, you're not having to do a whole lot of work there, right? It's only when things that you want to upgrade, or if you want to move things around, or if something happens where you then have to do some additional tasks once that thing's back online, that is possible. So, I guess from my standpoint, it's designed for this, and you get the best of both worlds. The classic way is having to drive out to a site, to have to do management. It's a non-starter these days, right? It's a waste of resources and time. This is a way to really drastically reduce that.

Travis: Yeah. So, we talked about Ignition Edge here in the presentation today. But, for us, you could deploy any of the editions we have, whether it's Edge, standard Ignition, for people that want to do their home automation, or as maker, it's the same image for all of those. It's just an environment variable to specify what the edition is, if it's Edge or Standard. So, you know, these devices are certified to be able to run Ignition, whatever edition you want, it's just that more people are leveraging Edge because of the license fee being a lot lower, and there's just more of those distributed out there on these different devices in their network. But there's nothing stopping anybody from running a full Ignition server on prem as well, with this kind of technology.

Mo: I'll add to that a little bit too, Travis, because we actually do have some customers who will put either Edge Panel, or something of that nature on the device, and you had touched on something earlier that our customers use kind of frequently, is that they'll put a diagnostic tool on there, so that if you did have to take a truck, and roll it out there in the middle of the night, they can get online, and open up a Perspective app directly against the Digi device, where it's running a local network, and still see diagnostics coming off that application, confirm that it's talking properly to the local area network, and be able to do diagnostic work off that, while it's still pushing to the cloud. And then if it wasn't pushing to some other edge location, like cloud technology, then they can sit there and do some diagnostic work through that application running on there. So, to that point, it's not just one version that runs in this container live version. You can have multiple ways of configuring your container after the fact, specific to how you want to use that in your Ignition configuration. You can even strip it down and scale it down to specific things with modules and things like that. Once the container's built, you can reuse that container for different purposes. And you might have different flavors of different containers for different setups for your different projects.

Travis: Yeah, this wasn't something that we covered with the demo. But when you are in the Remote Manager, and you're going to deploy a container to a device, you're not only pushing that image out there so that it can run, and you could specify no config, and Ignition will start up from scratch, using all defaults. And it'll be a blank slate you can start. Then somebody can go and build the application.

But you can also deploy it where you are seeding it with that configuration up front. So, let's say, especially, if you're doing disaster recovery, you need to be able to push it out there in the last state that you had. And that typically is pushing out the volume, a backup of the volume as well, that persistent storage.

But we do have environment variables in the Docker container. You also can push a gateway backup in there as well, so that when you do that initial deployment, there can be seeded configuration that's there, ready to go, making, especially if you have a lot of corporate standards or various things you want to push out there, you know, configurations that are standard across all of them, you don't want to be people have to do that manually. So you push it out there initially, and then they go and make their customizations as required. And then from there, it's a persistent storage. Things that are changed, whatever they do in the configuration that's different, that'll be persistent, and they can back that up wherever they need to. It just makes this a lot easier. So, yes, you most certainly can seed the configuration. It's, you know, pretty awesome to be able to do that.

Travis: Yeah. So, this is a great question, definitely a little more technical, but I think it's important to kind of note, in that the example that we showed, the demo that we showed, you had the Ignition Edge running on Digi IX40, as a container, and it was pushing the data from the Modbus connection locally, pushing that data up to the cloud, through MQTT. And that required the MQTT transmission module to be installed in that container for Ignition.

Inductive Automation's official Docker container image does not include the MQTT modules. It includes all of the standard IA modules, but not the Cirrus Link ones. Now, we're working with them going forward, so that we can have official containers that would already have those things up and running. But, fear not. It's not hard. You can easily visit our documentation. There is an easy way to create a derived image off of our base, where you install those additional modules, and then you just have that be part of the config. You push that image down, versus our standard official image that we have. So, with a little bit of work, you could easily do that, and you just do that once, and then you can push it out everywhere you need, and everything would be installed and ready to go, that's required. Again, that's the great thing about this, is that you can create your own derived images that have some customizations that are required to you, and you just do that one time, and you're able to use it. So, pretty exciting technology.