IoT Platform Selection

At OnRue Technology Solutions , we were developing DataWheels, an IoT solution targetting personal and public transport. First key decision we (or rather Myself as an Architect, Product Manager and CTO) need to decide was the IoT platform to use. While there were lot of options available in market , we short listed following platforms

  1. Azure
  2. Google Cloud Platform
  3. AWS

I also had a look at Artik, Samsung etc. They did not appear to be a correct fit for our solution. This post will mention what parameters and thought process by which we chose the Platform for our solution. This study was done in second week of August 2016. So by the time you read this, there could be some changes in terms of capabilities of these platforms.

Once DataWheels has been launched, we will provide more info about our use cases. But the post can be starting point for things to consider. Based on your use cases, you  might be required to look at few more aspects.

  1. Maturity of the Architecture:                                                                             At an over all solution level, we needed a platform which can provide easy to develop and implement solutions right from regular REST service, deep analytical capabilities,  messaging queues and  IoT specific features. In this context, Google lagged behind AWS and Azure. While google is excellent in terms of hosting generic applications and analytics, we need to do lot of plumbing in order to stitch everything to-gather to suit our needs.                                                                                                                            Following reference Architecture diagrams were taken from respective sites. While we could improve upon each of them, a better starting point meant less effort for us.                                                                           Google Reference Architecture (Ref:https://cloud.google.com/solutions/iot-overview#telemetry)                               Google_IoTArchitecture                                                         AWS Reference Architecture (Ref:https://aws.amazon.com/iot/how-it-works/)                                                                                                                     AWS_IoT_Architecture                                                                 Azure IoT Architecture(Ref:https://azure.microsoft.com/en-in/documentation/articles/iot-suite-what-is-azure-iot/)                                                 Azure_IoT_Architecture                                          Azure also gives a provision where the gateway can be your own data centre as well. Though it is not a diffrentiating factor, it kind of tells about their maturity. Only Azure and Google gave streams or pipelines which will help in easy integration. In Google, the only recommended way of connecting was pub/sub while in Azure and AWS, it is not so restrictive and provided better options. Looking at over all, Azure emerged as  a winner in this section with AWS falling shortly behind. Though not required for us, I noticed that only Azure and AWS provided cloud to device messaging as well.
  2. Off the shelf features/capabilities available :                                                             Since our solution will be used by end consumers, they should have the ability to activate or deactivate their devices. Solution should also enable device level authentication and security. The non availability of pipeline made in AWS meant that storing of incoming data meant more development effort. Given that, Azure emerged as a winner and AWS closely following it. Lack of out of the box authentication and device identity in Google kind of surprised (as well as disappointed us). With that the chances of going for Google decreased significantly.
  3. Protocols supported                                                                                                       By the nature of devices and IoT, the time was to look for protocols other than HTTP. In this terms, AWS and Azure supported all the protocols used frequently in IoT like MQTT, AMQPS apart from HTTP. Google supported only HTTP 2 and gRPC. We did not conduct any tests to validate pros and cons between MQTT, AMQPS and gRPC and to measure their performance (Absolutely due to lack of time). Since we decided to go with industry standard of MQTT, chances of Google being chosen reduced further. Both AWS and Azure were equal in this aspect.
  4. Ease of Development(SDK availability)                                                                           In our product we will be using MQTT predominently and HTTP will be used for few use cases. Azure and AWS provided SDK’s in all popular programming languages for both device management, IoT messaging. For HTTP existing APIs in languages proved sufficient. Google provided SDK support in all languages only for gRPC. So in this criteria as well, AWS and Azure were equal.
  5. Availability of Tools for all our needs:                                                                             Apart from IoT messaging, we also have few use cases which are strictly not IoT specific (e.g user signup etc). We were looking for Functions to perform this and all the players supported it. We were also looking for NoSQL DB and all players provided the same. W.r.t capabilities in Analytics and Machine learning (and using popular things like R,Spark etc), Azure and AWS appeared to be better than Google ( To give benefit of doubt to google, we did not do experiments in Google cloud platform  to confirm this. Their documentation and guides too did not provide more information. Since Google lagged behind in other key aspects explained earlier, we did not want to spend more time in experimenting with Google).
  6. Ease of Provisioning and Scaling.                                                                                 It is the only area where Google won hands down. In AWS and Azure, we need to provision it before (in AWS we have complex set of plans to save you from daily monitoring and handling worst cases. But that is a seperate topic of discussion by itself.).
  7. Ease of Storage :                                                                                                             This was touched upon in earlier topics. In Azure, the stream analytics helps to store incoming data easily in data base or send to down stream system as message or give it to analytics system for real time analytics. This was not possible in AWS. In Azure, even for functions, there is a graphical interface to easily save into database (provided there is no need for data massaging or business logic).
  8. Pricing :                                                                                                                          For a solution like us, we need to look at pricing for different areas like Database, runtime cost of functions, stream analytics etc. We also need to look at pricing for different volume of data and rate of data ingestion (which are dependent on number of devices).  While coming to price of NoSQL DB, we realised that the price of Google cloud is significantly higher. So Google was ruled out.  When coming to consuming messages, AWS and Azure price based on number of messages. But the catch is the size of the message. In AWS, 1 KB is the size of the message and in Azure it is 4KB. For e.g if you send a message with 8KB, in AWS it will be treated as 8 messages and in Azure it will be 2 messages. So when you are arriving at pricing, this needs to be kept in mind to choose the corresponding plan.  In our case, we did the math and Azure worked out 50% cheaper than AWS.

Looking at all aspects, we have chosen Azure as our IoT platform. Please drop a comment or send an email to hariharan.anantharaman@onrue.com if you have any  questions.

Leave a Reply

Your email address will not be published. Required fields are marked *