IoT deployments involve an interlinked chain of critical decisions that can substantially impact the cost of operation if the wrong choices are made. The trick is to find the correct balance and optimise the trade-offs between different options, writes Consult Red’s, Stuart Griffin
As IoT matures, the volume of devices involved in deployments is scaling up from the thousands to the hundreds of thousands. At the upper end, deployments of half a million or more IoT devices are changing the economics of service provision and the total cost of ownership (TCO) per unit. Offerings that take-off are finding that cost efficiency assumptions from cloud decisions such as data management, server choice and real-time versus batch processing are inter-related; they can substantially impact the cost of operation.
This is a complex web of decisions with many moving parts, so a decision that appears relatively simple in isolation is complicated because of the knock-on effects it has on other critical decisions. Importantly, choices that benefit lower volume or initial roll-outs do not necessarily carry through to mass deployments.
Edge or cloud or both?
As deployments grow so do cloud costs
Cloud is an obvious choice as an enabling technology platform for innovative new services because it offers the potential to scale up in line with increased utilisation of a service or product. In addition, the cost comes in the form of Opex rather than Capex, and this is attractive for unproven concepts or offerings for which it is hard to get a clear notion of predicted uptake. However, the cloud has never been free, and IoT organisations are increasingly aware that, as their deployments grow, so will their cloud costs.
Harnessing edge to reduce operating costs
The alternative to cloud Opex is to invest in adding greater computing power to the device itself. Adding edge intelligence capabilities comes with a greater upfront Capex burden. Still, once spent, services are less exposed to fluctuating cloud costs and will have lower operating expenses for the product or service’s life. Significantly, many chipsets and components used in IoT devices already come with some intelligence embedded and utilising this may be a minor incremental cost.
Fine balance between Capex and Opex
In essence, though, it boils down to calculating a relatively fine balance between:
- Capex to develop devices with intelligence to sift data, identify trends and initiate action or,
- Opex, to send large amounts of data to the cloud for processing and then to communicate back to the device for action to be taken.
Cloud and network costs are more significant for deployments that don’t utilise intelligent edge devices, but capital costs can be minimised with a simpler product.
Server versus serverless
Looking at economies of scale
Cloud or edge is just one aspect to consider. Deciding whether to adopt a serverless architecture or a server-based one is also finely balanced. Serverless is great for prototyping because it allows users to pay as they grow but it doesn’t deliver economies of scale; once utilisation reaches a high level, conventional server-based architectures will be cheaper.
Switching later isn’t easy
This decision depends almost exclusively on a deployment’s expected cloud utilisation. If high volume is expected, server-based is the way to go. However, caution must be taken because changing from serverless to server-based isn’t like flicking a switch. The architectures are different and it’s a complex process that can cause delays and increase the cost.
Data lake or database
Balancing cost and latency
There’s a similar dynamic in selecting a data lake or database approach. A data lake will be cheaper at high volume, but it will also be slower and harder to use. For some IoT apps, this will make a data lake unsuitable. However, for others, the savings will be substantial with high volume deployments, especially those that use a server architecture finding the lake easy to use.
Real-time versus Batch
This demonstrates how a server decision can affect data management decisions and have longer-term impacts on the overall TCO of the deployment. It also feeds into deciding between real-time and batch processes. Batch processing is inherently more efficient and can also be scheduled when processing is cheap. But it can add complexity and it isn’t suitable for use cases that demand a rapid response. The choice between batch and real-time is a fundamental consideration when reducing the operating costs for high volume applications.
Balance flexibility with cost savings
What lies ahead
If IoT were a static situation, it would be straightforward to decide on these issues, but a key challenge is to predict what lies ahead. Scale might be slow to arrive, and growth stages may not occur as expected. Organisations, therefore, need to balance what they need now with likely consumption in future. Over-provisioning is inefficient, but under-provisioning can mean you’re unable to meet customer demand. Monitoring usage and uptake carefully means you can pre-empt when you need to re-architect for greater volume, but trends are not always clear.
Flexibility costs money
This means a further balance needs to be decided between flexibility and expedience. Flexibility costs money at the start but could save costs as organisations adapt their architecture. The three major cloud hyperscalers, Amazon Web Services, Google Cloud and Microsoft Azure, all have different strengths and weaknesses, and organisations should consider which matches their needs best. Low-cost solutions may involve multi-hosting, but this can be challenging to manage. A solution that provides greater flexibility may ultimately be more valuable to scaling the deployment than potential cost savings.
Getting help to manage trade-offs
Understanding the different dimensions of IoT device deployments as scale accelerates is complex and multi-faceted, with various drivers changing priorities in different phases of the product lifecycle. Collaborating with experts who have participated in device design for roll-outs involving millions of units, like Consult Red, can help demystify the process and understand the critical way-markers on the journey from pilot project to mega volumes.