An open source platform in practice

According to surveys carried out by the Eclipse Foundation, 20% of IoT platforms have been developed as on-premise solutions. This shows a positive trend with regard to the use of the public cloud, but there are dozens of reasons why we might want to continue to develop using on-premise or open-source solutions:

  • Return of investment: We might have a budget that is too small to justify a big investment
  • TechnologyWe might want to use technology that does not depend strictly on a supplier
  • Privacy: We might want to export data outside our country
  • Data shadowing: We might need a copy of the data on our legacy platform, either to experiment with or just as a backup
  • Integration: We might be implementing an inter-cloud platform, meaning we need an an integration layer
  • Experience: We might be developing our first I-IoT platform, so we want to start small
  • Product: We might want to develop our product using only cloud infrastructure
  • Intellectual property: We might need a small space to run our analytics, helping to protect our intellectual property
  • Legacy integration: We might have developed an old legacy platform that we want to integrate with our I-IoT platform
  • Connectivity: We might have some restrictions with regard to connectivity and we might want to control the traffic

In this chapter, we will develop a custom platform by reusing the concepts that we learned in the previous Chapter 7Developing Industrial IoT and Architecture. The following diagram depicts the proposed solution:

An example of an on-premise platform using open source technologies.

We will use Mosquitto as a Message Queue Telemetry Transport (MQTT) data broker in conjunction with Kafka to improve scalability and to provide an isolation layer. We can replace MQTT with different technologies, and we can also use it in conjunction with a different protocol by replacing Mosquitto only. Our data will be stored on Cassandra, using a KairosDB data abstraction layer. Rule-based analytics will process data through the Kafka data stream (hot path), while advanced analytics will use Python and Airflow to process a small portion of data via micro-batch processing (cold path). The results of these analytics can be stored on Elasticsearch or a SQL database. We won't be covering how to manage this data as part of this project. Finally, we will implement an asset registry using Neo4j.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset