Why you should not develop your own IoT platform?

In the old days cowboy-style programmers found pride in developing their own C/C++ standard libraries, wasting their time and employers money.
Later came time of home-grown libraries, e-commerce & CRM frameworks. We have entered PaaS/BaaS era now, but some individuals as well as organizations are still trying to develop their own IoT platforms.
Imagine a state-of-the-art device prototype with highly demanded functions. Authors rush to develop some back-end for it to make it “call home” periodically, and swiftly move to the market (competitors aren’t sleeping!). After short consideration, decision is made to build back-end for IoT project from scratch, reusing expertise available in-house.
Here are some hidden surprises one will encounter while building IoT platform on his own.
Security
As popular saying goes — letter “S” in “IoT” acronym stands for security. One cannot develop system that would be 100% secure, rather it’s always a balance between uninterrupted operations and security failures.
There are multiple areas requiring your attention from security stand-point:
- backend (cloud) access,
- communication between back-end and end-devices,
- firmware that runs your device
- physical access to device
- access via web / mobile app interfaces
As soon as your device will hit the market, there will be people trying to hack it. Sooner or later device will be compromised, question is how you can minimize damage and what reaction should follow from your side.
Don’t try to re-invent the wheel, use proven open-source software or go and get help from professionals. E.g. if you are not a cryptographer, don’t invent your own cryptography for your device.
Eventual complications can be very severe, e.g. look up the scandal of TRENDNet IP-cam, and ask yourself if you want to be is same situation with your product.
Security is on-going challenge and security is never “done” by 100%. To get better understanding of IoT security refer to this old, but still highly valid Internet of Things Top 10 security threats presentation from OWASP.
Updates
Try presuming that all software you ship on a device is fallible. And sooner or later you will be forced to release update, for security reasons, or to improve functionality. If you are dreaming about volumes, you cannot send technician to every individual device to flash updates. Only available options left are relying on your customers to keep your device updated (chances are pretty low, try recalling when was the last time you updated your home Wi-Fi router), or employ over-the-air (OTA) updates approach.
Your laptop’s operating system has OTA updates, your smartphone does, even Mars Curiosity Rover has one!
Paradoxically, poorly written OTA updates system can make your system even more vulnerable. There are edge cases, like power loss during device update or connectivity loss during transmission. If not handled properly, these situations will cause device firmware corruption, which will make device unusable or unpredictable.
Moreover, OTA will add up to list of security challenges: firmware image can be intercepted during update process, and reverse-engineered by competitors. Genuine firmware could also be used on a different device than the one it was intended for. And finally, someone could modify genuine firmware and install it on device with the intent to hack your backend.
Good news is that there are techniques that can be used to work around these issues. The chip vendors suggest their recommendations, and there are noncommercial projects in this area also.
To sum up, building secure & reliable OTA system can take years, however, there are battle-proven solutions on the market that you can use with little effort.
Device management
Before shipping your device out to end customer,you provision it on your premises: configure some settings, flash latest version of firmware, etc. As soon as device leaves your premises,it starts life of it’s own.
As any loving parent, you would like to monitor and maintain your device operations, troubleshoot problems, and, eventually, decommission devices when they reach their end of life. You would also like to have the opportunity to debug and configure remotely. If your device fleet grows, you will need some asset management system to be able to save/edit metadata for individual device.
Major IoT platform vendors have this features partially, e.g. Device Manager from Google Cloud IOT Core and Thing Registry from Amazon IoT platform. More elaborated solution is DevicePilot, it focuses monitoring and management of connected devices.
Protocols & gateways
When one dreams about volumes of sold devices, communicating with those devices in a reliable manner is a challenge, regardless of what type of transport protocol is being used. Cellular networks have blind spots, LTE doesn’t work in tunnels, home Wi-Fi routers sometimes fail and need rebooting.
Primo, networking is inherently unreliable, especially when devices are not stationary (there is even a term for that — Lie-Fi).
Secundo, backend infrastructure should be prepared to withstand peak number of connections from devices. Imagine 250+ million cars in Europe being equipped with telemetry systems, all of them trying to submit their telemetry data simultaneously (majority of cars are hitting the roads on Monday morning, and most of Europe is in same time zone). Try to imagine what kind of infrastructure will be required to support that load of simultaneous connections?
Common solution for that challenge is using light-weight protocols, and having dedicated component to handle inbound traffic from devices (commonly referred to as “device gateway”).
Protocols: there is a tendency to use message-oriented protocols, with queueing and pub / sub features, as they are more suited to unreliable connectivity situations. Default protocol choices are MQTT and AMQP, both running on top of TCP and ensuring reliable message delivery. In case when occasional message loss is not critical, MQTT-SN is employed (works on top of UDP transport).
Gateway: most often this is the endpoint, that hosts MQTT/AMQP Message Broker and facilitates messaging between devices and backend. In more complex cases it also acts as a bridge between multiple protocols, used in the system.
As these protocols are open-source, there are freely available implementations of message brokers one can use. However, in order to reliably support multiple connected devices, sooner or later there will be a need to employ cloud-offering from one of the cloud providers. Next move would be to use message broker service and benefit from extra features and ease of integration.
Interoperability and ecosystem
No single company or organization can develop complete IoT project alone. IoT It is best delivered by a set of partners, each of which contribute their narrow expertise to overall solution, because very diverse knowledge is required to cover the whole solution vertical. These competences include:
- end devices and sensors
- end device components
- embedded operating systems
- IT infrastructure
- security
- cloud services
- analytics
- visualization & dashboards
As a result — organizations have no other choice, but to partner with someone who can complement their expertise. Besides, employing proven, widely adopted solutions or horizontal blocks will lower the costs of complete solution. With widely adopted technology on board it would be easier to find partners, who you can integrate with. It would be cheaper to find and retain service providers, because they care about their future and would rather commit to working with widely popular platforms.
Don’t compromise on interoperability, forget about developing custom-protocols or data formats. The more open-standard your solution is, the better.
Platform flexibility
First data from real customers and devices performing in the field will provide you with many insights, and inspire you to produce next versions of your product or introduce complementary products.
Home-grown platform will lack flexibility and extensibility to support this challenge. It would not be possible to add new device types and add or diversify existing services. One will be forced to either keep redoing back-end architecture for every implementation or to create separate implementation for every new device generation.
Consider your future needs up-front, and don’t focus too much on current requirements. Choose platform that will be scalable and flexible enough to support next versions of your product.
Summary
Doing any kind of IoT project is hard, as it is still unchartered territory. It is wise to restrain yourself from developing complete IoT solution, because it will take too much resources from your side, and push paybacks even further into the future. Instead, one should consider building IoT solution from available horizontal blocks or components, that one can readily adapt. Doing everything alone is way to costly and risky, compared to thoroughly selected set of available building blocks.
