At DevicePilot, our customer is "any company deploying connected products". With a definition that broad, it's not surprising that they span a huge range of value-per-device. The monthly recurring revenue ("MRR") per device that our customers charge to their end-customers ranges from $50 or more, down to $0.50 or less - a range of 100:1.
Device service cost
Modern connected products are built atop SaaS services. As a vendor of one of these SaaS components, we spend a lot of time thinking about our pricing (and our costs). Clearly we can only charge a fraction of the revenue for our service that our customers charge for their solution.
This can be challenging because many IoT services are so new that it's still unclear exactly what price end-customers will pay, which creates turbulence back up the value chain. But it's also possible to work forward along the value chain: starting with the basic service costs and working up to what price the end proposition must charge to make a profit.
Chattiness drives cost
What drives service costs in IoT?
Simply: data.
Some devices are very "chatty", such as a smart meter generating a message every 10 seconds and sending all that data to the cloud for storage and query, driving substantial monthly costs.
Other devices are far more uncommunicative, like those that must be frugal with data because they are battery-powered, or connected via very low-bandwidth connects such as LoRA or Sigfox. For example, a smoke alarm might send a "battery OK" message only once a day.
With these wild differences in service cost and service value, it's vital to do your sums to make sure your proposition can be profitable.
Is cost correlated with value?
Is end-customer value connected with device chattiness? Are chatty devices valuable and quieter devices not? If that's the case, then it should be possible to build a successful business anywhere along the continuum.
Sometimes the answer is "yes": cost and value are correlated, because other service costs have already constrained them to be. For example, if you incur $1 of cellular data charges per device per month, then (hopefully) you'll have ensured that your end-customer value is more than that.
But in other cases, the answer is "no": cost and value are not well-correlated. If the device is mains-powered and connected over some all-you-can-eat network such a domestic broadband connection, it can still generate quite a lot of data, even if it's of low-value to the end-user - this is typical of some B2C applications. This can lead to a situation where ongoing cloud service costs dominate and drive an otherwise successful IoT business into loss.
A second cost driver: queries
If your application reacts live to incoming device data and then discards it, the above is probably a realistic analysis. However many applications need to store historical data from the device (like activation numbers, energy, temperature, etc) and then do some calculations on that data to achieve some useful goal, such as informing the user or automatically taking some action.
Generically we'd call the component which does that a "database" and the way we ask a database to look up data and apply calculations is called a "query". There are many types of database int he world, each optimised for specific types of query: relational, time-series, graphs, etc. Generally what determines the cost of a query is simply how much data is touches, driven by underlying data-transfer and CPU time costs.
Your monthly per device query costs are the product of:
- How much historical device data each query touches (often best described by how long it took the device to produce the data)
- How many such queries you run per month. If you need to know the answer within a day, you'll need to run your query once per day
Reducing your device chattiness has a double win, because not only does it reduce ingestion and storage costs, it also reduces query costs because there's just less data to query per day.
Estimating your costs
We now introduce a simple spreadsheet based on the above to sanity-check how long your IoT SaaS costs can possibly be - just plug in two or three key numbers for your application and find out the rough minimum for your cloud service infrastructure costs (per device, per month).
(If you get stuck using the sheet, see the end of this blog for instructions.)
Note that your actual costs will likely be significantly higher because of other services and applications you need to pay for, but hopefully this is useful in establishing a baseline.
We've used AWS pricing for this analysis partly because it's statistically your most likely choice (something like 80% of companies use AWS!) but also because it's the benchmark for other cloud providers to match.
"It's too expensive!"
After using this tool, you may find yourself recoiling in horror / trying to figure out how you can make it cheaper. Perhaps you might expect economies of scale? No such luck - as part of its cunning plan for world domination, AWS offers the keenest pricing to even the smallest user, and so your costs will scale linearly with volume.
You might consider looking at your lower-level technologies. Instead of buying your platform or database as a PaaS, you could just go for IaaS - launching your own EC2 servers in the cloud and installing open source software on them. This will apparently be cheaper but only if you ignore what is usually by far the biggest cost in most tech companies: your people! The expensive kind of people who can configure databases on EC2 servers, and recover them when they fall over because their disk has filled up at 3am (because sod's law dictates it must always be in the middle of the night, right?). You'll also likely experience much worse up-time than an AWS service since not only is that reliable to technical measures like redundancy or elasticity, its scale has already enabled massive investment over time in quality of delivery. In essence, this is why the world is moving up from IaaS to PaaS.
So if you find yourself saying "it's too expensive!" even to commodity AWS IoT pricing, then you need to take a hard look at your customer value proposition and see if you can increase it, because in terms of cost you're up against the iron laws of cloud economics.
Conclusion
Device service costs place a floor on what you must charge your end-customers in order to make a profit. Your best bet for reducing service costs is to reduce the amount of data your devices send back to the cloud. Perhaps you could even add some edge processing in your device.
The spreadsheet, explained
To use the spreadsheet, just plug your numbers into the yellow boxes. You'll then see updates to the prices for three different sets of AWS services that you might be using:
- AWS IoT Core: This is the canonical "vanilla" AWS IoT broker. You pay a fee for device security (per device, not per message) and then for message ingestion. For storage, we assume here you use S3 (which is astonishingly cheap and scores well on every dimension you might care about such as resilience, availability, scalability, bandwidth, etc.) and for querying you use AWS Athena, which is able to perform a variety of SQL-like queries straight out of S3.
- AWS IoT Analytics: This plugs into AWS IoT and provides the ability to do stream processing on data. You pay to "process" it into a custom internal store, and then to do SQL-like queries on it.
- AWS Timestream: AWS' time-series database (TSDB) as-a-service, here we assume that you're ingesting somehow for free (unlikely).
We reiterate that all of these estimates are the absolute bare minimum cost you could possibly pay to give you a "sanity check" (or "order of magnitude") estimate of what your costs might be. Any real deployment would certainly incur many other service costs too - let alone your own people costs.
What's really interesting about these costs is how similar they are, which further strengthens the case that we're really knocking up against some fundamental economics here.
