When you are designing a cloud-connected product, you have a choice. Do you put the main chunk of your processing locally in the device or up in the cloud? Let’s look at the alternatives.
The obvious answer is that the cloud must be the right place for your processing to go. It’s what it was built for, right? To an extent that’s true, but first you have to get your data up to the cloud. Cloud platforms don’t generally charge for inbound data, but that doesn’t mean that your data transfer is free. If your device uses a cellular connection there will be a cost, often quite a high one, for data transfers. If it uses a wired or WiFi internet connection, you will need infrastructure that can cope with the volume of data being transferred. If you are using someone else’s infrastructure there may be safety and security standards you have to meet that wouldn’t apply to a separated network. The same considerations apply if you are using a private server instead of a cloud platform, though you should remember to factor in administration and maintenance of the server.
The amount of data you are dealing with matters a lot in these calculations. Sending readings from a temperature sensor will not usually cost you much, but video is an entirely different proposition. We mentioned that cloud platforms don’t generally charge to upload data, but they do charge for data storage and processing, and video files are large. Don’t neglect the storage factor when you are estimating costs. If your processing is in the cloud, you will be storing more data there. At some point you will be downloading some of that data, which there will also be a charge for, and again video files are large!
On the flip side, putting all your processing in your device may not be practical. You will need a processor that can handle the load, which will likely be more expensive than a processor that just shifts data up to the cloud, increasing your unit cost. You may also need more storage locally, and eMMC can be expensive. You might even find that the bigger processor puts more demands on the power supply, needs more cooling or puts greater demands on other support circuitry, with associated cost implications. Finally, you still have to get your results up to the cloud. The data rate will be vastly lower so there are unlikely to be infrastructure costs, but if you are using cellular communications the data transfers will still cost.
It is worth stressing that we are talking about ongoing costs. Traditional manufacturing companies are used to a commercial model that essentially costs them nothing after their product is sold. You sell your washing machine to your customer, and unless it fails during the warranty period that is the end of it. That is absolutely not true of connected devices. An IoT-enabled washing machine will incur the sorts of communications and processing costs we are talking about throughout the lifetime of the product. Your business plan will need to take this into account somehow.
There is an issue of flexibility that may also affect where you do your processing. You may find that you need to do processing that had not been anticipated in your design. This is quite common while prototyping, but it can happen much later in a product’s life. Adding new features, for instance, may mean processing the data in new ways.
If all the data is up in the cloud, it is relatively straightforward to change how you process it. You make your changes on the cloud platform, and propagate it around to your users via whatever mechanism the platform supplies.
If the processing is done in the device instead, then the device will need a firmware update to add new features. This could be incredibly inconvenient or practically seamless depending on how your device upgrade is implemented, but it is rarely free of irritation to your users. It may be less of an issue than it first appears since you should be making provision for firmware updates in any case, but that’s a whole subject of its own that we don’t have space to go into here.
A common compromise is to split the processing workload. The device filters and pre-processes the data, markedly reducing the volume that is sent to the cloud. If you have a suitable application and split the work appropriately, this can avoid many of the costs of the purely local or purely cloud-based solutions. The danger is that this pre-processing could remove information that you later discover the cloud platform needs, which may require some careful design work to ensure that the world doesn’t break when you upgrade. You need to think very carefully about both your current and future needs if you attempt this sort of compromise. It is possible to get the best of both worlds, controlling the configuration of local pre-processing from the cloud, but you have to design that sort of behaviour in and in contrast to uploads, downloads from the cloud aren’t usually free.
By splitting the logic carefully between the cloud and the embedded device your product may be able to provide a basic level of operation even if it has no Internet connectivity available, whether temporarily or permanently. This is something you should consider in your design particularly if your device will be mobile, for example if it is mounted in a car. Planning for your device to just record the relevant data throughout a journey but only upload it when it can reach your home WiFi is a perfectly reasonable design decision.
Something that we haven’t considered at all yet is data security. Millions of words have already been written about securing data communications, so we don’t need to say more than you should do it. The important consideration for this article is how secure your data is both on your own device and up in the cloud.
Cloud platforms take data security very seriously. Their reputations depend on it. You should look around to find out how secure your chosen platform is, but by and large it will look similar for all the major players. More helpfully you should consider what data you store and how. Doing what you can to keep personal identifiers out of your data sets is one obvious step; data is much less interesting to thieves if it can’t be related back to people or organizations. This amongst many other considerations should be going into your design process.
Securing data locally on your device depends a great deal on how complex your device is. A complex device running something like Linux will need to take all the usual steps for keeping a computer secure, in particular updating system components when security updates are available. Simpler systems are simpler to maintain, but again security against remote attacks should be considered in the design. More importantly you should consider what data on your device might be sensitive, and whether that potentially sensitive data needs to be uploaded at all. This may suggest that you want to do more processing on the device than in the cloud.
Realistically, data security may not be a big concern for many embedded devices. If the entire world knows that the departmental coffee pot is only three quarters full, that’s not a big deal, at least as long as the coffee pot monitor can’t be used as a vector for further breaches. Medical data being sniffed out of a heart rate monitor obviously would be a big thing. The sensitivity of your data can matter as much as technical concerns in where and how it should be processed.
Last but by no means least, you should think about where your product is going to physically reside once you have sold it. A connected device in a city will very likely have access to 4G or 5G networks. A connected device nestled in an isolated Scottish valley may have an intermittent connection at best. Your choices about where processing takes place will affect who you can sell your product to. Neither broadband nor cellular provision is universal, and the capacity and costs of both are constantly changing. Just consider that twenty years ago the internet could not have supported the volume of video calls that went on during Covid lockdowns.
This has been a very quick overview of the issues surrounding where your processing happens. As with all system design, it’s a balancing act and there is no one right answer. You simply have to sit down and research the costs and benefits that apply to your specific project.