On-prem/Private IoT Platform Gotchas

During 2017 I had a number of conversations with clients about where the computational power for their IoT projects would be located. In my webinar “IoT Target Architecture: Your Strategy’s Linchpin” I discussed how to identify the functional requirements that drive compute toward the Edge (or away from it), those being:

• Data stream filtering (reducing how chatty a device is)
• Cycle-Time (need to make a decision faster than network communication permits)
• Availability (the ability to operate or fall back to network independent operation)
• Data protection (need to address an intellectual property or geopolitical control)

(The webinar is available on-demand if you want to hear those details. Note the 1/2 driver was for data protection as it so often implemented in private or controlled colocation rather than a pure edge compute scenario.)

There are situations where this results in adding compute capability directly to the IoT Endpoint but there are also many situations where the additional capabilities do not have to be at the “thing” itself. Data protection is an example of this: the organization may achieve this objective by having the IoT Platfrom located in a private data center or near-prem location.

There are also organizations that are anxious about the idea of leveraging cloud for IoT and  can only address those concerns with a private platform approach.

What are Private IoT Platform Gotchas?

Hardware costs: Most of the IoT platform providers are going to limit use to certified hardware. There will be hidden costs in this as many of them will establish not only specific models but specific hardware support agreement requirements. These hardware purchases, due to licensing restrictions placed on the IoT platform itself, may not be available from your prefered partners, or if they are may not be included in your contract discounts. (This is tied into the fact that the certified and supportable models may not be normal part number/SKU and are limited to the specific models that are in the platform providers testing/certification labs.)

Licensing based on capacity, not use: Due to the fact that many private-IoT consumers don’t want to share operational details (which is one reason they are using a private platform), anticipate licensing to not be metered (as with cloud) but established based on capacity. In effect you will pay based on peek capacity instead of your actual loads.

Anticipate an upcharge license premium over cloud: When we have discussed pricing with suppliers developing private-IoT, not only do they often plan to price based from capacity but to charge a significant premium compared to cloud.  While I do not have data on negotiated multipliers, anticipate a 3-8X upcharge. Many of these suppliers are uncertain of the size of the addressable market for private-IoT (due to IoT’s long sales cycle) and are concerned about support and maintenance commitments becoming burdens. (Some suppliers will offer metered on-prem, but you should anticipate significant minimum reoccurring costs.)

Don’t forget about non-production:  Keep in mind that development, training, testing, etc. may each need separate environments.  For environments that run on-prem to meet availability or cycle time requirements, cloud based non-production (development, training, etc.) is a good option. For environments with a data protection burden, where the intellectual products or data cannot be cloud resident, consider pursuing a data sanitization strategy to enable as much cloud usage as possible.

Feature coverage will be an on-going issue: Keep an eye on what functions are in fact a part of the on-prem offering vs. cloud offering. There will be functions that will be impractical for the supplier to create on-prem versions of. Encourage your sourcing and legal folks to press for details on what is supported, for how long, how support will terminate, etc. in agreements.

There are problems that can only be solved by moving compute, storage and analytical capabilities close to or into the IoT endpoint. The key is including these issues in your architectural and operational strategies and avoiding having these issues become gotchas that derail your project.

Thanks,
Erik