最近代表公司首席科技执行官对AWS和Azure IoT平台进行了详细的测评，为公司IoT战略做出了指导性建议，公司的具体战略方向我就不说了，因为这涉及到很多其他要考虑的方面。但是我本人的建议应该可以给大家很多启发。如果你们公司也在考虑选择IoT平台，或者你考虑着朝着IoT方向去创业，一个好用，实惠的IoT平台是必不可少的。
首先澄清一下市面上的IoT平台，因为你随便一搜, 一大堆，根本无从着手选择。
分两类：
- PaaS类
就类似AWS IoT或者微软的Azure IoT Hub了，他们提供一个serverless 的底层的IoT平台，你不在需要去管理自己的服务器，虚拟机了。他们帮你都打包弄好了。这个在我看来是未来几年的IoT的趋势之一。因为如果进行IoT部署，设备数量和数据量的快速增长，马上就会让一开始选择的服务器不堪重负。我想起来我最早创业时，自己弄了个AWS EC2，然后在上面跑kafka，然后在IoT设备上写kafka publish，把数据推到cloud上。5个设备，管理起来简直要我们命了。。。所以，serverless 的IoT平台让你没有后顾之忧，无论你的规模未来会增长到多大。这也是我这篇文章主要要讲的。
- 优点：不用自己管理服务器，可以理论上无限增长计算力和设备数量。
- 缺点：需要自己开发自己的IoT方案。
2. PaaS + SaaS类
这类东西现在是群雄逐鹿，各种公司各种IoT 平台，比较“牛逼”，混的比较好的比如 GE的predix，西门子的MindSpere, PTC 的Thingworx等等。初创公司的话比如C3 IoT等。可以负责人的告诉你，像GE 的predix在数据分析的比拼中被某初创公司完爆了。所以大公司，有时候，没啥用，真的。这种IoT平台呢， 他们就是自己管理服务器和虚拟机，你可以在他们的IOT平台上部署IoT方案。他们是在AWS 或者Azure，Google cloud之上的，但是技术是自己的技术，仅仅租用cloud端服务器而已。
- 优点：可以帮助你各种个性化，满足你的需求。这些公司往往都是某个工业领域的老大，他们会集成他们的平台和他们现有的机械设备。
- 缺点： 贵，而且会被绑住，到最后你会发现个性化其实是一个累赘，每次个性化都要花钱，花钱花到最后你的IoT方案会是一个另类，然后和其他的平台完全不通，然后改又得花钱。彻底套住。
3. 完全SaaS类
这种公司就更多了，全都说自己各种各种牛逼，可以做这个做那个。但是你只要稍微懂一点，你就会发现，他们丫的全是基于AWS 或者Azure之上，利用人家API开发的。充其量就是在比拼谁的UI做的好看而已。比较这类IoT服务，其实就是看他们用API用的怎么样，有没有把各种功能搞齐全。然后UI好不好用。公司嘛, 比如刚刚获得微软Inspire大会年度最佳partner的Codit瑞士公司。
- 优点：啥也不用你干，完全解决方案公司。到手是人就可以用。
- 缺点：目前这些公司还不成熟，产品存在一定的缺陷。而且他们的产品很大程度上取决于大的PaaS服务商。
接下来开始真正的对比1类中的AWS IoT和Azure IoT
不想看过程的，可以直接跳来跳去看每个类别后的结果和总结！
IoT 平台： AWS IoT 和Azure IoT Hub
对比范围：
- 设备管理
- 边缘计算设备功能和管理（edge）
- 安全性
- 价格模型（在终极总结里提到）
一个一个讲啦:
- 设备管理：
- 设备注册
- AWS IoT
这就是一般那些销售都会跟你说的，你看我们注册设备多简单，是人都会弄。但是实际上，以上操作只是在AWS IoT core（他们的IoT云端平台的界面）做的事情。实际上你的设备哪TM知道你帮他注册了。。。所以，最麻烦的事情莫过于把你下载的证书和公钥私钥放到你的设备上。相信我，这绝壁是一件让你痛苦的事情。我当时用的树莓派，用SSH和SCP传文件，结果公司内网问题，导致就是连不上。。。哭死。
总体评价：还是挺不错滴，UI简单易用，基本上所有事情都可以UI解决了。如果你是大神，也可以用AWS 提供的command line环境，需要在操作电脑上装一个SDK，然后用你的AWS user的账号密码，然后就可以进行代码命令行操作了。步骤原理都一样。但是你可以想象利用代码你就可以自动化，成批的注册设备了。一会儿下面专门会说。
- Azure IoT Hub
你要先在你的Azure resource group里添加一个IoT Hub。步骤看这：Use the Azure portal to create an IoT Hub
然后呢在IoT hub的右边找到IoT Devices，然后点那个“+”号，添加一个设备。见下图。
填完之后你以为就完了？当然不是，上面不是说了么，你的设备哪知道你偷偷帮他“办了身份证”。现在你得把身份证给你的设备。在设备信息里会有它的key，有两个，随便选一个都行。然后你得把这个key放到你在设备上的程序中。是的，程序中。你想要设备给你发信息，你当然要放一段代码在你的IoT设备中让它发数据对吧？ 那这个key，外加你的IoT hub的url，都是要放到你的代码中的。具体下面会讲怎么弄。
总结一下，AWS IoT和Azure IoT hub都支持命令行和api，所以你可以完全自动化整套流程。aws我们用notebook写了一堆代码，加起来好像也就100多行？就完全ok了。但是如果不比api和代码命令行。AWS IoT完胜！Azure的UI做的就跟屎一样。如果你一个小公司，或者自己家里搞IoT玩玩，想快速上手，首选AWS IoT。
- 数据图像化和警报
- AWS IoT
按照上面注册好设备后就可以让设备发点数据到云端玩一玩了。
首先呢，你要按照AWS的教程，下载适合你IoT设备操作系统的SDK。其实就是个Start.sh的bash文件，你把它放到你的IoT 设备上然后运行，他就会自动给你下载root证书，然后安装设备SDK，SDK类型也可以根据你的编程语言选择。
弄完之后你要写一段代码，里面大概就是调用SDK里的一些方法，然后定义你的证书，私钥等。然后要publish什么数据到IoT core里面。我用的raspberry 和sensehat，其实就是发一点sensehat的温度感应器的数据到IoT Core上面。
AWS IoT采用的是MQTT，或者通过HTTPS的MQTT，所以你要把数据发到一个话题（topic）里，在IoT core云端有一个topic broker管理这些topic的。
AWS很人性的，做了一个test的功能，进去后就能注册到相应的topic里看看有什么信息在里面了。
当你看到有信息时，那就证明有数据不停地从你的设备发到IoT core了。
AWS提供一个简单粗暴并且好用的图像化方法。当然这不一定是最后的用户界面，不过已经很好用了。
它就是cloudwatch。具体怎么弄我就不详细说了。里面可以自己设置metrics，然后做dashboard。还可以设置alarm预警。设置简单的threshold很容易。它还可以把其他很多系统的信息也展示出来，所以不仅仅是感应器数据信息哦。
- Azure IoT Hub
Azure IoT 也是差不多，你也要在你的设备里安装SDK然后放一段可执行代码。 Azure也是用的MQTT protocol，它也支持AMQP和https。但是主要还是MQTT为主，所以我就不展开了。记得之前注册设备的时候选的symmetric key吗，Azure会有一个主key一个副key，你需要把这两个key，然后加上IOT hub的url放到你的可执行代码里。
但是以上数据都发到IoT Hub里了，据微软官方文档，数据发到IoT hub会保存7天。然后如果你要图像化这些数据，IoT hub还真没有直接可用的service。PowerBi可以，不适合做实时数据的展示，而且我并没有测试，我这里就不乱评价了。如果没有图像化，你能看到的就只有terminal里面的黑底白字的命令行返回值.
要图形化，最后我们的解决方案就是用Time series insights（TSI），这是Azure另外一个服务，相当于一个单独的服务器然后运行那个TSI软件。可以直接接IoT hub里的数据，根据device ID或者其他数据里的属性信息提取相关数据，可以实时展示，也可以设置预警等。不过，价格就贵了，因为毕竟要单独弄一个resource group，单独的服务器。长这样 （网上搞得图，可以同时看很多数据源，但是！但是！但是！重要事情说三遍！这个TSI是最唬人得一个图形化工具了。。。乍一看以为是实时得，但是其实根本不是，而且没法设置成实时，连powerBI都不如。。。问了微软的人，他们说这个东西就是给工程师把所有时间序列数据列列出来然后对比着看得，我去=.=）：
至于预警，Azure还有一个单独的服务，叫Logic App，利用Azure streamanalytics 和service bus把IoT Hub的数据接近去，然后logic app从service bus里读取数据，可以设置警戒值。然后报警后Logic App可以触发邮件，skype，或者短信，反正应有尽有。
总结啦： AWS的cloudwatch功能不错，用起来很方便，价格也便宜（具体没算，但是测试时候几乎没花钱在cloudwatch上）。Azure 的TSI和Logic App也不错啦，功能上都能满足，TSI甚至可以提供更多。但是我只能说根据你的需求来吧，一开始就上TSI会让你费很多钱，一个普通的instance一个月100多欧至少。
这一轮，我个人觉得AWS IoT胜。胜在简单，但是功能不少。
- 设备批量注册
- AWS IoT
真心没什么好说的，到时候有兴趣可以问我要代码，AWS IoT没有单独的服务用来批量注册设备，如果要批量注册设备，就只能用他们的API自己写一些代码，代码主要声明了执行代码的权限，一般把AWS IAM里面专门设置的用户的密码什么的，然后具体逻辑就是如何定义设备的名字ID，然后要利用API生成一个证书和公钥私钥，然后每个设备的证书记得加上规则。然后就ok了。 当然这还不够啦，具体执行还要稍微变一下，因为批量注册后你总不能把证书和公钥私钥一个一个放到你的设备里边去吧。所以， 我们要用到CSR（certificate signing request）和AWS的JIT （just in time）注册方式。
大概意思就是你通过CA 弄一个公钥私钥，然后用你自己的私钥弄一个你自己的证书，注册这个证书，然后利用私钥做一个验证的证书，再用这个证书去制作一个CSR。然后再用CSR做一个证书，这个证书注册到AWS IoT的CA那。激活那个证书，然后需要附上你的批量注册模板，这个模板一般嘛可以放S3里面，一个json文件，随时调用。最后，用那个激活并且附有模板的CA证书，再去做你的设备的证书。然后把证书放到设备里。
等一下，怎么又要放到设备里！！！ 没错，怎么样都逃不开放到设备里。但是现在我们的证书并没有被验证，不能直接用。所以，放到设备里这个行为可以通过设备固件升级，或者厂家在生产这个设备的时候就完成。到时候设备一联网，就可以去AWS IoT进行验证，只有用咱们注册验证激活并且附有批量注册模板的证书制作的设备证书才会被验证成功。其实这个方法还是很聪明的。但是解释起来真的很烦。看下图 （我承认还是需要一些PKI和密码学的知识才能彻底弄懂的)。
- Azure IoT Hub
Azure就有的说了，他们做了一个叫Device provisioning service的东西，以下简称DPS。这个东西设计的很巧妙，不仅完成了AWS IoT上面的这一套验证，还能避免以后IoT hub url变换或者其他变动导致的提前被放入证书的设备（在工场里就被放入了证书）也能注册成功。
大概意思就是说，IoT设备和IoT Hub之间加了一个服务，DPS，这货呢可以帮助你完成注册。Azure一般的单个注册呢不是需要一个key和IoT hub的地址吗，如果这个IoT hub变掉了，但是那些key什么的已经通过IoT hub生成，但是还没注册，那这个设备不就废了么。。。所以，DPS就不需要你的key和IoT hub的 地址啦。
DPS提供一个唯一的全球地址，所有设备都连那个，不会变的。然后呢，它还需要一个scope ID，这个ID用来定义你这个设备是属于哪一类的，这个是一般不会变的，比如我要批量注册一堆温度计在工场，他们都会尊从差不多的注册模板。那这些设备我们就给他们一个scope ID，然后注册模板存在云端，随时被DPS调用。然后只要那个设备连上网，它就连到DPS，DPS就会根据它的scope ID去帮他完成注册到IoT hub的行为。即便IoT hub地址变了也不怕。DPS随时调整，不影响新的设备注册。
总结：AWS IoT虽然也可以完成要求，但是明显麻烦很多。而且考虑的不如Azure IoT齐全。微软不愧是玩企业用户的高手，一切都会从企业扩张，快速产能化去考虑。
不过不管用什么方式，都要想办法把证书和一小段代码（初始联网后运行的代码）放到设备中，可以通过CA root 根证书制作中间证书的方式发给生产企业，让他们利用中间证书再制作子证书放到设备中。或者，通过设备固件升级放进去。
这一轮，Azure IoT 胜的无悬念。
- 设备管理（Indexing和IAM）
- AWS IoT
Indexing：
AWS IoT在注册时候给设备分的组，还有各种属性等都可以用来做快速的查询。AWS IoT专门做了一个google 搜索差不多的东西，但是专门用来在IoT core搜索IoT设备的。我用后发现体验相当的好。原来和google差不多，AWS会把你所有的设备的属性，id等各种数据给做index，这样搜索起来就非常快。搜索框不仅支持模糊搜索，还可以自己写一些搜索的SQL语句。
IAM （identity access management）用户权限管理
这个IAM，我最开始想测试的是如果让不同的用户只访问特定的IoT设备。但是最后发现AWS IoT现在根本没有这个功能！唯一可以用的解决方案是通过最后做图表展示的时候强制过滤（利用indexing 的api），然后根据用户名显示只给他们看的东西。换句话说就是要自己写代码在dashboard上限制。不过那样操作起来不是特别灵活，量大了后管理会很麻烦。要不然就是弄多个AWS IoT core的账号去给设备分类。
我被他们反问，为什么需要这样的设置。因为目前没有人向他们提过这个要求。其实应用场景很简单。假设一个公司在北京某工厂有10000个感应器设备。这些感应器监测着一些机器设备。然后数据用来分析并且根据分析结果进行设备维护。这个公司自己没有数据分析部门，所以外包给另一个公司来管理这些感应器并进行数据分析。但是这10000个外包给了100个公司。他们分别管理100个感应器。难道我在建设之初就想好了然后建了100个AWS IoT core账号？要是后来变了怎么办。且不说建那么多IoT core 的账号是不是浪费钱，操作上也完全会乱套。所以AWS IoT没有相关解决方案。可惜。
对于第三方资源访问IoT core的IAM管理，AWS还是使用自己那一套User，policy那套东西。就是你可以给某个action，比如lambda function定义一个role，然后那个role你给加几个policy，这些policy就会限制那个role做某些事，访问某些资源。基本上我觉的ok的。
- Azure IoT Hub
Indexing
微软这个东西做的我就要来吐槽一番了。咱先不管用户用api自己开发的UI能多方便多好用。但是同样的和AWS 比，Azure 的搜索长下面这样。
这个sql代码框得按照sql语句的格式写，写错了就不会出任何结果，但是也不会有任何提示。反正超级不好如果你不是sql数量使用者的话。但是毕竟这个UI不是给最终用户，而是给开发者用的，勉勉强强吧
IAM （identity access management）用户权限管理
这个东西也没啥好说的，难兄难弟， 反正目前都没考虑到这个问题。我觉得主要原因可能是IoT在实际使用中还没有出现那么大的量的应用案例，也没有实际需求。所以两个公司并没有把这个功能放到roadmap上。不过，这是一个很必要的功能。
这是IoT设备方面的，我们来看一下第三方app对于IoT hub的访问控制, 做的还是ok的。
总结：
在设备索引上，AWS 反正还是做的略胜一筹吧。
IAM上双方差不多，没有特别牛的。但是两者都没有在设备IAM上下功夫，如果你的企业有这方面的需求，目前这两个公司都没法满足。
- 远程监控和控制 （对设备本身，不是数据）
- AWS IoT
这里我们讲的远程是针对设备本身的，如果你说你可以根据它是否发送数据来判断这个设备是否正常的话，逻辑上也没问题。但是有时候我们需要把设备状态数据和telemetry数据给分开处理。不然每个数据包的数据量就会变得很大，而很多IoT平台它对每个数据包的大小是有限制的，即便没有限制，也是按照数据包的大小来算数量，然后计费的。比如AWS 按照5kb每个数据包来计算，每一百万个数据包收费1美元。但是如果你每个数据包时8kb，它不会把你限制你传送，但是你这个数据包就相当于两个。收两份钱。
那AWS 的远程监控怎么样呢？AWS实际上没有现成的服务给你做远程监控设备状态本身的，所以需要实时了解设备本身的状态，比如是不是在线，设备的证书是否过期等等，还是要通过API来实现。之前说过AWS 有一个cloudwatch，那个很好用，可以用来监测设备发送的telemetry，但是没法监控设备本身的数据，我看了cloudwatch 的metrics，还是有局限的。
远程控制AWS是通过job来实现的。包括可以让设备重启，固件更新，关机等等。 实现这个需要在设备上上传一段代码，这段代码主要就是会监听一个job相关的MQTT topic，然后通过IoT core发一个内容到这个topic，设备检查到和自己相关的内容就会启动代码去AWS 的S3上下载一些东西,这些东西可以是固件升级的固件啦，或者其他的，比如说设备属性更新，更改的模板等等。或者就直接执行重启等指令。还是比较方便的。
- Azure IoT Hub
Azure竟然又和AWS一样，对于设备本身状态的监控也没有现成的服务，也要通过API实现。不过呢，Azure比AWS稍微好一点的是人家至少做了一个界面显示设备的状态。我一开始觉得，哟，不错哦。后来发现这个数据过好久才更新一次，根本没什么卵用。到头来我还是用API command line去看设备的状态。
远程控制的话，Azure和AWS差不多，只不过在Azure这里，他们叫它method。而且还做了个界面，可以方便使用，真的方便吗？咳咳。
总结：
远程监控和控制上面双方使用的方式都差不多，利用API基本上都可以实现。Azure在远程控制上面利用method，并且可以编辑和添加method给设备。都可以在portal界面操作，这个还是不错的。
我觉得，两者打平吧这局。
2. 边缘计算设备（edge）功能和管理
先说一下edge computing，其实没有特别复杂。简单的说，由于各种原因，比如上传数据太大（比如图片视频），或者条件限制（偏远地区，网络不好），或者一堆dumb的感应器只能发送简单数据但是不能做任何运算，这个时候就需要一个有一定运算能力，能连接云端的一个设备（比如电脑，路由器，树莓派）。然后这个设备会运行一个操作系统（比如linux，FreeRTOS），然后基本上就可以编程随便玩了。即便没有网络，也可以部署一个机器学习的模型在这个设备上离线处理各种运算，比如图片识别，视频识别啦等等。最后只要把识别结果在有网后上传云端就ok了。
下面我们来讨论一下我具体测试了啥：-）
- 边缘设备注册到云端
- AWS IoT
AWS IoT 的Edge computing产品叫做Greengrass（然后他们会推出各种grass，”草“ 的衍生产品，很多都是roadmap，我就不说了。。。名字也是挺别致的==）这个Greengrass简单的说就是一个云端的IoT Core的线下版本。我问了AWS的IoT专家，这就是一个mini版的IoT core，叫做Greengrass core。
ok,具体要把edge设备注册到云端非常的简单，在AWS的console里的Greengrass的项目里有一个Group，一个Core，一个Device。要注册一个设备，首先要弄一个group，这样就可以方便管理这些设备。然后每个group都要有一个Greengrass core, 这个core就是edge设备。原理和在IoT Core注册设备一样。（会有公钥私钥还有证书可以下载，然后要放到这个edge设备上）。然后么就会要你下载Greengrass core的SDK安装到edge设备上。
总体评价，还ok，挺直接简单的。
- Azure IoT Hub
微软这个整体思路也差不多。然后要在设备上装一个他们叫IoTedgeRuntime的东西，然后就可以在Azure portal上看到那个IoT Edge,包括一下状态啊之类的。
总结：
AWS 和 微软 的edge设备注册整体思路都差不多，而且做的也很简单，比较容易操作。这一轮，不过AWS有一个很严重的问题，就是只要Edge里面任何一个东西更改后都需要重新部署到Edge，也就是在重新部署的那几秒里Edge是停止工作的。基于这一点，AWS暂时用的技术还是有一定缺陷。（虽然这个缺陷有点严苛，并不一定会影响绝大多数的需求。。）这一轮微软Azure胜。
- IoT设备注册到边缘设备
- AWS IoT
反正很简单，就像普通注册设备到IoT Core一样，有证书，各种公钥私钥啦，然后就搞定了。不过，需要注意的是，这些设备是注册到Greengrass的，而不是注册到IoT core的，所以在设备上部署一些软件的，代码的时候，需要把IoT core end url 换成Greengrass 的 end url。不过反正一个思路啦，没什么复杂的。
- Azure IoT Hub
微软在这里的操作和AWS有着巨大的不同，并不是像注册设备一样注册到云端的方式，而是运用docker来把一个功能（接收数据）部署成为一个模块。但是缺点是，这样的话就无法直接连接设备，无法直接进行管理，只能通过模块里的功能来监测比如设备的状态等。不过好处就是，所有被部署成模块的docker container都分别运行，不互相影响。换句话说就是如果其中一个模块有改动，需要重新部署到edge设备，并不需要重新部署其他模块。但是AWS却要在每次一丢丢的更改后整个edge runtime 必须重新部署。
如果是非常critical的物联网解决方案，对及时性和稳定性要求很高，那重新部署的那几秒钟就会导致整个方案暂停，接收不到实时数据，导致不能及时在edge端对数据进行分析从而预警。
这个是一个特别严重的问题，我当时发现这个问题后AWS的两哥们哑口无言，只对我说通常不会有很大影响，而且部署完之后一般也不会那么频繁的去更改。他说的其实有道理，但是这就是一个缺陷，而且是不小的缺陷。好在，这个东西会在roadmap中解决，他们已经提上日程了。
总结：AWS 和 微软他们在 设备注册上Edge设备上的技术选择不一样，产生的结果也不一样。AWS让注册设备到Greengrass和注册到IoT core差不多，也比较符合正常人对设备管理的思路，操作简单，我觉得挺好。微软Azure，我说的严格一点，就根本没这个功能，只能部署相关功能模块，算不上设备注册。
如果不好好分析和测试，可能觉得AWS比Azure要好，但是仔细研究发现微软的docker contrainer的技术解决了AWS Greengrass需要重复部署的问题。这个问题可大可小，但是对于大企业来说，这总是一个缺陷，有潜在风险。
所以，我最后觉得Azure在这轮险胜，因为我觉得虽然它本质上无法注册设备，但是通过模块的功能，基本上可以实现各种所需。
- Edge的规则部署
- AWS IoT
AWS IoT Edge的各种规则和模型部署主要采用两种方式：1）Lambda 功能2）Resource （资源部署）。 Lambda是AWS一个非常牛逼好用的服务，可以自动化部署一些简单的功能，然后和AWS里面很多的服务互相激发，互相使用。同理，比如你要设置一个过滤器在Edge设备里，用Lambda绝对是一个很快捷的选择。
选择用Resources，可以让Greengrass调用AWS里面其他的各种资源，比如S3. 你可以把机器学习的模型存在S3，然后利用Lambda在某个特定的时候或者时间进行调用。或者可以把Greengrass的升级固件存入S3，然后进行远程OTA升级。
如果考虑到scalability，AWS可以通过API实现，说白了你要部署一个规则，机器学习，你在AWS console上只能一个一个弄，但是通过API可以自己用代码自动化这个流程，部署多个设备。技术上没缺啥，但是用着不是那么方便。
- Azure IoT Hub
微软Azure IoT Hub在处理这个上面和AWS又是不同的技术方案。其实我上面已经提过了，微软利用基于docker container 模块部署的技术。可以部署各种功能 （就像上面提到的数据过滤器来接收数据）。也可以部署机器学习的模型，主要有三大类模块可以部署（都是要自己写代码的）
但是微软的整个流程稍微有点“复杂”的，但是也可以接收的。
就是模块部署的时候你不是把东西直接弄进edge设备里面的，而是要建一个registry的container，然后把你的各种模块都存到那个container里，然后在设置模块的时候选择相应的container。所以这里面有一个编写功能模块然后上传到container的过程。反正我个人的体验不是很好，但是如果弄的多了应该会比较熟，更快吧。反正觉得比Lambda麻烦（个人印象）
但是，微软牛逼的地方在于他多年服务于企业，他会考虑到scalability（扩展性），所以部署module（模块）的时候，他在他的portal里面有设计一个bulk deployment model，可以添加一个label，然后部署一个module到一堆设备上。
总结: AWS对于小数量的规则，模型部署，还是非常简单方便的。但是如果要大规模的部署几个规则（比如你家厂里1000个感应器设备），那你就只能自己去用代码把这个流程loop自动化一下了。微软Azure呢， 那个registry，contrainer的方法逻辑上没啥问题， 但是实际操作起来，我遇到了不少需要troubleshoooting的地方。只能说熟能生巧吧。我在这里不能质疑这个方法本身的问题。
所以，在考虑到scalability的基础上，Azure胜，但是如果对于初创公司来说，AWS应该是不二之选。我站在我给打工的公司的立场上这一轮票投给微软Azure IoT Hub。
- 机器学习模型部署
因为我把机器学习在上面那块提到了一下，这里我就不再机器学习模型这块再具体展开了。结论和上一轮一样。
- 离线功能测试
大概先讲一下我的整个设计流程。
大概的流程：
温度感应器和Alarm（报警器）作为设备连接到Edge，然后Edge设备连接到云端。
- 运行温度感应器将，收集的温度发给Edge, 频率为每秒钟一次。
- Edge设备收到数据后利用部署的规则（我们部署了一个简单的规则，温度超过40度就报警）触发报警动作。
- Alarm收到Edge设备的报警数据，然后点亮SenseHat的屏幕，提醒用户温度超标
- Edge设备同时把触发的警报结果同步到云端。
- 把Edge设备的互联网连接断掉，然后重复上面的步骤。
- AWS IoT
评价一下AWS，我们在第一次调试的时候遇到了不少问题，本来预计一两个小时的事情搞了一上午。我当时都有点不耐烦了。就是Greengrass不知道为什么在断网后连上网后就无法自动同步数据到IoT Core。反正最后谁也没弄清楚到底是什么原因。解决方案就是把整个设备的系统都重新装了一遍，然后就好了。。。
我不管你东西到底有没有问题，但是这个debugging的功能几乎没有啊，只能看log文件，那一堆堆的，看起来简直是一种折磨啊。经验丰富的AWS工程师也没法快速确定问题所在。我可以很负责任的说，troubleshooting有很大的问题。要么不发生问题，一旦发生问题，修复起来绝对折腾死你。
- Azure IoT Hub
Azure在这里用的方案就是在Edge部署一个module，这个module用来接收温度数据。然后再部署一个数据分析的module（其实两个module可以放一起，我们分开是为了让各个module简单一点，各司其职，出了问题好debug）。数据分析的module分析数据触发警报，然后警报发到alarm（警报）感应器，然后SenseHat显示结果。因为微软不像AWS的流程那么简单，（因为AWS全程都是MQTT和topic broker）。微软就是要部署module（模块）。所以我附上一张微软离线测试更详细的流程图：
效果还行，没出现什么大问题。 但是我要提一下的是，其实在Edge端部署机器学习模型的时候，出现了很诡异的问题，就是module部署完之后，检查部署成功。然后过了几分钟，module自动消失。。。部署失败。。。也不知道是什么原因=。= 彻底扎心。。。 Azure和AWS一样，完全没有一个troubleshooting的服务。也是看Log。。反正不是特别好找问题，导致最后的解决方案就是重装系统。。。（微软windows经典解决方案适合他们任何产品。。。）
总结：
离线模式这个很基本的edge功能，AWS和Azure都有，而且都正常运行，经过了测试。但是他们多多少少在部署的时候都出现一些问题，而我们在troubleshooting上花了不少的时间。最后我觉得只能在这一句给双方一个平局。
终极总结：
安全性测试我并没有专门设计测试方案去测试，而是在其他测试中进行观察。结论就直接写上面的啦。
然后关于第四点，对，我并没有忘记。价格模型我觉得会影响很多公司的选择。AWS的pay-by-use的方式非常适合小公司，初创公司。很多时候做个测试，PoC什么的，几乎都花不了几个钱，但是微软的价格模型却是分梯度的。用户需要估计一个大概的使用量去选择相应档次的服务。如果估计不当，或者后期快速增长，都会对价格有很大影响。
AWS的价格模型详情可参考：https://aws.amazon.com/blogs/aws/aws-iot-update-better-value-with-new-pricing-model/
Azure的价格模型细节参考：https://azure.microsoft.com/en-in/pricing/details/iot-hub/
最后附上我个人的推荐：
AWS IoT和微软Azure IoT Hub可以说是目前世界上最好的两个中心化的IoT平台了，Google的云平台就不是特别行，IoT暂时就不去看了。阿里在17年刚开始推出IoT服务，起步有点晚，但是下次有空可以和Google做一次比较评估看看。
凡事选择都需要有一定的条件，别人用的好的未必适合你。
- 如果你是初创公司，我建议选择AWS。 如果是大公司，建议选择微软Azure，微软企业级服务还是有一套。
- 如果你的业务需求对Edge要求不高，比如edge停止工作一小段时间对业务并无影响。那选AWS。否则选Azure
- 如果你对自己业务需求量估计不足，公司扩展并不稳定，建议AWS。反之则选择Azure。
- 如果追求scalability，公司有一定的开发能力，建议选择AWS。如果要尽量追求全权托管服务，那选择微软Azure。
- 个人初学者想学习一下IoT 平台，建议AWS，因为便宜好用。
- 智能家庭IoT部署，我觉得选择AWS也会让你的成本更低。
最后，这整个文章都出自我个人观点（根据实验测试），并且微软和AWS都在对他们IoT平台进行升级。所以，很多我指出的问题他们可能已经修正。我的测试时间是2018年4-5月，有什么问题欢迎指正。有什么观点请随便评论，我会及时回复讨论。
