Hybrid Cloud

Part 15 of Data Communication for Industrial IoT

A hybrid cloud is a combination of in-house and cloud functionality in the same system.  For industrial applications, this usually means the use of a public cloud for remote access, and a locally managed, private “cloud” for interaction among application within the plant.

A public cloud is a service like SkkyHub, Azure or GE Predix that is hosted by a separate company, whose services are available to the general public.  It provides a point of contact for a remote user to access the data collected from the industrial system.  Depending on the cloud service it might also provide redistribution, storage, analysis, alerts and other processing on the data.

I put private “cloud” in quotes because the local server does not need to be a cloud service in the sense of on-demand resource balancing on a distributed collection of virtual machines.  Usually it is an aggregation and distribution point for data from the local network that allows various plant subsystems to communicate with one another.  It may fulfill the same communication role as a cloud server without the implied implementation of a cloud service.

A private cloud is run by the company that uses it, often on company hardware at a company location.  It might be, for example, be run inside the control system network, in a DMZ between different plant locations or between the management offices and the shop floor.  In terms of security and reliability, one key difference is that data communications for the private cloud typically run across the company network, while for the public cloud communications go across the Internet.

A Very Good Approach

There are several reasons why a hybrid cloud might be the best approach to data communications for the Industrial IoT.  First, a good hybrid cloud system can provide separate data paths for in-house applications and publicly available services.  Implemented correctly, this can mean exposing lower-level data to plant engineers and managers, while providing access to higher-level data like accumulated statistics for the IT department, or aggregated supply levels to raw materials vendors.  This kind of data separability, where everyone gets just the data they need, is a hallmark of a secure system.

In a similar way, running separate servers for in-plant and public cloud keeps the critical data paths on the LAN where higher data rates and more bandwidth are typically possible.  It also means that if the Internet connection goes down, the plant can continue to function unimpeded.  To achieve this, the design would need to ensure that none of the primary control necessary to run the plant is in the public cloud.  And if the system is designed correctly, when the network comes back the data should continue to flow to remote users via the public cloud, using the latest values.

Despite these advantages, there are a few practical considerations.  Costs can be somewhat higher, as you are effectively running two systems.  That may not be a huge consideration since you probably need the communication infrastructure within your plant in any case.  The requirement then becomes ensuring that your in-plant communication software can interoperate with your choice of public cloud provider.  A software or hardware protocol gateway may be all you need to act as a private “cloud” server.

Avoid Cloud Dependencies

Some cloud service companies may not encourage a hybrid cloud solution just due to their business model.  For example, consider a typical REST-based cloud service.  These services offer the ability to transmit data via HTTP directly from a sensor or embedded device to the cloud server.  However, if that sensor needs to be incorporated into a larger control system, sending the data to a cloud service and then back to the control system is both impractical and fragile.  Yet the cloud provider will not let you run a copy of their server software in your own network, as that would eliminate their service revenue.

This brings up an important requirement when selecting an IIoT cloud provider – a good IIoT device should be equally comfortable connecting to a local system or a cloud system.  The cloud service provider should formally support local receipt of data using the same protocol they use in the public cloud, through cloud-compatible software or hardware, so that the device can transmit either to the local system or the public cloud with just a configuration change.  Local cloud-compatible servers should support the protocols that the plant uses, like OPC, Modbus, etc.

When a hybrid cloud system is implemented correctly it can eliminate dependencies on the Internet connection, yet still provide all of the remote accessibility benefits of the cloud.  It can make it possible to re-purpose devices between the cloud and the local system trivially, and provide for graceful degradation in the event of a network failure by maintaining local communication and control even though remote visibility has been lost.  When the purpose of the system is process control, you don’t want to lose control of your process.

Continue reading, or go back to Table of Contents

AWS Outage Calls Attention to Hybrid Cloud

At the end of February Amazon Web Services (AWS) slowed to a crawl for about four hours, causing a major loss of service for hundreds of thousands of websites in North America.  Sites with videos, images, and data files stored on the AWS cloud server suddenly lost much or all of their content, and/or shut down altogether.

After the initial weeping, moaning, and outrage died down, a lively discussion ensued among IT technicians, managers, and concerned citizens on to how to deal with this kind of incident in the future.  The comment section on a story at The Register gives a sample of the kinds of ideas put forward, and there is a clear consensus on a number of them.  Most experts agree that the occasional service outage is one of the inherent risks of using the Internet and cloud services, and that if you need high reliability for your data, you’d better have some kind of redundant or backup solution.

There are normal, accepted ways of building redundancy into a data communications system, including IoT and cloud applications.  One approach mentioned frequently is “hybrid cloud“, a public and a private cloud running simultaneously.  A public cloud is service offered to anyone, typically by a company for paying customers, like AWS.  A private cloud is a service operated and maintained by an individual or company for its own internal use.  To achieve redundancy for AWS in this past outage, a private cloud would have been up and running with a copy of all the company’s data and software, the same as AWS, but just not online.  When AWS stopped serving data, the system would have automatically switched to the private cloud, and someone using the website would not even have noticed.

This is how it works in theory, but building and maintaining a hybrid cloud system that can perform this kind of redundant operation is no small task.  Depending on the level of data and functional replication, in addition to the speed of error detection and  switch-over capability, the hybrid site could cost as much, or even more than the cloud site.  Companies considering such an option would need to do a cost/benefit analysis, based on their specific circumstances.

For Industrial IoT applications a hybrid cloud approach to redundancy may be useful.  Although low-level process control systems should typically not be dependant on the Internet or cloud services, companies who use the IIoT for process monitoring, data collection, or high-level control applications may find it worthwhile to maintain a hybrid cloud.

Skkynet’s SkkyHub service lends itself particularly well to hybrid cloud solutions.  It is possible, and not very difficult, to run a replica system on an in-house server, using the DataHub. Although the DataHub is different from SkkyHub in some respects, for the primary task of data connectivity the two function in an equivalent way.  Readers interested in trying this out are encouraged to contact Cogent for technical tips to ensure a secure and robust implementation.