对于任何选择转向Kubernetes平台的组织来说，服务网格越来越被视为一个基本的构建模块。由于服务网格为微服务管理提供了可观察性、连接性和安全性检查，因此，Istio的底层功能和开发是运维和最终标准化的关键组成部分。
服务网格帮助组织迁移到云原生环境，它是一种弥合内部数据中心部署和云环境中的容器化云环境之间的管理差距的方法。一旦实现，服务网格如果运行正常，可以大大降低这个过程的巨大复杂性。事实上，对于许多DevOps团队成员来说，没有服务网格就无法切换到云原生环境和Kubernetes。
Tetrate技术人员Butcher说，在一个典型的分为内部服务器和多云部署的环境中，服务网格通过支持“需要在这些不同环境中进行通信的组件之间的通信”来提供“公共基础”。
“这就是对身份和安全的投资。”他继续说，“所有环境都是一致的，而且可以向审计员证明这些环境是一致的。服务网格带来的集中控制和一致性是非常有用的，尤其是在这么一个基础设施分裂的世界中。”
Aspen Mesh的联合创始人和CTO Jenkins认为，归根结底，组织将服务网格作为“不仅仅是部署问题”的答案，也作为在云原生旅程中“将所有部分集成在一起”的一种方式。
Jenkins说：“你想达到的最终目标是，通过让开发人员在更小的组件上快速移动，释放开发人员的效率，而这些组件都是为用户提供集成体验的，你必须从这里开始。因此，我们发现，组织在很大程度上使用服务网格来帮助实现这一进化路径。这涉及到了解现在所处的位置，将一些部分迁移到云原生模型中，并开发新的云原生组件，但同时不要将已经完成的所有工作都抛在脑后。”
各组织也从服务网格以及Istio的成熟中受益。例如，最近发布的Istio 1.6.4和Istio 1.6.3，功能越来越实用。
正在开发中的另一个主要新功能是“web组装支持”，作为扩展Istio，尤其是sidecar Envoy代理的一种方式，它“以更便携和快速发展的方式，而不是必须在系统中构建一些非常低级的组件。”Jenkins说，“我认为这很好，因为它将允许开发人员扩展服务网格的某种能力，但不必在这个拥挤的核心区实现所有这些，在这里，稳定性是一个极其重要的问题。因此，这一功能打开了网络组装的新空间，使我们能够同时做到这两点：稳定性和创新。
然而，仍有一些情况不需要服务网格。换句话说，服务网格并不是所有DevOps的最终解决方案。“实际上，有些时候你不需要Kubernetes，而且可能根本不需要容器，或者可以使用无服务器。”
当组织考虑采用什么来促进他们的软件开发和部署目标时，有成百上千的开源工具和解决方案可供选择。在进行选择时，要考虑连续性和统一性，服务网格就具备这些。
原文链接：
https://thenewstack.io/when-you-need-or-dont-need-service-mesh/
