Why MVP is an essential sanity check for successful product development
The question shouldn’t be ‘is an MVP too time-consuming and costly to engage in?’, but ‘can you afford not to apply consumer insights from MVP […]
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.
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.
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.
In essence, though, it boils down to calculating a relatively fine balance between:
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.
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.
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.
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.
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.
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.
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.
As a tried and trusted technology innovation partner, we’ve developed smart, secure technology that’s in over 30 million homes worldwide, we can help manage your risk and get you to market faster. With experienced teams in software, hardware, connectivity and cloud, our clients value our independence, integrity and our track record in product design, development and systems integration to deliver innovation.
Contact us if you need advice and support.