Then - the problem with too much choice
Just five years ago, if you inspected the technical components of a handful of popular IoT systems, you'd see they had little in common under the hood. Sure, at a high level that all made a distinction between the four basic components (device → comms → cloud → application) but on closer inspection you'd see that the specific technical choices for each component were completely different.
The problem was that there was just too much choice for each component. For example, consider just the cloud platform: with more than 400 IoT platforms available, statistically it was unlikely that any two companies would happen to use the same one. And that was a problem, because they all worked differently and supported different technical standards, so having chosen different platforms, two companies would be each stuck in a relatively closed ecosystem where they (and their customers) couldn't take advantage of all the developments in all the other ecosystems.
Now - the joy of a little choice
Since then, the number of choices have been whittled down, as
- companies dropped out (like Samsung, who have shuttered two IoT platforms)
- companies started to converge on common "best practice" technical choices
- the big cloud players started to win
This has been generally a very good thing, because when looking at the architecture of IoT systems being designed today, you'll see that they share a lot in common and therefore are all able to take part in a large ecosystem. This gives vendors more customers (albeit with more competition) and gives customers more choices of alternatives to swap out for each component.
The result? Quality up, costs down, and rapid ecosystem growth.
Because DevicePilot is lucky enough to work with many IoT companies, we get to see what technical choices they're making. We thought we'd share that insight and what seems to be emerging as "best practice".
The map
We've attempted the impossible: a universal map to fit every IoT system. The idea is that any IoT vendor can point to a block and say "that's what we do". Some vendors may even fit across two blocks well - but no vendor can do every block well.
Device
If your use case is novel, you'll have to build your own device. But to help you, there's a wealth of designs available at the chip-level or the module-level (depending on your level of technical experience) as well as communications stack to help implement common communications protocols.
But increasingly, it's likely that there's already an off-the-shelf device available which does what you need - for example, if your use case requires temperature sensing, there's a a whole range of off-the-shelf devices to choose from, and you'll make your choice based on variables such as robustness, price, battery life, and which communications it supports.
Communications
Since this is the Internet of Things, you need to connect your device to the internet. The question is whether you can do this in one leap (for example, using a cellular modem in the device) or whether - for reasons of cost, battery life, or radio coverage - you need to connect in two stages using a Local Area Network from the device to a gateway, then a Wide Area Network from the gateway to the internet.
We've shown various choices and combinations here. Most IoT communications solutions are still not IP-capable (because of bandwidth and/or battery life) but that doesn't matter too much as long as they're terminated at the internet in the standard way.
The important idea of "end-to-end security" generally means that a secret is known only to each device and the cloud, so that the communications layer itself doesn't have to be secure. In ultra-secure situations (e.g. home CCTV) where you can't trust your cloud either, the right-hand end might be something like a smartphone application so the data can't be decrypted even if the cloud is broken into. However, if your cloud is broken into, you probably have other problems.
Security is important, and it's easier to get security right if you "own" both ends of the end-to-end security... which is an increasing number of hardware vendors such as Disruptive Technologies, Sigfox, The Things Network (LoRA) and Libelium are offering hardware which comes already securely terminated in the cloud. That also makes them much easier to use too.
Ingestion
There are two ways IoT data arrives in the cloud: via HTTP and subscribing.
- HTTP: This is the same mechanism that your web browser uses to submit a form to a server. As a common web technology it has a lot to recommend it, and common IoT communications services such as Sigfox can be easily configured to POST into common IoT analytics/storage solution such as DevicePilot without writing any code
- Subscribing: A "pub-sub broker" is probably the better pattern at scale, since it completely decouples the publisher (device) from one or more subscribes (analytics/storage). The world seems to have chosen MQTT as the IoT standard, along with standard ways to get security right, etc.
Your choice here is constrained by what device/communications can do, and what your analytics/storage can accept. Modern solutions like DevicePilot can do both.
Data format
There's also the question of whether the receiving cloud services understand the format of the data provided by the device? The good news here is that JSON is now the overwhelmingly preferred data format, with device properties being sent as a set of property-value pairs, e.g.
{ $id : “12345”, temp: 32, battery: 3.4 }
Services which are extremely data-limited such as SigFox may provide a way to "explode" tightly packed binary bit-fields into standard JSON for easy ingestion.
Analytics and/or Storage
In super simple cases, it might be possible to send IoT data straight to some kind of user interface without anything in-between - for example, to display live temperatures on a smartphone. But usually you'll need one or both of:
- Analytics, e.g. to turn a stream of temperature readings into daily max-min values. The more devices you have, the more you'll likely want analytics to boil down lots of data from your device estate into valuable insight.
- Storage, so that data is stored until someone wants to look at it
These services may be supplied as a single block (e.g. a time series database such as Influx or the one inside DevicePilot) or be delivered as separate components (e.g. AWS S3 storage plus Athena).
Either the IoT data can be stored before it's analysed, or the results of the live analysis can be stored until anyone wants to look at them (depending on whether you run your analytics as the data goes into storage, or as it leaves storage).
Historically, the coordination of analytics and storage used to required custom code - even if it used SaaS services underneath - but increasingly it's becoming possible to configure all the blocks to work together without any code.
An extra capability sometimes provided in this block is triggers/notifications - the ability to react when a particular device state or analytics result is observed, for example, if a device goes offline then raising a ticket in the ticketing system.
UI
The main questions here are:
- Who is the user?
- If they're technical then the kinds of graphs that systems like AWS QuickSight or Grafana produce will be fine
- If they're a business user then the kinds of charts available in systems like Tableau or DevicePilot might be more suitable
- If they're a consumer user then you'll likely want to design a custom application to optimise the user experience
- How many devices are there?
- If it's just a handful of devices then lists, line charts, etc. can work quite well
- If you have 100+ devices then you'll want a way to filter devices by criteria and easily "drive" your analytics tool to produce metrics across the entire estate
In this part of the architecture, we're now well into the land of standard web/mobile technologies, so if you start out with an off-the-shelf solution for your UI (for speed) but later decide you need more control over the user experience, you can then write your own application and extract the analytics using standard web interfaces, so there's no lock in.
Final thoughts
Increased commonality of service components has made it much easier to deploy |oT, and much easier to get it right. It's also opening up the possibility of new business models: a device which is auto-magically terminated in the cloud can be sold as a data service rather than a piece of hardware.
In the past, your choice was:
- Buy an all-in-one platform (often horribly proprietary with risk that you'd be locked in to something that became increasingly bad-at-everything), or
- Build your own solutions of out low-level technical blocks, requiring significant technical expertise, time, and money
Now it's more and and more possible to get the best of both worlds: rapidly deploy a complete IoT solution, entirely composed of off-the-shelf parts which can be bought as-a-service, without having to write any software. And yet because the interfaces to those parts are standard, it's easy to swap them out again if they don't perform, or break them into smaller chunks when you grow and wank more control and customisation.
For example, if you wanted a temperature monitoring solution you could deploy Disruptive Technologies sensors and gateway, plus DevicePilot for analytics and visualisation, delivering a complete, robust, secure solution in minutes... and as both are sold as-a-service, there's no upfront cost at all.
