关于数字化转型的惊人事实： 容器混乱
这是有关数字化转型带来的挑战的系列博客中的最后一篇。
容器混乱。
容器和管理它的编排（我们所说的毫不费力）的主要目的之一是高效扩展。 还有其他一些好处，主要是面向开发的好处，推动了人们选择采用容器，但从 NetOps 的角度来看，这与规模和（缺乏）安全性有关。
传统的交付架构无法在容器环境中发挥作用。 沟通是不稳定的、动态的、难以预测的。 通信方式日益多样化，环境也日趋不稳定。 现在的情况与两分钟后的情况不一样，更不用说十分钟后了。
但是您仍然需要为容器环境内的“应用程序”提供核心网络和安全服务。 您将无法在其中插入身份和访问控制，也无法跨变量实例管理证书。 终止应用程序的 SSL对于您和应用程序本身来说都是一场噩梦。 甚至像机器人防御和 OWASP Top Ten 保护这样的应用程序安全性也会出现问题，因为您如何将它们放入如此不稳定的环境中？ 另外，你不需要将容器环境中的每个服务映射到公共 IP。 您需要一条安全的入站路径来提供应用服务，而不会干扰环境内部的操作。
幸运的是，在容器环境内作为多个微服务部署的应用程序仍然是应用程序（甚至是 API），并且具有“特定于应用程序”的端点，这提供了建立安全入站路径的机会，而不会干扰容器环境。 这使得基于传统稳定性和规模原则的双分叉网络架构成为可能，同时采用了基于软件的容器规模的现代方法。 这种两层架构可以实现可靠、安全的端点，通过它可以在容器环境内从 NS 主干转换到 EW 路径。
两层架构
两层架构提供了必要的可靠性和安全性，同时支持容器化应用程序所需的速度和规模。 通过限制容器的混乱，您可以保持理智并将共享基础设施与容器化应用程序固有的熵隔离开来。 这带来了意想不到的好处，即支持具有可变变化的生产流程。 虽然应用程序在容器化环境中可能会更频繁地发生变化，但身份和访问控制以及其他与安全相关的服务的更改可能不太频繁。 更新可以彼此独立地进行，从而使 DevOps 能够以更快的速度发展，而不会给‘房子’南北两侧的 NetOps 造成巨大负担。
入口点可以管理特定于应用程序的策略（性能和一些安全性），而安全入站网络的其余部分则处理其余部分。 这使得将容器纳入为旧版应用程序提供服务的生产环境成为一个更顺畅、更轻松的过程，因为它造成的破坏最小。
重要的是要记住，要使两层架构发挥作用，入口必须有效地成为应用程序。或者至少是其虚拟等价物。
即使在容器“墙”的另一边有数百个微服务，入口也是实现规模化、可访问性并确保应用免受外部威胁的战略控制点。 使用入口来应用那些在流量进入易变且不确定的容器世界之前最好处理的服务。
...至此，我们对数字化转型的惊人真相的探索就结束了。 还有许多其他问题和障碍需要解决，但本系列中涵盖的四个问题：云混乱、跳过安全性、规模不经济和容器混乱可能是必须解决的最关键的问题。
如果您意识到变化的影响，您将能够利用自动化、基于软件的安全性和规模以及新架构的力量，成功地导航到新的数据中心。