简要回答

采购通用能力，除非它限制你的产品；仅在控制或差异化证明永久运维归属合理时才自建。

实践要点

  • 两种选择都存在集成成本。
  • 托管服务转移而非消除了责任。
  • 退出路径有可衡量的价值。

推荐方法

  1. 列出不可妥协的产品能力。
  2. 为运维、合规和迁移定价。
  3. 在承诺前对最难的集成进行原型验证。

边界与故障模式

  • 仅比较许可成本与开发者薪资。
  • 构建了一个代理就称之为平台。
  • 忽略服务退役和区域可用性。

范围与决策边界

将连接、身份、注册表、消息、状态、规则、存储、设备群运营和产品工作流分解。不要为模糊的“平台”选择一个答案。将每项能力标记为差异化的、必要的通用能力或实验。运行开源产生运维归属；集成托管组件仍需要架构和治理。

决策标准

当某项能力体现专有领域行为、随产品学习而变化，或需要提供商无法提供的控制时，自建。当标准和提供商覆盖需求且内部运维不会改善用户结果时，采购。

计算永久运维：升级、安全补丁、分布式状态、容量、可观测性、值班响应、备份和恢复。测试协议行为、SDK 占用、网络位置、租户隔离、导出、配额、维护窗口和故障可见性，而非比较功能清单。

跨文档化的设备群场景建模生命周期经济。包括集成、迁移、支持、合规、转移、空闲环境、事件人工和延迟的产品工作。保持假设可见；推测性总计不是精确预测。

标准协议减少但不消除锁定。设备凭证、标识符、模式、规则、设备影子、历史数据和运维工具需要有演练过的退出方案。

决策流程

  1. 分解能力和事实来源。
  2. 分类差异化和所需控制。
  3. 编写通过/失败的安全、可靠性、驻留和互操作性要求。
  4. 用生产形态的设备对最高风险集成进行原型验证。
  5. 测试中断、配额、升级、身份轮换和导出。
  6. 从明确场景估算生命周期成本。
  7. 在采用专有语义之前设计并演练退出方案。
  8. 记录假设、被拒绝的替代方案、负责人和审查触发条件。

混合设计应保留规范的设备和租户身份以及产品模式在直接治理之下。提供商适配器需要明确的边界，而非在最低公共层之后抹去有用的原生功能。

故障模式

因为看起来小就自建代理或 PKI 忽视了数年的运维工作。购买一体化套件可能将领域语义强塞入专有模型。成本比较遗漏值班人工或网络费用。混合系统可能让团队拥有不透明的粘合代码，同时缺乏双方的可见性。一个从未恢复过凭证、配置和数据的名义导出不是退出方案。

实施清单

  • 范围已分解为归属能力。
  • 差异化和通用基础设施已明确。
  • 通过/失败要求先于评分。
  • 运维和安全响应有指定负责人。
  • 成本包括人工、事件、集成和迁移。
  • 身份和模式保持受治理。
  • 专有依赖已盘点。
  • 故障和退出路径已演练。

证据与治理

决策记录应列出能力边界、要求、工作负载假设、试用架构、故障结果、成本输入、安全例外、被拒绝的替代方案和负责人。保留未验证的内容。精良的加权评分可能隐藏一个失败的硬性要求，因此将通过/失败门禁与偏好分开报告。要求架构、安全、运维、产品和财务审查人员签署他们所负责的假设。

对于提供商试用，测试设备注册、凭证轮换、租户分离、重连风暴、下游中断、配额耗尽、区域受损、维护、支持升级、配置导出和历史数据提取。对于内部自建，测试节点替换、备份恢复、滚动升级、依赖故障、值班诊断和安全补丁投递。使用相同的产品形态消息和设备使比较保持有意义。

定义审查触发条件而非随意的年度仪式：重大价格或配额变更、新的驻留要求、收购或弃用、设备群形态变化、无法满足恢复目标或产品能力变为差异化。重新审视受影响的能力而非默认重新开放整个平台。迁移工作应有明确预算和客户影响。避免永久的“临时抽象”——它复制提供商行为却不给团队带来可移植性或原生运维可见性。

决策后指定一个有责任的负责人。采购不拥有服务架构，构建了某组件的团队也不能将运维视为他人的问题。发布服务目标、依赖图、升级路径、预算告警和弃用计划。所选选项仅在普通工程师能够诊断、恢复并解释其故障边界时才达到生产就绪。

保持实验有时间限制。因惯性而成为生产的试点可能在安全、支持、成本和退出获得批准之前就获得了敏感数据和可用性义务。从试用到生产的晋升需要明确的架构和运维审查。

主要参考来源

使用NISTIR 8259A了解设备网络安全能力，使用OASIS MQTT 5.0 规范了解消息互操作性。在每个提供商的官方文档中验证当前配额、导出、安全、共担责任和生命周期声明。