最近在研究边缘设备上的开发、运算和软件部署，学习了Microsoft Azure IoT和AWS IoT上各自的激活设置（provisioning）、验证（authentication）以及部署（deployment）方面的服务。两个平台在IoT终端上都不约而同地使用X.509证书的形式来对机器进行验证，以AWS IoT举例，设备只需要携带规定的证书，就可以通过核心的验证，从而使用Greengrass部署、本地Lambda等功能。然而这一验证方式却和AWS的其他功能完全脱节，在设备上与System Manager、S3和CloudWatch互传信息，都需要由IoT Core来作为中间角色进行双向验证和授权，和通常使用的AWS云服务时使用密钥即可完成验证、执行指令的方式非常不同。或者来说，整套AWS IoT的设计就和外层AWS的设计风格非常不同，AWS各个主要功能都是基于模块化来设计的，彼此之间相互独立运作，通过统一简明的接口设计可以彼此串起，组装起来应对不同的使用场景和要求，比如说在EC2的虚拟机上接收S3的数据，进行预测之后将结果发送到数据库中，将系统和软件的运算指标实时发送给Cloudwatch，超过一定阈值则触发SNS向客户发送警报，这其中基于具体的案例串起来了很多不同的功能，每个部分都可以独立进行更新、调换以及取消，这对于其他部分的正常运作不会有任何影响。而在AWS IoT中，一颗核心Core控制住所有其他功能，像是Logger、Connector、Device和Lambda，任何部分的更新都需要产生一个新的功能版本，且跟着其他部分来一起迭代出一个新的整体版本（group version），才能将这一个更新改变部署出去。多数系统上跨功能之间的沟通也都需要通过MQTT来完成，而在设备上通过传统IAM密钥的方式来进行激活和任务管理也缺乏best practice。

当然，这样的设计一开始可能主要是出自于边缘计算设备的限制，但是这就导致了IoT和其他主要部分之间的鸿沟很大，设计思路截然不同（简直像是两个公司出的不同产品），对于开发者上手也会增加额外的学习和适配的成本。而随着原本的思路产品不断演变、增加新的特性，彼此之间的鸿沟也就变得更大，在两者之间来回执行任务也会遇到更多的矛盾，缺乏好的参考样本。产品的开发都是有惯性的，一开始定下来的设计框架会直接主导未来迭代的方向和实践，因此在一开始定下一个正确的框架、或是一个能够包容和灵活接入相关产品的框架，对于产品的推广会有很大的帮助。