使用微服务迁移单体应用
有一种奇特的观点认为，你可以把一块巨石放在一个容器里，然后就大功告成了！ 现代建筑的优点是规模大、速度快。
事实上， KubeKon 2018 的一项调查显示，大约 55% 的受访者表示他们利用容器“作为现有应用程序的虚拟机替代品”。 其他调查显示，大量 Java 企业级应用在容器中运行。 2018 年 Diamanti 的一项调查显示，虽然大多数人 (54%) 正在使用容器开发云原生应用，但近三分之一 (31%) 的人正在使用它们来对遗留应用进行现代化改造。
所举理由一般都是操作性的；尽管需要管理的活动部件激增，但容器似乎更易于管理。 性能和许可费用也常常是决定是否采用容器的因素。
但这一举措并不像将旧版应用程序包装起来并放入容器那么简单。
现实情况是，整体式应用程序（传统的客户端-服务器和 Web 应用程序）具有某些特性，使得难以将其提升并转移到容器中并获得运营优势。 容器和微服务并不互相包容，但都倾向于现代应用程序可用性所基于的“注定失败”原则。 如果您不熟悉这个原则，那就是如果一个容器失败了，您只需启动另一个容器来代替它。 所有的容器都是牛，一个比一个好。
在刻意设计的现代无状态应用架构中，情况确实如此。 在传统的有状态应用架构中，情况并非如此。
您会看到，客户端-服务器及其后继者（三层 Web 应用程序）通常都是有状态的。 它们维护有关会话中客户端和应用程序之间交互的某些信息。 该会话可能保存在应用程序或 Web 服务器的内存中，或保存在单独的数据库中。 无论这些数据保存在何处，它都是使应用程序具有状态的原因。 这些数据与应用的运行相关且重要。它包含您的购物车、您上次访问的页面以及其他特定于应用的信息。
你可以想象，如果保存该信息的网络/应用服务器突然消失，将会对客户体验产生负面影响。 我的购物车不见了。 我必须导航回到原来的位置。 基本上，我必须重新开始。
这种行为与消除应用状态操作的现代架构原则完全相反。 现代应用程序和服务具有无状态特性，当出现问题时，可以无缝地用一个实例替换另一个实例。 它是“注定失败”理论得以实现的基础。 如果你将状态重新引入到该等式中，一切突然就会崩溃。
虽然应用程序仍可运行，但用户却处于不确定的状态。 他们的流通被打乱，他们的交易被传送到下界，再也看不到了。
这个问题导致了应用服务需要尊重状态。 一旦客户端连接到特定的应用程序/网络服务器，它就必须在会话生命周期内连接到同一个应用程序/网络服务器。 开发了 Cookie 持久性和其他机制来确保每次请求都被路由到同一台服务器。 为了保存状态。
现实情况是，除非你是一家初创企业，否则你现在正在运行传统和现代应用。 尽管关于该主题的研究各不相同，但“63％ 旧版应用/37％ 新应用”的分布在各个时期基本保持一致。 这意味着您需要同时支持传统架构和现代架构。
如果您还没有解决有状态和无状态之间的区别，那么简单地将整体式应用程序移入容器是没有帮助的。
架构分层
管理整体式应用程序向容器化环境迁移的最好（或者至少是最简单的）方法是确保即使在容器集群的无状态无政府状态下仍能尊重状态。 这需要在集群边缘、在南北向东西交汇的入口处具备一些智能。
两层方法支持传统和现代的运营方法以及将传统的有状态应用程序迁移到容器化环境。 通过利用 F5 容器入口服务 (CIS)，NetOps 可以继续支持有状态应用迁移到容器化环境的需求。 这种连接确保采用持久性的传统负载均衡方法可以继续运行，并将请求引导到正确的容器或直接进入传统环境。
同时，BIG-IP 可以同时将对现代应用程序和 API 的请求定向到容器集群内的入口控制器，以便根据需要分发到尽可能多的无状态容器中。
转型需要时间
实际情况是，大多数组织支持多达五种截然不同的应用程序架构——从整体式架构到移动式架构再到微服务。 同时支持相同但不同数量的网络和运营模型肯定会使运营不堪重负，并抵消迁移到现代架构和环境的好处。 战略性的两层方法使组织能够在过渡到大多数容器化环境的同时，获得两种模型的运营和业务优势。
重构选项
为了简化这种转变，您可以做的事情之一是重构旧版应用程序以利用共享会话。 这些会话保存在与 Web / 应用服务器分开的位置 - 通常是某种数据库 - 任何具有适当会话 ID 的 Web / 应用服务器都可以访问这些会话。 您仍然需要跟踪会话 ID，但这通常可以通过无论 Web/应用服务器状态如何都持续存在的 cookie 来实现。 如果旧版应用程序尚未使用共享会话模型，则与重新平台化整个应用程序相比，重构是一个相当轻松的过程。
因为这种转变需要时间——毕竟，我们今天几乎仍然在多云模式下运营——所以重要的是找到并利用能够最大化利益的架构选项，同时又不损害可用性和安全性等核心客户需求。 使用两层架构方法可以同时提供这两种功能，而不会限制容器化工作。