服务网格做好被广泛采用的准备了吗
服务网格就像一辆电动汽车，你的朋友在谈论它，它很时髦，但是你还没有拥有。你可能希望稍等一下，看看其他人如何对其进行管理。但是，这种感觉就像是下一次技术演化。
服务网格是一个新兴领域，软件历史上从来没有任何软件100%准备好了才被使用。未来很难预测，但像Kubernetes和Envoy这样的基础技术将是管道
专家组就服务网格的成熟度进行权衡
服务网格就像一辆电动汽车，你的朋友在谈论它，它很时髦，但是你还没有拥有。你可能希望稍等一下，看看其他人如何对其进行管理。但是，这种感觉就像是下一次技术演化。
近几个月，服务网格已经引起了广泛的关注——它们有助于解决采用微服务架构后出现的许多问题。但是服务网格是否准备好供所有企业使用呢?事实证明，支持者并不认为这项技术已经100%做好被广泛采用的准备了。
11月18日举行的北美2020年服务网专题讨论会上，该领域的思想领袖有：Mat Klein，Lyft;Manish Chugtu，VMware;IBM的Dan Berg和Idit Levine，Sol***。总体而言，小组成员承认服务网格领域当前的积极发展，例如Envoy周围的整合。他们还强调了它的许多好处，包括为微服务体系结构增加了联网、可观察性和路由功能。
但是，我们仍然没有看到足够的服务网格生产用例。并且，每个网格框架仍在成熟当中。使用服务网格的权衡包括增加的等待时间，陡峭的学习曲线和持续的维护开销。网格间互操作性缺乏明确的标准化可能是另一个问题(SMI是一种提议的格式，但是现在行业似乎更倾向于Envoy的xDS API)。
所有这一切并不是说它不会成为公司未来基础架构的关键部分，也不是说它不会为需要的用例提供有用的功能。简而言之，服务网格是一个新兴领域(这就是为什么该小组如此吸引人的原因)。当我们深入研究未来图景的新更新时，请遵循以下内容。让我们一起来看看专家认为该技术的发展方向。
服务网格的新进展
服务网格空间的新进展是什么?好吧，现在大多数小组成员都将Envoy视为大多数网格的已建立数据平面代理。我们还看到它非常适合作为新的多云范例的可观察性机制。
“Envoy是我们正在看到出现的数据平面层”，Klein说。服务网格和API网关空间充斥着许多解决方案，应用程序也越来越倾向于无服务器。未来很难预测，但“像Kubernetes和Envoy这样的基础技术将是管道”，他说。
Levine还称赞了Envoy的可扩展性特性，并举例说明了近用WebAssebnly扩展Envoy所取得的进展。她说：“Envoy是可行之道。”“它是建筑的基石——所有不接受它的东西都会消失。”“尽管如此，市场上存在大量的营销炒作，如果没有适当的保护和治理，执行起来可能会很危险。”
同样，Berg相信Envoy是未来，而多云是现在。然而，他描述了团队实现服务网格是多么困难。他表示：“他们正在努力做到这一点，但很艰难。”护栏和治理的概念非常重要。除此之外，许多公司只需要Istio等成熟技术所能提供的一小部分能力。他呼吁简化可用性和部署——我们需要“针对复杂问题的简单解决方案”。
Chugtu赞扬了它在处理新的混合和多云模式方面的优势。这些现实正在出现，带来了跨所有部署模式的通用可观察性框架的需求。在安全性方面，Chugtu看到了通过威胁检测等方式解决可扩展性问题的实际好处。根据Chugtu的说法，一个服务网络收集的有用信息越多，它就越能帮助定义访问属性。因此，它有助于创建一个零信任模型。
使用服务网格的权衡
尽管如此，仍然存在很大的困难。总体而言，专家组认识到服务网格实施需要大量的人力资源——陡峭的学习曲线，可用性挑战和持续的维护。此外，每个操作都占用服务器空间，因此操作开销和应用程序延迟是需要考虑的实际问题。后，它可能会给不需要它的场景带来过多的复杂性。
“这是一个很陡峭的学习曲线，”伯格说。“这不是一个渐进的改善——你从零开始，然后是一个飞跃。公司可以采用它来实现可观察性和企业范围的交互。随着他们的进步和意识到有更多的价值，伯格补充道，他们必须理解许多资源，并融入这个网络。从操作上讲，SideCar也会随着时间的推移消耗资源。“很多人刚开始构建的时候没有考虑到这一点，”他说。他预测，托管解决方案可以帮助打开更多的可能性，以便更容易地采用。
Levine说：“我们正在尝试采用一种尚未100%做好准备的方法。”服务网格本质上是操作，管理以及升级和维护的另一件事。她还承认设计固有的增加的延迟。不管潜在的弊端如何，Levine仍然相信集中式配置平面的好处胜过不利因素。
Chugtu说：“服务网格无法满足客户现在所在的需求。”他承认其复杂性和固有的学习曲线。但是，他仍然认为值得付出努力，因为这有助于平衡团队动力。从根本上讲，引入服务网格可以将基础架构的所有权转移回平台和DevOps团队，从而使开发人员可以专注于核心能力和应用程序开发。
在近的一次采访中，Palladino强调平台团队和开发者的分离是一件好事。他说：“应用程序团队应该成为连接的消费者，而不是连接的制造者。”
回到问题的根源，也许公司真正应该问的问题是：我们应该首先采用微服务吗?当你采用微服务时，会带来许多意想不到的结果，这些结果与运行单体架构有很大的不同。
从本质上讲，行业不应该在没有必要的时候把事情复杂化。当它被证明是合理的，“Sidecar代理解决方案是这些问题的优雅解决方案”，Klein说。
标准和服务网格接口
正如我近介绍的那样，由Sol***牵头的Service Mesh Interface(SMI)可能是一个令人振奋的提议，它将新兴的Service Mesh领域带来互操作性和可扩展性优势。然而，专家组的总体情绪是对其实际使用的怀疑态度。
Levine支持SMI，以在网格之间形成供应商中立的标准接口。在未来的多网格世界中，在市场上拥有通用的服务网格配置模式可以增强公司的能力。但是，她承认SMI的障碍，特别是标准的“较低的共同点”效应和政治因素阻碍了它的引入。
其他人则不那么确信SMI是必要的。伯格说：“如果你要用不同的网格，那可能是难以下咽的。”“终我们会有多少实现呢?”他问道。如果主要好处只是避免供应商锁定，SMI可能不值得投资。
Klein将SMI描述为一个理论上的好主意，但在实践中并不认为它有用。“我非常怀疑任何东西都是可携带的，”他说。在一天结束的时候，所有的服务网供应商都会有他们自己的解释。Klein强调，行业应该避免增加不必要的抽象层。
一些座谈会的专家没有关注SMI，而是认为围绕Envoy xDS API的融合更加有意义。“如果一切都基于Envoy，那会不会收敛呢?” Klein问道。
准备采用服务网格
因此，了解所涉及的障碍之后，服务网格何时才能100%准备好?它适合什么情况?答案各不相同。
一种方法是从现有技术堆栈的角度来看待它。Klein重申，公司应该在服务网格之前首先采用微服务。他说，不要因为“技术嫉妒”而拥抱服务网格。取而代之的是，这应该是基于大程度地减少操作痛点和大化生产率的客户至上的决定。
另一种观点是考虑未来的发展方向。Chugtu说，服务网格可能是你公司或未来客户愿景的一部分。在这种情况下，你的历史或当前体系结构可能不太重要。他说：“解决方案已准备好，你要解决的用例就很多。”
还有一个观点是，没有任何伟大的技术是完整的。服务网格何时可以100%准备就绪?“从不”，伯格说。总会有故障，以Kubernetes为例：每个发行版都修补或引入了新问题，社区正在不断改进它。同样，市场上的每个服务网格都日趋成熟。他说，它们各有优缺点，“没有一个是完”。
服务网格何时会成熟?对于Levine来说，首先需要通过绞拧器(痛苦的事情)放置服务网格。她说：“它们都不够成熟。” 只有当人们在生产中运行它时，他们才能提供反馈以改善服务网格。尽管“还没有一个人完全准备好”，但Levine确实预见到了一个适合更多组织的快速开放的市场。
服务网格是一个全新的概念，需要更多的生产用例来提高网格和Envoy的可扩展性。早期采用者应根据自己的情况进行正确的猜测，在选择一个市场之前评估市场上的所有服务网格。对于后期的采用者来说，未来可用性的改进和管理服务网格的提供可以很容易地激励一个组织变得网格化。
服务网格是一个新兴领域，软件历史上从来没有任何软件100%准备好了才被使用。未来很难预测，但像Kubernetes和Envoy这样的基础技术将是管道
专家组就服务网格的成熟度进行权衡
服务网格就像一辆电动汽车，你的朋友在谈论它，它很时髦，但是你还没有拥有。你可能希望稍等一下，看看其他人如何对其进行管理。但是，这种感觉就像是下一次技术演化。
近几个月，服务网格已经引起了广泛的关注——它们有助于解决采用微服务架构后出现的许多问题。但是服务网格是否准备好供所有企业使用呢?事实证明，支持者并不认为这项技术已经100%做好被广泛采用的准备了。
11月18日举行的北美2020年服务网专题讨论会上，该领域的思想领袖有：Mat Klein，Lyft;Manish Chugtu，VMware;IBM的Dan Berg和Idit Levine，Sol***。总体而言，小组成员承认服务网格领域当前的积极发展，例如Envoy周围的整合。他们还强调了它的许多好处，包括为微服务体系结构增加了联网、可观察性和路由功能。
但是，我们仍然没有看到足够的服务网格生产用例。并且，每个网格框架仍在成熟当中。使用服务网格的权衡包括增加的等待时间，陡峭的学习曲线和持续的维护开销。网格间互操作性缺乏明确的标准化可能是另一个问题(SMI是一种提议的格式，但是现在行业似乎更倾向于Envoy的xDS API)。
所有这一切并不是说它不会成为公司未来基础架构的关键部分，也不是说它不会为需要的用例提供有用的功能。简而言之，服务网格是一个新兴领域(这就是为什么该小组如此吸引人的原因)。当我们深入研究未来图景的新更新时，请遵循以下内容。让我们一起来看看专家认为该技术的发展方向。
服务网格的新进展
服务网格空间的新进展是什么?好吧，现在大多数小组成员都将Envoy视为大多数网格的已建立数据平面代理。我们还看到它非常适合作为新的多云范例的可观察性机制。
“Envoy是我们正在看到出现的数据平面层”，Klein说。服务网格和API网关空间充斥着许多解决方案，应用程序也越来越倾向于无服务器。未来很难预测，但“像Kubernetes和Envoy这样的基础技术将是管道”，他说。
Levine还称赞了Envoy的可扩展性特性，并举例说明了近用WebAssebnly扩展Envoy所取得的进展。她说：“Envoy是可行之道。”“它是建筑的基石——所有不接受它的东西都会消失。”“尽管如此，市场上存在大量的营销炒作，如果没有适当的保护和治理，执行起来可能会很危险。”
同样，Berg相信Envoy是未来，而多云是现在。然而，他描述了团队实现服务网格是多么困难。他表示：“他们正在努力做到这一点，但很艰难。”护栏和治理的概念非常重要。除此之外，许多公司只需要Istio等成熟技术所能提供的一小部分能力。他呼吁简化可用性和部署——我们需要“针对复杂问题的简单解决方案”。
Chugtu赞扬了它在处理新的混合和多云模式方面的优势。这些现实正在出现，带来了跨所有部署模式的通用可观察性框架的需求。在安全性方面，Chugtu看到了通过威胁检测等方式解决可扩展性问题的实际好处。根据Chugtu的说法，一个服务网络收集的有用信息越多，它就越能帮助定义访问属性。因此，它有助于创建一个零信任模型。
使用服务网格的权衡
尽管如此，仍然存在很大的困难。总体而言，专家组认识到服务网格实施需要大量的人力资源——陡峭的学习曲线，可用性挑战和持续的维护。此外，每个操作都占用服务器空间，因此操作开销和应用程序延迟是需要考虑的实际问题。后，它可能会给不需要它的场景带来过多的复杂性。
“这是一个很陡峭的学习曲线，”伯格说。“这不是一个渐进的改善——你从零开始，然后是一个飞跃。公司可以采用它来实现可观察性和企业范围的交互。随着他们的进步和意识到有更多的价值，伯格补充道，他们必须理解许多资源，并融入这个网络。从操作上讲，SideCar也会随着时间的推移消耗资源。“很多人刚开始构建的时候没有考虑到这一点，”他说。他预测，托管解决方案可以帮助打开更多的可能性，以便更容易地采用。
Levine说：“我们正在尝试采用一种尚未100%做好准备的方法。”服务网格本质上是操作，管理以及升级和维护的另一件事。她还承认设计固有的增加的延迟。不管潜在的弊端如何，Levine仍然相信集中式配置平面的好处胜过不利因素。
Chugtu说：“服务网格无法满足客户现在所在的需求。”他承认其复杂性和固有的学习曲线。但是，他仍然认为值得付出努力，因为这有助于平衡团队动力。从根本上讲，引入服务网格可以将基础架构的所有权转移回平台和DevOps团队，从而使开发人员可以专注于核心能力和应用程序开发。
在近的一次采访中，Palladino强调平台团队和开发者的分离是一件好事。他说：“应用程序团队应该成为连接的消费者，而不是连接的制造者。”
回到问题的根源，也许公司真正应该问的问题是：我们应该首先采用微服务吗?当你采用微服务时，会带来许多意想不到的结果，这些结果与运行单体架构有很大的不同。
从本质上讲，行业不应该在没有必要的时候把事情复杂化。当它被证明是合理的，“Sidecar代理解决方案是这些问题的优雅解决方案”，Klein说。
标准和服务网格接口
正如我近介绍的那样，由Sol***牵头的Service Mesh Interface(SMI)可能是一个令人振奋的提议，它将新兴的Service Mesh领域带来互操作性和可扩展性优势。然而，专家组的总体情绪是对其实际使用的怀疑态度。
Levine支持SMI，以在网格之间形成供应商中立的标准接口。在未来的多网格世界中，在市场上拥有通用的服务网格配置模式可以增强公司的能力。但是，她承认SMI的障碍，特别是标准的“较低的共同点”效应和政治因素阻碍了它的引入。
其他人则不那么确信SMI是必要的。伯格说：“如果你要用不同的网格，那可能是难以下咽的。”“终我们会有多少实现呢?”他问道。如果主要好处只是避免供应商锁定，SMI可能不值得投资。
Klein将SMI描述为一个理论上的好主意，但在实践中并不认为它有用。“我非常怀疑任何东西都是可携带的，”他说。在一天结束的时候，所有的服务网供应商都会有他们自己的解释。Klein强调，行业应该避免增加不必要的抽象层。
一些座谈会的专家没有关注SMI，而是认为围绕Envoy xDS API的融合更加有意义。“如果一切都基于Envoy，那会不会收敛呢?” Klein问道。
准备采用服务网格
因此，了解所涉及的障碍之后，服务网格何时才能100%准备好?它适合什么情况?答案各不相同。
一种方法是从现有技术堆栈的角度来看待它。Klein重申，公司应该在服务网格之前首先采用微服务。他说，不要因为“技术嫉妒”而拥抱服务网格。取而代之的是，这应该是基于大程度地减少操作痛点和大化生产率的客户至上的决定。
另一种观点是考虑未来的发展方向。Chugtu说，服务网格可能是你公司或未来客户愿景的一部分。在这种情况下，你的历史或当前体系结构可能不太重要。他说：“解决方案已准备好，你要解决的用例就很多。”
还有一个观点是，没有任何伟大的技术是完整的。服务网格何时可以100%准备就绪?“从不”，伯格说。总会有故障，以Kubernetes为例：每个发行版都修补或引入了新问题，社区正在不断改进它。同样，市场上的每个服务网格都日趋成熟。他说，它们各有优缺点，“没有一个是完”。
服务网格何时会成熟?对于Levine来说，首先需要通过绞拧器(痛苦的事情)放置服务网格。她说：“它们都不够成熟。” 只有当人们在生产中运行它时，他们才能提供反馈以改善服务网格。尽管“还没有一个人完全准备好”，但Levine确实预见到了一个适合更多组织的快速开放的市场。
服务网格是一个全新的概念，需要更多的生产用例来提高网格和Envoy的可扩展性。早期采用者应根据自己的情况进行正确的猜测，在选择一个市场之前评估市场上的所有服务网格。对于后期的采用者来说，未来可用性的改进和管理服务网格的提供可以很容易地激励一个组织变得网格化。
