(This is the third of four posts in our On-Ramp To IoT series, based on the Prototyping Connected Devices webinar co-presented by Todd Zielinski and Bill Horan and hosted by O’Reilly. Read the other posts: Anatomy of a Connected Product; Getting Connected and Communicating; and Prototyping Your Connected Device.)
So far we’ve covered the basics of connected devices and shared some details about how our electrical engineers and interaction designers work together to expedite and optimize IoT product development.
In our second post we went into the different types of prototypes you’ll want to make to test and fail and test and fail again, how to get connected to the Internet, and which protocols you can use to communicate with the cloud. In this post, we’ll cover the next step along your on-ramp to IoT: selecting a cloud provider to connect your device to the cloud.
Your First Decision: Should You Build Your Own?
If you have a limited budget and specific needs, or potential intellectual property or security concerns, rolling your own cloud service is certainly possible. Thanks to a number of open source projects out there, this is relatively easy to implement. Most use a Linux hosting service with a variety of databases as the back end. There are a lot of considerations in terms of security, access methodology, scalability, and end device implementation.
There are lot of factors to consider if you are using an open source IoT solution. Keep in mind the size of your platform, and how you intend to use and support it. Not every distribution will be a good fit, and a little research can save a lot of time.
Some examples include:
Canopy: Device side requirements are Linux C/C++ SDK, using a JSON transport — not much pre-packaged platform support. Server is using a Cassandra database cluster, with a custom REST API. Mobile application example support as well.
Contiki: This project has broad pre-built support for a range of hardware platforms and transport protocols with a small footprint, and a server side implementation using a CoAP API. It has lots of examples, and a very deep set of capabilities. Includes example mobile applications.
Kaa: Uses Apache Avro JSON implementation, and a device side SDK in C, making it portable and highly scalable from small devices up to larger ones. Has peer to peer communications, which can be very handy.
Particle: Pre-built support for their own open source hardware modules. Polished simple access, but less options; intended to connect to Particles’ cloud service. Includes mobile application examples.
And many more — there’s no shortage of projects building IoT cloud services right now.
How To Select a Cloud Provider
While there are a lot of scalable database engines and web services developers can use to build their own cloud service, having an out of the box solution that’s built to scale and has all the protocols defined saves time getting to market and takes care of headaches developers might otherwise trip over. You can save time and upfront development costs with a prebuilt service — at the cost of longer term fees for service.
For those choosing to go with an established cloud service provider, there are plenty to choose from – Ayla, Telit, Cloud Vortex, ThingWorks, Nabto, Mbed, 2lemetry, Google Cloud Platform, and more – and there are a lot of considerations that go into finding the right provider for your device. The big factors to keep in mind are: pricing models, hosting, capabilities, and web/mobile portals.
The Gist. What’s the cloud provider’s pricing model, and does it gel with your business model?
There seem to be as many ways to charge for cloud services as there are cloud providers. Some have annual fees. Others charge monthly. Some charge by device, and some are based on data transfer amounts. For your device to be really successful, find a cloud provider whose business model matches yours.
Some device-only plans require a little bit of data transfer, but others require a lot. If you have a valve that you turn on once and never turn off, then having something that is data transfer-based is probably less expensive for you. But if you want to check the temperature every twenty minutes, an always-on connection that gives you a monthly plan and charges by the number of devices will be more your speed.
The Gist. Does the cloud service offer constant connections, or does it connect periodically or on demand?
There are latency times, throughput, protocols, and transport methods to consider. Some devices need to be able to connect immediately and not have a delay of X number of minutes, so those work better with a constant connection. Others only need to update occasionally — say, for a temperature reading — which is more economical with a slower on-demand connection. Some applications need a local/ peer to peer communications path that is only offered by a few cloud providers.
This is also where security concerns come into play. You want to make sure the provider uses a well-known and secure method for communicating. What does it support and how does it support it? Make sure the provider fulfills your security needs.
The Gist. Does the service host its own server instances, or does it abstract them onto other providers?
Some cloud service providers host their own machines with the services on them. Others use their machines but abstract the services onto the servers of others, such as Google or Amazon. In the latter cases, the cloud service provider is an intermediary to another hosting provider who has the hardware and is actually doing the work of database and hardware upkeep and maintenance.
This can be good or bad depending on your biggest concern: Is it scalability, availability, or security? If availability and reliability are your top priorities, being able to spread out across multiple hosting services might be a better fit for you. Some cloud providers that manage their own instances may provide lower costs or more security — at the potential cost of availability.
If you have a limited budget and you think you can handle it, building your own individual host solution is another option. There are ways to do that, including open source methods. A cloud service is really just a database, but it is a highly scalable database with very particular and simultaneous connections. Amazon is working toward becoming a build-your-own cloud service provider, but it’s not quite there yet.
Web Portal or Mobile Portal
The Gist. All portal service providers handle the custom user interface (UI) differently, so it’s important to consider your end user’s needs.
Some services are more centered on the mobile app. Some come with kits so you can develop your own dashboard, which comes in handy if you’re looking to deliver a dashboard application that lets you see location of assets. If your user wants to see if the temperature is correct in their house, then a mobile application is probably more your speed.
Ultimately your development team will build the final UI that the user sees, but the underpinning for the portal will come from the cloud service provider. The base Web or mobile portal they provide will give you a sample, working framework and source code from which to develop your UI. That will save all the actual IO work and make it more of a UI job.
Cloud Providers: What’s Out There
There are plenty of providers to consider right now, and the view keeps shifting. Google Cloud Platform just bought Nest. Amazon bought 2lemetry to be its ongoing cloud service option. PTC Cloud Services bought ThingWorks and is trying to position itself in the industrial space. Particle just changed its name from Spark and offers an open source application in addition to its own offering, and Samsung acquired its own network, called SmartThings.
There are also cloud services offered by individual module vendors like Telit and TiWi Connect, which is by LSR. There’s a lot of different scale here and different applications for each one of these.
The Bottom Line: There’s no simple answer! You have to examine each device carefully on a case-by-case basis, keeping your business model, technology, and end user in mind. That’s the only way to find the absolute best fit for you.
The next post, Prototyping Your Connected Device, addresses how to choose your EE kit, chipset, and module; and includes a case study of our sample IoT device, Sprink.lr (a smart watering system for houseplants).
(On-Ramp is an ongoing series explaining engineering techniques used in product development.)