【51CTO.com快译】在OnRue技术解决方案公司，我们一直致力于开发DataWheels，一款专门面向个人与公共交通方向的物联网解决方案。而作为项目起点，我们首先需要选择理想的物联网平台。尽管市面上的选项众多，但我们仍然将范围缩小为以下三种：
一）Azure
二）Google Cloud Platform
三）AWS
另外需要提醒大家的是，本项研究完成于2016年8月的第二周，因此在阅读本文时，各平台的功能可能已经出现了些许变化。
一、架构成熟度
在整体解决方案层面，我们需要一款能够实现轻松开发并具备常规REST服务、深入分析功能、消息收发队列以及物联网特定功能的解决方案。有鉴于此，谷歌的表现要落后于AWS与Azure。虽然谷歌的云平台擅长托管通用型应用并在分析方面表现优异，但我们需要多路并进从而以组合性方式满足业务需求。以下参考架构图获取自各相关站点。虽然我们能够对其进行定制化调整，但作为理想的起点，改动越少显然就越好。
谷歌参考架构 (援引自: 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月发布了类似的方案)。在谷歌方面，其仅推荐使用pub/sub连接方式; 而在Azure与AWS方面，我们则拥有更多更为灵活的选项。总体来讲，Azure在这一领域略占优势，而AWS则稍稍落后。虽然我们并不需要，但我注意到只有Azure与AWS提供从云到设备的消息传递机制。
二、现成功能
由于我们的解决方案将供最终用户使用，因此其必须能够激活并停用对方的设备。我们的物联网平台还需要启用高级层级验证与安全保护机制。只有Azure与AWS提供设备层级的验证与激活功能。这亦意味着如果选择谷歌云平台，我们则需要自行开发此类功能。不过，AWS不提供相关管道的状况则会在存储输入数据方面带来难题。
三、所支持协议
考虑到设备与物联网的特性，对HTTP之外广泛协议的支持能力就变得非常重要。在这方面，AWS与Azure支持物联网中频繁使用的全部协议，包括MQTT、AMQPS以及HTTP。谷歌仅支持HTTP 2与gRPC。由于我们决定采用MQTT这一行业标准协议，因此我们无需进一步测试MQTT、AMQPS以及gRPC之间的性能差异。在这种情况下，AWS与Azure的表现基本相当。
四、开发难度(SDK可用性)
在我们的产品中，我们主要使用MQTT，而HTTP仅限于少数用例。Azure与AWS面向全部主流编程语言提供用于实现设备管理与物联网消息传递(利用MQTT)的SDK。在HTTP方面，现有API与语言已经足够完成任务。谷歌亦为全部语言提供SDK，但其仅支持gRPC协议。在这项比较中，AWS与Azure仍然打了个平手。
五、支持完整堆栈
除了物联网消息传递，我们亦有少数用例并非严格的物联网特定机制(例如用户登录等)。我们希望利用部分无服务器计算功能执行此类任务，在这方面三家供应商皆提供支持。另外，我们还需要一套NoSQL数据库，各供应商同样给出了自己的方案。在分析与机器学习(以及使用R、Spark等主流工具)方面，Azure与AWS的表现要比谷歌好一些(不过这一点暂时存疑，由于谷歌在前文提到的几个方面较为落后，因此我们并未就此做出实际测试)。
六、价格
我们需要了解数据库、运行时功能成本以及数据流分析等功能的具体使用价格。另外，我们还需要了解不同数据量及数据提取率情况下产生的实际支出(取决于具体设备数量)。在NoSQL数据库方面，我们意识到谷歌的定价明显更高。而在消息处理方面，AWS与Azure皆以消息数量为计费单位——不过二者对于一条消息的实际大小存在不同解读。AWS的单一消息为1 KB，Azure则为4 KB。举例来说，如果发送一条8 KB消息，其在AWS中将被视为8条消息，而Azure则仅为4条。根据我们的实际邮件大小以及近期用户数量计算，Azure的消息收发成本比AWS便宜约50%。
因此权衡各方面因素，我们选择了Azure作为自身物联网平台。
原文标题：IoT Platform Selection: Azure vs. AWS vs. GCP，原文作者：Hariharan Anantharaman
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
