At OnRue Technology Solutions, we were developing DataWheels, an IoT solution targeting personal and public transport. The first key decision we made was deciding which IoT platform to use. While there were lot of options available in market, we short-listed the following platforms:
Azure
Google Cloud Platform
AWS
We 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 the second week of August 2016. So, by the time you read this, there could be some changes in terms of capabilities of these platforms.
Maturity of the Architecture
At an overall solution level, we needed a platform that could 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 a lot of plumbing in order to stitch everything together to suit our needs. The following reference architecture diagrams were taken from respective sites. While we could improve upon each of them, a better starting point means less effort for the team.
Azure also gives a provision where the gateway can be your own data center as well. Only Azure and Google gave streams or pipelines that will help in easy integration (AWS introduced it in September, once we already chose the platform). 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 overall, 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.
Off-the-Shelf Features
Because our solution will be used by end consumers, they should have the ability to activate or deactivate their devices. Our IoT platform should also enable device-level authentication and security. Only Azure and AWS provided device-level authentication and activation capabilities. It also meant that we needed to develop that component if we were going with Google. The non-availability of pipelines in AWS meant that storing incoming data meant more development effort on our part.
Protocols Supported
By the nature of devices and IoT, support protocols other than HTTP was a key requirement. In these terms, AWS and Azure supported all the protocols used frequently in IoT like MQTT and AMQPS along with HTTP. Google supported only HTTP 2 and gRPC. Since we decided to go with the industry standard of MQTT, we did not conduct any tests to validate pros and cons between MQTT, AMQPS, and gRPC to measure their performance (absolutely due to lack of time). Both AWS and Azure were equal in this respect.
Ease of Development (SDK Availability)
In our product, we will predominantly be using MQTT, whereas HTTP will be used on a few use cases. Azure and AWS provided SDKs in all popular programming languages for both device management, IoT messaging (using MQTT). For HTTP, existing APIs and languages proved sufficient. Google provided SDK support in all languages, but only for the gRPC protocol. So in this criterion as well, AWS and Azure were equal.
Support for the Complete Stack
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 (serverless computing) to perform this, and all the players supported it. We were also looking for a NoSQL DB, and all the players provided that as well. Regarding 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 the benefit of a doubt to Google, we did not do experiments in the Google Cloud Platform to confirm this. Since Google lagged behind in the other key aspects explained earlier, we did not want to spend more time in experimenting with Google).
Pricing
For our solution, we needed 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 volumes of data and rate of data ingestion (which are dependent on the number of devices). While coming to the price of NoSQL DB, we realized that the price of Google is significantly higher. So Google was ruled out. When coming to consuming messages, AWS and Azure price based on the 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 example, if you send a message with 8KB, in AWS it will be treated as eight messages, and in Azure, it will be two messages. So when you are arriving at pricing, this needs to be kept in mind when choosing the corresponding plan. In our case, we did the math based on our message size, the number of users in the near-term and medium-term, and the number of messages in Azure worked out to be roughly 50% cheaper than AWS.
Looking at all aspects, we have chosen Azure as our IoT platform.
