In previous articles, it has been shown how advantages can be gained through the separation of data ingress processing from egress processing. While those advantages were focused around efficiency, asset reuse and promoting citizen integration, today we’ll examine how they permit the adoption of a hybrid cloud deployment strategy.
In those earlier articles, HTTP was utilised as the link between ingress and egress components. This was utilised as it is commonly understood and was suitable for the multiple-producer, single-consumer scenarios being discussed. A publication/subscription approach can be considered for other scenarios, such as multiple-producer, multiple-consumer, but also for those scenarios where at least one component is required to run on-premise.
Consider the simple point-to-point integration of a Monitoring System that generates alerts and wants corresponding work orders in an EAM system, where it is all cloud hosted.
How would this simple architecture change if one of those systems, say the final EAM system, was being run on-premise? While there are a number of approaches to solving this problem, we’ll explore one that builds on our earlier efforts around splitting ingress and egress components. If we were to split this cloud-based pipeline in the approach outlined earlier, but this time, utilising MQTT, we might end up with a design similar to the following:
This design shows two different pipelines, both of which are cloud hosted. The first pipeline is focused on data ingress, publishing to the inbound data topic of the MQTT Gateway, which in turn feeds that through the egress focused pipeline. However, a further tweak so as not to use the MQTT Broker as an entry point to that second pipeline, but rather as a communication link between the two might result in a design similar to the following:
Here, we still have two pipelines and we continue to use MQTT as the link, but the entry point to the second pipeline is an MQTT Stream, which subscribes to topics of interest in the MQTT Broker.
Having split these components in such a way, we can now shift one of these pipelines to run at a different location. This could be a second Reekoh iPaaS instance or a Reekoh Enterprise on-premise instance. If necessary, one pipeline might be running on-premise at a remote site with the second being in the corporate environment with just the MQTT Broker being cloud-hosted, providing an outbound only communication link between the two sites.
In our use case, we have the EAM running on-premise. Accordingly, the second pipeline will be moved to a Reekoh Enterprise instance running on the same site:
With communication from on-premise to cloud being outbound only, Reekoh’s cloud-hosted MQTT Broker can be used to bridge any cloud-originated or remote data source requiring integration on-premise in a simple, yet secure manner.
