物联网和多路访问边缘计算（MEC）：完美匹配

并非每一个主要的技术趋势都会落地到实处， 其中有些人是很好的技术，但很难实施。其他技术似乎目的是是寻找问题的解决方案。但是当你发现几种技术配合得很好时，就会加速它们的发展，因为它们会把共谋者聚集在一起，追求更好的东西。

这就是IoT和多路访问边缘计算（MEC）所发生的情况。

首先，一些闲话

人们以某种​​方式谈论物联网和MEC，这些方式有时并不合理。最让我感兴趣的是联网汽车。这个故事通常是这样的:如果汽车需要实时做出转向决策，那么汽车将无法将所有的道路数据发送到云端，因此必须有一个edge设备。

首先，完成这项工作所需的机器学习（最终是人工智能）包括两部分：训练模型和使用模型。为了训练模型，你必须获得大量的数据到一些资源池（“云” - 在这里引用，因为有很多可能意味着）。但为了开车，你将拥有一个本地生活的应用程序，使用该模型来指示行为。如果汽车没有连接，它就会工作，因为没有实时的要求将这些数据传输到某个遥远的云资源。所以当人们谈论自动驾驶汽车和MEC时，他们会把事情混为一谈。

你看，MEC中的ME（Multi-Access Edge）意味着有一个连接组件。如果你在本地运行所有东西，那么你只剩下C（Computing）计算，这基本上是一个应用程序。如果我们开始将所有应用程序称为MEC和IoT，那么我们基本上都会在2017/18年的大规模营销战争开始时大肆吹嘘一切。

物联网（IoT）和MEC

虽然有些宣传肯定是夸大了，但是物联网和MEC还是有很多不同的用例。

您可以想象一个使用Wi-Fi或LTE连接的智能城市作为零售中心。接入点是确定位置的好方法。因此，如果你在市中心有一个连接的区域，则访问Wi-Fi的用户基本上可以传输他们的位置。您可能想要使用他们的实时位置来提供上下文内容，从交易（附近酒吧提供特价饮料！）到交通协调（使用应用程序而不是执法来清除大面积之前或之后的区域事件）。如果您正准备在他们需要做出决定时截获某人，那么根据附近提供的数据在本地运行应用程序就非常合适。

或者，也许有一组物联网传感器分布在地理上偏远的地区。考虑采矿区或制造工厂。可能有数百万个分布在该地区的传感器，通过WiFi连接到本地IoT网关，这些网关本身连接到接入网络。如果这些传感器提供关于驱动实时可见性（如安全系统）或甚至实时自动控制的关键信息，则在本地托管这些应用程序是很有意义的。如果没有本地数据中心，那么MEC是一个很好的折衷方案，特别是如果在WAN链接的事件中需要继续进行行为时，公共云无法访问的时候。

哪个先来？

这实际上取决于您是否被一个应用程序驱动，该应用程序可以通过更多的信息或可以使用更好的应用程序性能的信息来改进。

对于大多数公司来说，人们可能会认为他们在使用有用的数据，但是大部分的数据源仍然是基本的后台应用程序，跟踪客户行为和库存。因此，出现的问题是如何将分支连接到这些大系统上，这就是为什么SD-WAN是如此的热。

如果是这样，那么使用SD-WAN作为创建额外的计算和存储表面的方法可能是正确的方法。可能不会有大量的分布式传感器负载，但是构建连接性解决方案，就好像在将来的某个时刻会为更多的实时的IoT类型应用程序做好准备。。最起码，它迫使您重新考虑什么是云，允许您利用分布式资源。

对于那些已经面对大量遥测信息的公司来说，这个问题可能更多的是关于如何处理这些信息。这些想法将从周期性调整开始(例如识别维护机会)，并逐渐接近实时操作。在这些情况下，首先要解决的问题是IoT数据的集合。

但即使在这种情况下，该集合也可能支持连接到某些访问解决方案的聚合点。这意味着，最低限度，人们应该考虑这些物联网网关的什么样子的。例如，为了满足实时应用程序的要求，甚至包括少量的分布式计算和存储，是否有意义？特别是在恶劣的环境中，依靠远处的云可能不切实际，因为当无法使用时，可能需要几天或几周的时间来进行修复。

底线

这里的基本点是，拥有大量数据将最终需要对这些数据进行处理。如果数据将用于定期更新以训练模型，那么具有连接性可能就足够了。但是，如果您想象在实时或接近实时使用这些信息，那么架构规划应该考虑如何将小型计算和存储表面正常升级的问题。

当然，对于这些工作负载表面的管理和编排会有一个更长期的要求，这开始将对话扩展到单纯的连接性之外。聪明的架构师至少要确定当前的决策并不妨碍未来的行动。

真正的妙语？当做出看似纯粹的连接决策时，即使稍微规划一下，也会为您节省大量时间和精力，特别是当您的部署将位于难以到达的位置时。