In this final edition of three articles in our IOT decision-making tree series, we discuss the last branch of the IOT decision-making tree, highlighted in yellow below. It departs from the premise that your IOT device is IP enabled, but with no customisable or preconfigured firmware. From there it evaluates two scenarios: where your firmware is connected to an existing or custom-built backend.
The approach outlined in this branch of the IOT decision-making tree is ideal for prototyping as it is faster to launch, mostly budget-friendly and you can take advantage of almost immediately available IOT data and analytics.
The distinguishing factor here is data sensitivity – whether you require complete ownership and control of your data or whether you are comfortable sharing your data with the manufacturer. Of course, this branch may no longer serve your needs once you have completed the prototyping phase of your IOT device, in which case you will revert to branch 1 of the IOT decision-making tree.
Firmware already connected to a backend
In this scenario, you will not have control over the firmware, your firmware is already connected to a manufacturer-provided backend, and you are obliged to share your data with the manufacturer. Data is pushed to an existing backend and you have to integrate with the provided backend. With this option, you will also not have control over which protocol is implemented, eg, MQTT or HTTP. This is a manufacturer choice, which means you will have to configure your backend in such a way that it can work with the existing protocol of the device.
Firmware not connected to an existing backend
This approach typically uses TCIP, where there is an existing protocol and the device communicates via MQTT. In this scenario, you connect the firmware to your own backend with the advantage of having control and ownership over the data. Some options to consider are AWS IOT, Azure and Google IOT Core, which are easy to launch but less cost-effective and customisable. We briefly compare the big cloud trio below. This means you only have to provide the parameters and it will communicate with your backend and you only have to configure the language – either HTTP or MQTT – which depends on the purpose of the IOT product you are developing. With this option, you have complete control over which protocol to use that will complement your device’s architecture.
Big cloud trio: AWS/Azure/Google IOT
Despite the similarities in the IOT services such as AWS, Azure and Google, there are also substantial differences. One difference, for example, is how these services package their respective IOT tools.
The AWS platform is currently the leader of the pack with a 40% market share. It is good for providing the building blocks for scalable, reliable and secure IOT applications, enabling devices to connect to a cloud infrastructure securely and the ability to route messages. The devices connect with applications running in the cloud via HTTP, MQTT and WebSockets, which is secured using TLS.
Microsoft’s solution, Azure, is currently the second-largest IOT platform on the market. Its key features include the Azure IOT Hub that is the central platform for developers to build IOT applications and products. Essentially, IOT Hub is a flexible cloud platform as a service that supports several protocols including AMPQ, MQTT and HTTP. If your device does not support one of these protocols, Azure’s IOT Protocol Gateway can adapt your incoming and outgoing traffic.
Google IOT offers its cloud services specific to the Google Cloud and includes features such as machine learning modules and a document-oriented database as a service. Google’s Cloud IOT Core is a managed service that “allows you to easily and securely connect, manage and ingest data from millions of globally dispersed devices”. When combined with other cloud IOT services, it offers a complete solution to collect, process, analyse and visualise IOT data. Cloud IOT Core runs on Google’s serverless infrastructure that scales automatically regarding real-time events. Cloud IOT Core supports the standard MQTT and HTTP protocols, which means existing devices can be brought into its fold with nominal changes to firmware.
The main advantage of using an “off-the-shelf” solution with non-customisable firmware and connecting to an existing or custom backend is short time to market. With relatively low development cost and effort, one can conceptualise an idea and launch a working product to test the adoption in the market.
The complexity and potential of IOT have scaled substantially with the number of IOT devices. To start on your journey of what connectivity and protocol you require for your IOT product, contact Polymorph today. Polymorph focuses on ensuring the technology always supports the best solution.
Share