【.com快译】在OnRueTechnologySolutions，我们一直在研究DataWheels，这是一种用于个人和公共交通的物联网解决方案。作为项目起点，我们首先需要选择理想的物联网平台。尽管市场上有很多选择，但我们仍然将范围缩小到以下三个： 1)Azure 2)GoogleCloudPlatform 3)AWS 第二周进行了研究2016年8月，因此在阅读本文时，跨平台的功能可能已略有变化。 1。架构成熟度 在整体解决方案层面，我们需要一个易于开发，同时具备常规REST服务、深度分析功能、消息收发队列、IoT特有功能的解决方案。鉴于此，谷歌落后于AWS和Azure。虽然Google的云平台擅长托管通用应用程序并擅长分析，但我们需要多种途径以组合方式解决业务需求。下面的参考架构图取自各自的站点。虽然我们能够对其进行自定义调整，但作为一个理想的起点，显然越少越好。 谷歌参考架构（引用自：https://cloud.google.com/solutions/iot-overview#telemetry） AWS参考架构（引用自：https://aws.amazon.com/iot/how-it-works/) Azure物联网架构（引自：https://azure.microsoft.com/en-in/documentation/articles/iot-suite-what-is-azure-iot/） Azure还提供了一个配置设置，就是你可以使用自己的数据中心作为网关。只有Azure和谷歌提供流或通道来简化集成（AWS在9月宣布了类似的解决方案）。在Google方面，它只推荐使用pub/sub连接；在Azure和AWS方面，我们有越来越灵活的选择。总体而言，Azure在这方面略有优势，而AWS略微落后。虽然我们不需要它，但我注意到只有Azure和AWS提供从云到设备的消息传递。 其次，开箱即用的功能 由于最终用户将使用我们的解决方案，因此他们必须能够激活和停用他们的设备。我们的物联网平台还需要启用高级身份验证和安全层。只有Azure和AWS提供设备级身份验证和激活。这也意味着如果我们选择谷歌云平台，我们需要自己开发这样的功能。然而，AWS不提供相关管道这一事实可能会给存储输入数据带来困难。 3。支持的协议 考虑到设备和物联网的特性，支持HTTP以外的广泛协议的能力变得非常重要。在这方面，AWS和Azure支持物联网中常用的所有协议，包括MQTT、AMQPS和HTTP。Google仅支持HTTP2和gRPC。由于我们决定使用MQTT作为行业标准协议，因此我们不需要进一步测试MQTT、AMQPS和gRPC之间的性能差异。在这种情况下，AWS几乎与Azure相当。 4。开发难度（SDK可用性） 在我们的产品中，我们主要使用MQTT，而HTTP仅限于少数用例。Azure和AWS为所有主要编程语言提供用于设备管理和物联网消息传递（使用MQTT）的SDK。在HTTP端，现有的API和语言足以胜任这项工作。Google也提供了所有语言的SDK，但只支持gRPC协议。在这个比较中，AWS仍然与Azure并列。 5.全栈支持 除了物联网消息传递，我们还有一些严格来说不是物联网特定机制的用例（例如用户登录等）。我们希望利用无服务器计算的一些功能来完成此类任务，所有三个供应商都支持这一点。另外，我们还需要一个NoSQL数据库，各个供应商也给出了自己的解决方案。在分析和机器学习方面（以及R和Spark等主流工具的使用），Azure和AWS表现优于谷歌（但这暂时存疑，因为谷歌在上述方面落后，所以我们不无已经对此进行了实际测试）。 6。价格 我们需要知道数据库的具体使用价格，runtime函数成本，数据流分析。此外，我们还需要了解不同数据量和数据摄取率的实际支出（取决于具体设备的数量）。在NoSQL数据库方面，我们意识到Google的定价要高得多。在消息处理方面，AWS和Azure都使用消息的数量作为计费单位——但两者对消息的实际大小有不同的解释。单个消息对于AWS为1KB，对于Azure为4KB。例如，如果您发送一条8KB的消息，它将在AWS中计为8条消息，但在Azure中仅为4条。根据我们的实际电子邮件大小和最近的用户数量，Azure中的消息传递成本比AWS便宜大约50%。 因此，权衡各种因素，我们选择了Azure作为我们的物联网平台。 原标题：物联网平台选择：Azurevs.AWSvs.GCP，原作者：HariharanAnantharaman
