At Tempest House, we’ve built dozens of high-quality, scalable apps, both IoT and otherwise. From this vast experience, we’ve distilled 7 tips for architecting an IoT product (and an example architecture at the end):
IoT products create a huge amount of data. There are many ways to structure your data, and the best design will necessarily vary on a case-by-case basis. Our process for choosing a design, however, is relatively consistent:
First, we ask:
Then, we work closely with the firmware architect, asking questions like:
Finally, we write transformers that turn the data into what we need to pass to the server.
Once someone understands their needs, they can design a structure that will withstand even the needs of large quantities of data. In designing this structure, the most important part is having clear communication between the data transit architect, web architect, and a competent firmware team.
While high-quality firmware will dramatically increase a device’s functionality and reliability, low-quality firmware prompts all sorts of headaches.
What does high-quality firmware look like?
How can you recognize low-quality firmware?
The structure is disorganized (typically due to poor planning).
Since connectivity is fundamental to an IoT product, communication from IoT devices is of the utmost importance. For that reason, we built a messaging queue into our standard toolkit that keeps sending messages until the message is received. This queue, built using Redux, also allows us to flag priorities to dynamically reorder the queue on demand and set contingencies for failed requests. Since communication is so important, it’s key to ensure each message arrives at its desired destination.
Due to their increased connectivity and increased points of vulnerability, IoT devices have unique, heightened dangers. To combat these vulnerabilities, adhering to industry-standard security practices will take you far. These three practices are especially important:
There are best practices for data encryption…but most people don’t use them. When used properly, however, it’s nearly impossible for a hacker to decrypt your data without full access to your systems.
At Tempest House, we store encrypted tokens that ensure our front-end is properly authenticated with our back-end. Personally, I like the Ionic Identity Vault because it prevents hackers from retrieving tokens from our mobile devices. While this sort of security measure costs a little extra, it can be invaluable in avoiding breaches.
At the end of the day, our security experts can’t offer every service that we recommend to our clients on their own. We build secure software for our clients, but we also recommend that one of our partner companies, EdgeScan, provide manual and automated penetration testing. They check all of our endpoints and probe further when they find problems. As an added benefit, they offer a security certification when a device/service passes their tests.
While compliance is not exclusively an IoT-related topic, the added communication between devices does make it more complicated.
GDPR is currently the most-complicated compliance issue. Anytime we architect something, we walk through a personal checklist of GDPR requirements. It’s a long, multi-page document, but undoubtedly worth the time. If anyone from the European Union uses your application and you’re not following GDPR, you can be liable for up to 4% of your company’s global revenue.
A scalable product is key to a company’s success. This is even more important for IoT devices, as much of their value comes from being networked.
For a scalable back end, we use often Tempest Tools, which we developed in-house. It has lots of built-in features and can build back-ends quickly.
For some high-load projects, we like to combine Tempest Tools with already-scaled back-ends like Express or Lumen. We determine which requests provide large amounts of load and use a microservice architecture with thin endpoints to balance the load.
Beyond the above options, we also have developers that can create backends in all the popular coding languages and frameworks. We are well-aware of the pros and cons of using each one, so we will always recommend the best toolset for the job.
This hybrid approach does have its downsides. Some activities—especially processor-intensive ones—run too slowly inside a virtual browser. For these processor-intensive cases, we employ plug-in architects to write native code. It’s a trick that most companies aren’t familiar with, but which allows us to optimize battery and CPU usage.
Here’s how Tempest House typically architects an IoT product using a hybrid application:
A.) We run a virtual browser inside a mobile application that uses Bluetooth Low Energy to connect back and forth with the IoT device, using a plugin that runs natively on the mobile device.
B.) After the device communicates with our server, our load balancer finds the proper node to process it.
C.) The node communicates a response through HTTP or real-time messaging. (We like to use Pubnub because it’s easy to set up, saves time, and works reliably with a low development cost).
D.) That back-end node also communicates with the cache and database (either SQL or NoSQL).
E.) Additionally, if we need to send push notifications to a mobile device, we send those through an Apple/Android messaging service.
While these tips and example are what we could easily share here, it’s far from everything we know. Building an IoT product is a complicated endeavor.