Solve IoT data management issues with a ROBO design approach


Data coming in from Internet of Things (IoT) devices is exciting, massive―and potentially crippling. To manage the data effectively and reduce system stress we need to proactively build support mechanisms to make it sustainable. Modern Remote Office Branch Office (ROBO) systems can help.

ROBO is not new. Splitting workloads and tasks across local and centralized networks is common today. But advances have transformed what’s possible in a ROBO model to reduce latency, reduce expensive data transport, and ensure secure connectivity — all critical requirements for embracing IoT and edge computing.

Back in 2017 I made a broad claim that the next major shift in IT would be back toward the distributed edge.  I continue to believe this to be true, but we will need remote processing to avoid having to move massive amounts of data to integrate with centralized enterprise applications. This is one of the biggest problems with remote data: it’s expensive to move. And IoT creates a lot of data.  The other thing to consider is, in almost all situations, local bandwidth is both larger and cheaper compared to what’s available over the wide area.

This is where ROBO industrial design for operations can potentially help.

High level ROBO solution

Figure 1: High level ROBO solution


No matter what the use case, the data from IoT is what creates value.  So, to adequately capture and act on data efficiently, we will need distributed (and decentralized) systems in place.

Key attributes to modern ROBO include:

  • “Single pane of glass” awareness of the hardware infrastructure, integrated with the platform, to avoid support challenges that were common when applications and data were individual islands.
  • Virtualization and workload mobility provide for needed redundancies.
  • Density and growth are more readily accommodated using hyperconverged models that can scale in smaller cost increments.
  • Compression and deduplication at a platform level increase density and decrease storage bandwidth needs.

In a ROBO architecture, the remote systems are placed to access the data generated locally utilizing comparatively inexpensive bandwidth.  The ROBO deployment acts as a local delivery and local gateway for applications and data that is processed in place.

The centralized system becomes the Disaster Recovery (DR) location in the event of catastrophic failure of the applications.  With capability redundancy at the edge, the IoT gateways can operate for a time, independent of the data center computing.

Done well, the WAN transport is less expensive because it is only used for carrying deltas in the remote-to-centralized storage systems.

It may also prove useful to employ Software Defined WAN (SD-WAN) capabilities that enable the local WAN interface to provide a protected edge (firewall, etc.) for the community of IoT devices outside of the organization.

The abstraction layer provided by a mature ROBO system makes it possible for applications to become truly independent of locality.  If it’s within ROBO, an application can potentially run anywhere, locally, centralized or at an alternative distributed site.  The viable options are distributed-to-centralized or distributed-to-mesh equating to one-to-one or one-to-many or many-to-many usage topologies.

Ideally, this type of solution would provide the means to reduce latency between the IoT investment and the backend systems that act on the data, but data compression and deduplication are critical.

The increased value of Hyper-Converged ROBO and IoT combinations

The major goal of ROBO is to overcome current limitations, at future data volumes, using a system that services the location where the data is gathered as well as the point where the data is used.

For example, a distributed ROBO deployment might support end user Virtual Desktop Infrastructure; traditional enterprise application hosting; IoT sensor data ingress and cleanup; and data backup and recovery together — with a centralized DR and application execution area.

In this environment, data backup moves to DR mechanisms while preserving bandwidth through pre-optimized data on the WAN. Local applications run as fast as technology allows and data gathering can take advantage of higher local bandwidths.

This model could enable existing applications and become the testbed for future application development in everything from traditional to containers to function-as-a-service.

ROBO use cases

In light of software-defined networking initiatives at firms such as Arista, network code can be spun up or down as workloads change, with the same code on hardware, in virtualization and within containers. As my colleague Rick Wilhelm phrased it, this environment allows for the “creation and destruction of application environments without drama or remorse.”

In the manufacturing industry, imagine if this rapid application deployment model was based on the speed of the churn on the manufacturing floor and the constant evolution of manufacturing sensors. With neural networks and artificial intelligence guiding the manufacturing process based on new and relevant data, this environment would truly enable agile manufacturing.

In healthcare, a VDI addition to the ROBO model supports both IoT data gathering/cleanup and enhanced software services.  Imagine the healthcare application running locally for latency-sensitive capability combined with centralized DR in the event of a catastrophic failure.  With data deduplication, the transport of the healthcare information, like imaging and client records, could be significantly reduced.

In insurance and banking, with remote offices spread over large geographic areas, consider a local instance of key applications with backup in the data center―all with a regular deployment pattern.  Applications could be created and destroyed on demand as needed to support container and function based digital services, with no loss of data.  You’d have the capability to capture geographically the IoT data based on the remote office distribution points.  Not to mention running the blockchain in off-peak hours, on all available equipment, that will become so important in the future.

I would also imagine that the retail industry could take advantage of low latency local applications tied to protected backend systems with DR, data deduplication and decryption.  Imagine the rapid enablement of new/changing inventory utilizing IoT and targeted inventory control and management software modules.  Point-of-sale applications could run locally in a store, verified though inventory control but utilizing the database at the data center as the source of truth for inventory, each at low latency and making backup and recovery considerably easier.

I haven’t even mentioned the neural network programming required for Artificial Intelligence (AI).  The sensor data path would need a return neural update to take advantage of real-time data.  The large centralized system creates the AI programming for the remote locations and delivers the modified neural network to the edge within a single pane of glass management system.

Analytical and AI models, pushed to the edge, will need to be monitored for accuracy and part of a continuous improvement lifecycle.  I could see this being used in all the verticals mentioned above.

Breakout of ROBO enhancement

Figure 2: Breakout of ROBO enhancement

The permutations on top of a solid ROBO solution model are staggering.

Until bandwidth and latency limitations are overcome, we’ll need to treat the data where bandwidth and latency aren’t a problem.  As IoT data creation overcomes the available bandwidth, the optimal way to deal with it is at the edge.  The ROBO model may be the answer.

Michael Nelson is the product manager for DXC Technology’s Modern Platform capability. His responsibilities include product development in the platform space, as well as coordination with DXC partners in the coevolution of platforms for the x86 virtualization space. @abusedbits

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.