为什么基础设施对于使用容器的开发人员如此重要
如今，在基础设施提供商的大厅里最常听到的问题之一就是如何向开发者社区解释该基础设施的价值。 问题是，基础设施的大部分好处都是在交付生产之后获得的。 这些都不能真正直接为开发人员带来价值，至少不能以对他们的日常工作产生有意义的影响。
额外的开发利益是开发人员当然知道的事情。 在我们的 2018 年应用交付状况中，我们只占了一小部分开发人员。 但该百分比在他们想要部署的应用服务这一主题上表现突出。 其中一些应用服务（负载均衡、缓存和加速）通常作为应用本身的一部分进行部署，也可以作为基础设施进行部署。 TCP 优化和 WAF 几乎始终是基础设施服务，部署在应用（无论是整体式还是微服务）的上游（在数据路径中）。
所有这些应用服务都有其价值。 降低风险，提高性能和可扩展性。 但这些都是应用和商业利益；它们使开发人员在应用交付到生产后受益。 很难找到（更不用说表达）基础设施交付前（即作为开发生命周期的一部分）的好处。
但随着我们继续拥抱容器和微服务，交付前和交付后的基础设施的价值变得更加明显。
与大多数新兴技术一样，新的应用架构的早期阶段几乎没有什么基础设施。 开发人员可能会惊讶地发现应用架构极大地影响了应用服务基础设施。 从转向三层，基于 Web 的应用程序具有可扩展性（负载均衡）。 从采用具有响应式表示层的 Web 2.0 开始，就出现了前端加速基础设施。 随着移动设备的出现和每个行业日益数字化，我们看到基础设施通过 WAF、DDoS 和机器人防御等安全服务做出反应。
我们现在看到的情况是开发人员正在他们的应用中编纂基础设施服务功能。 开发人员正在将传统上由上游服务负责的工作纳入代码中。 来自负载均衡器的重试。来自平台或代理的 mTLS。 访问控制以限制与合法客户端的通信。
由于容器框架的新兴性质和快速的采用率，这些都是基础设施责任，已被开发人员承担。
但正如一直以来的情况一样，这种情况正在改变。 正如以前的应用程序架构推动了网络基础设施的响应一样，容器和微服务也是如此。 只是这一次的变化并不以新盒子的形式出现。 现在正在发生的是将开发人员所需的应用服务集成到容器环境中。 这就是服务网格的作用所在，它直接为开发人员提供真实、可量化的价值。
正如Aspen Mesh首席架构师 Andrew Jenkins 在接受 Linux.com 采访时所解释的那样：
“如今开始制作网络服务是如此简单，真是令人惊叹。 您可以在推文中输入该代码。 但这并不是真正的网络服务。 为了使其具有弹性和可扩展性，您需要在应用程序的数据平面添加一些内容。它需要执行 TLS，需要重试失败，并且它需要只接受来自此服务的请求而不接受那个服务的请求，并且它需要检查用户的身份验证，等等。 服务网格可以帮助您获得数据平面功能，而无需向应用程序添加代码。”
交付前的价值在于减少范围并消除重复但必要的代码，以处理容器环境内的基本安全性和规模。 服务网格具有各种各样很酷的功能，但其优势主要仍然在于操作性——可观察性、可问责性、可扩展性。 对于开发人员来说，最重要的价值在于消除代码（从而减少技术和架构债务）。
采用服务网格来扩展、保护和观察部署在容器环境中的应用程序，减轻了编写代码的负担，这些代码本应由基础设施处理，但直到最近才被委托给开发人员。 服务网格是一种减轻开发人员责任的方法，让他们有宝贵的时间来开发服务和应用程序，从而为企业带来价值。