I’m old school and think everything should be on-prem (VM, not physical) when it comes to HMI & SCADA
That’s because you don’t have experience with use cases where this approach isn’t viable. Oil fields, pump stations, wind farms, municipal utilities…anywhere you have nodes that are separated by miles and there is no single “premises” that exists, this is where Cloud applications come in.
Trying to accomplish this with traditional SCADA methods won’t be nearly as secure or reliable. Transmitting things over the internet with 1990s security technology (e.g., no security, which are the vast majority of “traditional” SCADAs) is inviting disaster. Cloud edition gives you functionality with modern security practices. SSL certification, multi-factor authentication, traffic encryption. There’s a whole lot out there in the world of internet security that us “old school” guys don’t have the first clue about, but are incredibly important all the same.
In my experience, the most important consideration when utilizing Cloud Edition, especially when you have a multi-tenant application like my team is working on, is scalability. Something that will work on a tiny single-project edge station will very often annihilate a Cloud server at scale. You have to really consider every single method you use to accomplish what you need to accomplish or else you’ll be a big world of hurt down the road as more tenants move in.
For example, we had a situation where one of our servers was crashing and it turned out that someone had made a script transform on a binding that refreshed every 5 seconds inside of a template. That script included an alarm journal query, which is a pretty “expensive” scripting method as it is. When we had just a handful of tenants, it wasn’t a problem. But when we had 50, that means 50 alarm journal queries were happening every single second, per perspective session. So if 10 sessions were open, that meant 500 alarm journal queries per second. We ended up moving the script from the view template to a gateway timer script and changed it so that it would write its results to tags instead. Since it became a gateway timer script, that meant only one instance of the script would run no matter how many sessions were open, because each template would just read the tag the script populated instead. That’s just one example of something that’s typically “discouraged but tolerated” (using a script transform on a binding) being an absolutely unworkable solution at scale.
In order to use Cloud, imo, the most important thing is really understanding where to write your scripts and why. You need to really plan out and optimize everything.