关于IoT的五个可预见性失败原因

日期: 2017-06-05 作者:David Rolfe翻译:陈晓诚 来源:TechTarget中国 英文

覆盖少量设备的原型实施,与支持具有不同软件和硬件级别以及间歇性连接的数亿台设备之间存在巨大差异。本文列出的失败原因都属于这一类——不会产生收益或直接影响用户体验的设备,因此可以在早期成功的阶段和敏捷软件开发的零碎迭代中,中途淘汰。物联网的不间断本质也会带来进一步的风险。一旦启动物联网部署,你就无法关闭,哪怕只是一会,因此日常维护也将面临挑战,激进的架构变更近乎不可能。

冷酷的事实是,你可以拥有“酷”,你会变得“不可靠”。你不能同时成为两者,而你让你的客户感到失望或不便,并且保留生意的次数是有限的。以下是物联网会发生的五个可预见性失败: 安全 还需要解释吗? 没有从初始就为大量部署进行架构 物联……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

覆盖少量设备的原型实施,与支持具有不同软件和硬件级别以及间歇性连接的数亿台设备之间存在巨大差异。本文列出的失败原因都属于这一类——不会产生收益或直接影响用户体验的设备,因此可以在早期成功的阶段和敏捷软件开发的零碎迭代中,中途淘汰。物联网的不间断本质也会带来进一步的风险。一旦启动物联网部署,你就无法关闭,哪怕只是一会,因此日常维护也将面临挑战,激进的架构变更近乎不可能。

冷酷的事实是,你可以拥有“酷”,你会变得“不可靠”。你不能同时成为两者,而你让你的客户感到失望或不便,并且保留生意的次数是有限的。以下是物联网会发生的五个可预见性失败:

安全

还需要解释吗?

没有从初始就为大量部署进行架构

物联网的成功将比以前任何技术都要更大,更“实时”。这意味着物联网系统必须毫不费力的扩展到大规模部署。我们指的不是“只有”50%甚至100%的复合年增长率——成功意味着在几年中,从1000个部署扩展到一亿。

几乎所有的云供应商都声称能够支持巨大的工作负载,而NoSQL供应商和开源项目也是一样。

我不会直接质疑这些说法,但是如果你想要试图通过组合多种技术,来搭建大规模的系统,需要考虑三个因素:

  1. 物理约束。跨越美国的单向传输需要大约60毫秒。这意味着如果你的应用必须与服务器长时间对话,而不是发送单个请求,则你的延迟可能会上升到秒数,当用户在远离单个数据中心的地方使用应用。限制也适用于数据中心。大容量网络在10GB /秒左右到达极限。要真正获得扩展,你的应用不能只放入一个服务器,你的应用的任何单个子系统也不能只放入一个服务器。
  2. 技术阻抗不匹配。无论单个技术的扩展性有多大,都不能保证在将它们结合在一起时,能获得高水平的性能,特别是当它们以不同的速度进行扩展时。
  3. 开发人员经验。你拥有多少开发人员,真正构建过一个拥有一亿用户的系统?他们是你的员工,还是外包人员,或顾问?我不是说你的员工不够聪明,但是他们第一次就能够成功完成吗?如果不是,还会有第二次机会吗?

没有预见到那些可能性不大的特定事件

常规软件和物联网系统之间的根本区别,是你对创建部署的环境的控制力不足。现实世界是一个奇怪的、混乱的和不稳定的地方,这种奇怪的行为也会体现在你的系统上。奇怪的是,一次性事件会频繁发生。假设你已经部署了一亿台设备,一个百万分之一概率的事件,大约每周会发生两次。要应对这一点,很多开发人员的心态都需要发生根本改变。不够偏执的软件将允许错误进入系统并传播混乱。混乱会导致用户体验不佳,反过来又会导致消极的看法 —或更糟。

无法预测和应对不断变化的物理复杂性

物联网系统的初始部署通常将集中在某种形式的最小化可行性产品上,随着时间的推移,将会增加更多的功能。但除此之外,成功将导致竞争对手的收购,与不同世界观的人的技术合作,受市场启发的“功能”失败,并被默默忘记,以及随着时间的推移而产生的不可避免的技术债务。

在传统的企业环境中,我们可以替换老化的组件,在物联网领域中,实际的东西并不属于你——它们由你的客户拥有,不能强迫他们停止使用他们的设备,他们期望设备一直工作,直到出现故障。这意味着,一旦你发货了一个设备,你就必须为它提供几十年的支持,除非你愿意让你的设备“变成砖头”,并对抗你的客户。

未能预测和应对不断变化的逻辑复杂性

随着你的物理环境变得更加复杂,你的软件堆栈也会更加复杂。本来是一个好的干净的部署,随着时间的推移,将变得老旧起来,大量过时的代码和越来越多的复杂的数据路径通过系统,当你试图应对不可避免的事实,你永远不能停止支持任何已发货的设备。

你的JSON是否暗藏问题?

文档数据存储在这种情况下是一个真正的问题。因为它们对于存储内容没有任何规则,所以你拥有的每一个数据库交互代码都需要能够理解每一个可能遇到的记录结构。在SQL数据库中,新列用于存储新数据,使这问题更易于管理。

你会如何平衡需要改进和需要随时随地保持在线的需要?

高可用性(HA)应用的大量问题,是需要预测罕见但危险场景所带来的副作用。创建和部署一个真正的HA应用,是一个重大的技术挑战;而长期保持它的运行则是更大的挑战。

在十年之后,你所有的开源组件是否还能获得支持?

比一个废弃的购物中心更让人伤感的,就是一个废弃的开源项目,特别当你还使用它时。虽然现在可以通过组合开源项目来构建复杂的应用,但持续的支持将随着时间的推移而变得具有挑战性。迟早一个或多个组件会被抛弃。到时候,你将不得不在架构更改和不会影响收益增加的中断之间进行选择,或者你能够修复任何发生的问题。至少,这意味着你需要保留编译整个堆栈的能力。