随着微服务的兴起和远离单体架构的转变，IT 和DevOps团队专注于将基础设施中的所有内容整合到越来越小的平台和技术中。大胆的愿景是，每个人都将在同一个“上帝平台”上，拥有一个管理平面、一个数据平面和一个简单的参考点。Kubernetes、云原生和微服务将成为实现这一愿景的载体。每个人都会在同一页面上，使用相同的指标并使用相同的语言。网络和开发团队会突然头脑融合，喜悦随之而来。
问题是，NetOps、SecOps 和 DevOps 团队需要非常不同的能力和指标，以至于将所有团队干扰到一个平台上并迫使他们共享所有内容会给各方带来真正的痛苦。
NetOps、SecOps 和 DevOps不同诉求
NetOps 和 DevOps 对流量管理的期望不一致：
NetOps 希望保持安全性和正常运行时间，主要目标是网络稳定性和一致性，NetOps 团队必须保持整个公司的正常运行，包括财务、人力资源、营销等方面的应用程序。
所以，不，一些想要尝试新的基于 Clojure 的微服务的热心开发人员无法在本周进行蓝绿部署。提交票并排队，哟。这种保守的观点使得 NetOps 不愿意也无法对防火墙、负载平衡器和其他关键网络平台进行更改。NetOps 的谨慎颠覆了快速迭代、持续测试和快速部署的整个前提，而这些都是敏捷 DevOps 所追求的。
另一方面，DevOps，尤其是在构建云原生和基于微服务的应用程序时，需要能够快速更改安全规则和路由表，以现代 CI/CD 管道的速度进行测试和迭代。服务和云原生应用程序在设计上是松散耦合的，只有在开发人员对部署有更大程度的自主决定和控制权时才能成功。
与此同时，现代应用程序被分解为许多不同的服务，在粒度级别缺乏控制，这会大大降低 DevOps 正确调整和提供适当应用程序性能的能力，以至于客户可能会注意到。对于 DevOps 团队来说，让其他人控制他们的部署的想法感觉就像回到了 1990 年代，当时他们不得不等待一个月的服务器。
对于 SecOps，微服务和 Kubernetes 带来了安全挑战，这些挑战无法仅通过传统方法（例如围栏安全）来解决。虽然 SecOps 能够很好地在 Kubernetes 集群之外执行策略，但他们的工具并不适合轻量级、容器化的应用程序。由于安全性不足，Kubernetes 团队的配置错误会导致数据泄露和暴露。当 SecOps 通过延迟或停止生产中的容器化应用程序部署来保护组织免受风险时，它们就变成了恶棍。DevOps 将它们视为快速交付应用程序能力的主要限制因素，安全性通常以速度的名义被牺牲。
云原生倒逼整合问题
随着各种规模的组织都在推动云原生并采用微服务，对比鲜明的世界观发生了冲突。结果并不好：要么 DevOps 在 NetOps 两周的变更周期中焦急等待，要么 NetOps 火力全开，试图以 DevOps 的疯狂速度工作，并不断担心防火墙或负载平衡规则的变更请求一个团队将关闭整个应用程序基础架构，一举使数百个应用程序脱机。
SecOps 经常被夹在两个世界之间：试图弄清楚全球 WAF 如何处理边界后面的 Kubernetes 集群的规则，同时还实施微服务级别的安全性。
整合的级联效应也迫使 DevOps、SecOps 和 NetOps 在不同的观察和管理工具、不同的安全原则和对应用程序行为的不同期望之间做出选择。例如，对于 NetOps，平均丢弃的数据包是一个关键的 KPI，而对于 DevOps，它与理解用户体验无关。
解决方案是：复制，而不是整合
解决方案既违反直觉又显而易见：不是停止斗争以使整合工作；相反，是拥抱基础设施和工具的重复冗余。允许 NetOps 使用基本的安全和相当静态的规则和管理来控制前端网关；允许每个 DevOps 团队使用自己专用的负载平衡并将其自己的应用程序配置为高容量设备或位于前端的虚拟机后面的一组辅助网络活动，但由 NetOps 管理。
要清楚的是，我们并不是在提倡一个免费的平台：每个DevOps团队都可以选择自己的负载均衡器和工具，让NetOps来收拾烂摊子。相反，我们讨论的是基于用户组的受控整合，这些用户组维护重复的功能（如在两个轨道中），以便每一方都有一些可行的功能。
由NetOps团队控制的一个经过测试的、稳定的、企业范围的负载均衡器非常有意义：既需要性能和控制，又想保护自己免受DDoS和其他威胁。
NetOps可以像前门安全一样工作，确保每个人都有一个入口安全。借助于精心设计的策略，NetOps可以为DevOps团队提供所需的回旋余地，使他们能够在外围负载均衡器后面部署自己的轻量级网络基础设施，如Kubernetes。
DevOps使用一个专门的负载均衡器，一个入口控制器，然后在自己的沙盒中进行游戏，而不必用请求流来打扰NetOps。DevOps可以迭代。网络行动可以稳定下来。
SecOps可以维护防火墙的全球安全基础设施，同时与DevOps（或者更可能是DevSecOps）合作，创建一个零信任框架，在服务级别跨应用程序分发安全性，并使DevOps团队能够满足其特定应用程序或服务需求的安全性。
我们一次又一次地看到，一旦公司接受了这个新的现实，他们实际上能够加快代码速度和应用程序迭代，而不会降低安全性或稳定性。每个团队都可以愉快地专注于自己的KPI。
同样重要的是，双基础设施使NetOps、SecOps和DevOps能够协同工作，而不是为选择和控制一个解决方案而斗争。您的开发人员不需要一直左移来学习Nagios，这是他们真正不关心的事情，您的NetOps团队也不需要学习如何配置和调优Prometheus。