You have a lot of cloud-based VTScada systems in your area and had some recent experience using cloud-based systems for online training. Can you tell us what people mean when they talk about cloud computing?
Dan Naughton: This topic falls into two buckets. One is a generic definition of cloud computing. This means you have a server you can rent from cloud-computing providers, such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud. There are also second-tier providers that rent servers. The second definition relates to our industry, namely Supervisory Control and Data Acquisition (SCADA). It involves having your monitoring and control application running on one or more of those cloud systems.
Chris: What's the advantage of the cloud to having one or more SCADA servers onsite?
In addition, you're not as dependent on Internet connections to your sites. If connections are down, your cloud service will still run. Also, if you have many remote users accessing the system, a cloud-based server works better than all those Thin Clients trying to connect to a facility where the Internet may not be as reliable as you’d prefer.
Chris: What, if anything, sets cloud providers apart? Why choose one over another?
Dan: While I’m not an authority on these companies, I know that lower-cost providers, like the ones I use, are bare bones. Companies like Amazon have more to offer. You can rent entire networks of different servers. They have app stores where you can add products like firewalls, network switches and load balancers.
Also, if you deploy giant applications with tens of thousands of servers, bigger companies can automate the process. But in the SCADA world, it's usually a couple of servers, so those automation tools may be more trouble than they're worth because of their steep learning curve.
Chris: If your critical system can't ever go offline, would it make sense to have servers with more than one provider?
Dan: The more diversified your system is, the better. However, uptime for the major providers is so good that this isn't necessary. There’s a greater risk of doing something wrong when trying to match up servers across platforms, and less risk that Amazon will have a hiccup that takes their whole system down.
Chris: What about hybrid systems where you have one or more servers onsite and one or more servers in the cloud?
Dan: You can have a public cloud, which links Amazon or Google server you're renting to a private server at your facility, where you have a virtualized server rack. I think they coined the term “hybrid” for this type of setup.
Chris: Since you brought them up, can you describe virtualized servers and their relationship to the cloud?
Dan: In general, every cloud computer is virtualized. Everyone knows, if you buy a computer without an operating system, you'll need to install one—typically Windows. When you're done, there will be only one version of Windows running on that computer. If your data center had 10 physical servers, they’d only have 10 instances of Windows they could resell.
But if you look at the Task Manager for one of those servers, you’d see it's crawling along at like 1% of its usage. Most of its services are almost idle. A virtualized system takes advantage of that. Instead of Windows, for example, you could install a VMware software tool called a hypervisor, and install multiple virtual machines inside it. You could have 10 instances of Windows running on one server, sharing resources like CPU and memory, and get more utilization out of that hardware.
Chris: Our customers can find our recommended specifications for virtualized servers on our website. What are some “gotchas” to avoid when selecting a virtual machine?
Dan: When buying a virtual machine, you can choose between completely shared resources or completely dedicated resources. For example, I want eight CPU cores dedicated to me. I don’t want to timeshare them with other Windows machines on that server. I want dedicated memory. I want dedicated storage. The closer you get to completely dedicated resources, the more it looks like an old-fashioned hardware server. That's typically what we recommend. The gotcha is it costs more.
SCADA systems typically run at a relatively flat load over extended periods, compared to web servers- with many spikes based on usage. That makes it easier to size the machine because you have a good idea of what resources you'll need to run smoothly. In a cloud system, if you undersize your system and get too close to 100% utilization, you can easily buy more resources. You just reboot and you're good to go. You can't do that with physical hardware.
Chris: If you chose to put your whole SCADA application in the cloud, how would that change the skills needed to manage it?
Dan: In general, you’d need fewer people, but they’d need better skills in areas like networking. Managing a local area network (LAN) is reasonably straightforward. On a cloud server there’s no LAN, and everything is usually on a virtual private network (VPN) into that provider, so everything can connect to each other. If you're familiar with networking, it's straightforward to set up but if you've never done it before, it can be a little daunting.
Chris: One of the biggest reluctances to hosting SCADA on the Internet is perceived vulnerability. How would you compare securing a cloud-based SCADA system with one that’s onsite?
Dan: I think it’s better in the cloud. The local LAN is where most exploits happen. Most ransomware comes via email phishing. Security is better in the cloud because the server is insulated.
The other consideration is reliability. What if network or Internet outages occur at your facility and your cloud provider can't poll your local I/O devices?
Chris: So again, if you're highly mission-critical, it’s important to have a local, on-premise SCADA node to take over.
To learn more about our VTScada software, visit www.VTScada.com. For details of virtualized systems, watch this short documentary:
