Two Major Challenges For Device Makers Connecting to the Cloud
You have a good idea. No, you have a great idea. It’s so great that other people are telling you how great it is. “I wish I’d thought of that!” “You better file a patent!” Your idea is so good you stop telling people about it to avoid someone building your thing faster than you do. You sneak away to your hideout where you get to work. You select your chipset, board and comms protocol. You write the firmware. You source the materials at a cost that nets a profit within the first 12-18 months based on sales projections. You build your first prototype. You even find an incubator who loves your thing and commits sales, marketing, and strategic resources to help get you off the ground, along with some angel funding. Now all you have to do is connect your device to the cloud. This part can’t be harder than what you’ve already accomplished...
Smart device makers can end up investing a majority of their up-front energy on the device itself, leaving the cloud bit to the end of the project. It’s easy to see why; large cloud providers such as AWS have done a great job offering ultra low-cost, MQTT-based cloud infrastructure and enablement services to support the Internet of Things. Without real-world experience, it may feel like it’s a matter of finding the right engineers and setting them loose for a few weeks to bolt on the cloud. Even when starting with the most complete IoT cloud infrastructure available, decisions in cloud architecture selection and design have a critical impact on the longevity of an IoT business model and the success of a smart device venture. In this post, we outline two challenges that device makers face in connecting devices to the cloud.
1. Cost of Cloud
A good way to think about cost of cloud is to look at other long-tail product costs. Product manufacturers have priced products to include a warranty reserve for decades. The warranty reserve protects the business from expected losses incurred from the normal cost of doing business (lost/damaged product in transit, manufacturing defects, returns processing, etc). Warranty reserve is captured in the upfront sales price and then essentially held in escrow to fund the costs incurred to support warranty and loss. Similarly, cloud costs should be captured up front and ‘ammortized’ over the expected life of a device.
Cloud services have for the most part gotten cheaper over time, and that trend is expected to continue. It may feel like there’s no need to worry about the cost of cloud but, no matter how cheap cloud gets, it’s still a cost that must be built into the price of a device. Failing to account for that cost over the expected device lifespan can wreak havoc on a bottom line. The road to recovery is rough, as raising a device’s price is not a welcome change. We’ve commonly seen device makers release a product and then a few years later try to offer customers a paid subscription for ‘advanced’ capabilities. Sometimes it is a legitimate upgrade in functionality. Other times it’s an effort to recover the cost incurred from active (or overactive) cloud infrastructure.
Divining your device’s cost of cloud should not be an esoteric exercise. The most popular cloud providers present up-front, pay-per-use pricing for all of their services, and connected devices are extremely well-suited to a pay-per-use consumption model. How devices consume those services and over what expected period will determine exactly how much to account for your cost of cloud.
Use these questions to help guide the answer to per-device cost of cloud:
What specific cloud services are used and how are they priced?
How many devices will be sold over the lifespan of the product model? By quarter?
How many users will use the devices?
How often will the device be controlled from mobile/web applications per day?
How often will the device be controlled manually/locally per day? (For instance, turning on a switch)
Will the device support voice assistant skills for Alexa and Google Home? (These service require real-time state updates from devices if connected to the Amazon/Google Cloud.)
Will your device store data in the cloud? If so, how much and over what period?
Answering these questions can provide a basis for the daily, monthly and yearly cost associated with managing the device in the cloud.
Capturing the services costs and breaking that cost down to the core transactional activities will yield a per-event and per-state-change cost. That cost multiplied by the lifespan of your device is your estimated cost of cloud.
If the cost seems prohibitively high there’s a chance the solution is over-architected - but, don’t worry - now that you know, there are ways to reduce it.
2. Device Ecosystems Support
Delivering cloud services is table stakes for smart device makers, and connected capabilities extend well beyond the device’s prime directive. Supporting control and state updates via 3rd-party channels such as Alexa and Google are expected to come with the price of the device. What good is a smart product if it can’t or doesn’t play well with other smart products? That’s a lot of investment and cost that doesn’t add directly to the bottom line.
While device makers understand the market demand for supporting voice assistants and 3rd party integration platforms, the roadmap for meeting these requirements isn’t well understood. The competing strategies of the largest voice assistant partners can complicate the path. Architecture decisions begin to matter much more when device state-changes result in messages that have several alternative paths to take to comply with 3rd party real-time state update demands.
Beginning these practices will allow your device to support wide ecosystem interoperability:
Build a developer-friendly API
If interoperating, your cloud will need to be responsible for providing a secure, developer-friendly API to access device capabilities
An HTTP API that follows RESTful practices as best possible is widely useable
API should follow HTTP verbs correctly - GET, POST, PUT, DELETE, PATCH
JSON payloads are widely adopted standard for device-based APIs and ecosystems
Return consistent objects - fields should be consistent for objects of the same type between resource locations
Use query parameters for filtering results and advanced querying
Have a plan for versioning your API
Release your API with high-quality, easily consumed documentation
Be sure to build in API Error Handling
Define simple, but consistent error payloads
Use consistent and appropriate error status codes
Security is not an afterthought of API Design
Use HTTPS/SSL everywhere
Encrypt data at rest
OAuth2 is a widely-adopted standard for user authorization
Implement Authorization Code grant type for server-to-server auth
Implement Refresh Token (if OAuth token expires)
Authorization Bearer token passed with every API request
Implement a mechanism for disconnecting 3rd-party services from your own service
Implement a method of notifying 3rd-party services of about these disconnections
Build to Support Device State Updates and Event Data
Provide Webhooks for returning real-time, asynchronous status data
Ideally provide ways to limit, filter, and return only specific fields user requests
A Faster Path to Interoperability
If handling 3rd-party device connectivity is a large and missing or costly requirement for your device, Yonomi Thincloud provides cloud connectivity for consumer devices with out-of-the-box integrations with Google Assistant, Amazon Alexa, and Yonomi One, along with secure user-device access roles and permissions, firmware OTA services, and much more.
In addition to the potential for wider target customer adoption, the added benefit to participating in the ecosystems of market exposure can be well worth the effort.
Ultimately, hardware can be a hard business in which to thrive. After a great idea becomes reality, hardware makers have to manage challenges that don’t avail themselves to easy solutions, like supply chain management, sales, order and returns management, customer support, and troubleshooting. With the right infrastructure, cloud management can be more of an enabler than a hurdle.
About the Author
Wilson is a technical sales support and implementation specialist at Yonomi. Experienced at tactical and operational levels at companies large and small, Wilson lives to solve problems and ensure customer success. We mean it - message this guy if you have any kind of problem. He once helped a guy move so they wouldn't miss a project milestone.
Are You Building a Connected Device?
Learn more about what it takes to get your device connected with our free Guide to Building a Connected Device.