IT经理、架构师和开发人员都在努力妥协微服务和容器对企业IT所做的更改。一方面，这是一件好事，但事实上，更深层次的东西正在推动技术和IT。要了解微服务和容器，首先要捕获其价值定义，然后将IT和数据中心性能与这一变化驱动因素相匹配。***，为敏捷而构建，而不是为了下一件大事。IT规划人员和管理人员必须了解，应用程序和员工（尤其是事件驱动的移动员工）之间不断变化的基本关系是容器和微服务使用的驱动力。IT方向的转变使昂贵、长期存在的基础设施与动态市场保持一致。这不仅意味着更高效的云服务或更低的运营复杂性，还意味着更好地响应他们的IT需求。现代工作者应用程序已经从记录业务活动发展到促进它。该应用程序创建了一条阻力最小的路径，企业可以遵循该路径来制定运营计划。几十年来，企业架构师一直在努力使应用程序与业务目标保持一致，但他们经常受到当今可用于运营业务的IT工具的阻碍。智能手机设备的出现加速了这一现象。移动应用程序工作人员需要支持他们的工作，而不是遵循一些预定义的工作流程。移动工作人员是事件驱动的，这意味着应用程序也需要如此。微服务不是IT开发的业务计划，而是一种响应战略需求构建应用程序的方式。比传统虚拟化的开销更少在应用层面，微服务促使架构师和开发人员不仅要将产品特性和流程视为服务，还要重新思考应用组合的整个过程和概念。与面向服务的体系结构(SOA)和其他基于服务的方法一起，流程将组件捆绑到复合应用程序中。微服务的目标是将工人的工作与营养计划的组成联系起来。每个步骤和功能都是按需制作的。也许微服务和敏捷IT的最大影响是每个组件都变得至关重要。在一个应用模型中，各个组件的组成是显而易见的，因此可以合理地将关键应用和非关键应用分开。但在微服务模型中，一个组件可能是也可能不是关键应用程序的一部分，这取决于工作环境。规则、安全性和可用性必须在任何地方都得到满足，而不仅仅是在需要它们的地方。微服务的短暂性是推动容器技术发展的关键。而虚拟化，无论是在数据中心还是在云端，无论怎么组合，都会有比较高的应用开销。如果服务规模小且具有战略意义，那么虚拟化的成本就很难平衡。如果微服务被广泛接受，那么容器将变得更加普遍，微服务将成为事件驱动IT模型的基础。微服务必须基于正确的组件架构，它允许IT动态部署和规划组件。无状态组件和更实用的编程方法积极地阻止开发人员创建有状态组件。开发经理和架构师现在拥有一些函数式工具，例如制造商Microsoft和Oracle通过Lambda表达式创建的函数式编程。但是他们仍然需要围绕微服务的开发环境做一些功能领域，因为编程的必要模型仍然存在。增强后端以采用容器技术并不能保证数据中心将发展为支持微服务和事件驱动的IT。随着程序变得更加敏捷，这也意味着它们的开发效率会降低。采取一些措施来防止这种情况发生，与业务负责人和开发人员协商，让应用程序在设计时避免过度和无保障的组件化。不受控制地使用微服务会导致IT效率低下，而不会提高最终用户的敏捷性。除了这些，IT运营团队还必须修改数据中心的运营方式和数据中心本身。当网络延迟最小时，微服务和事件驱动组件效率最高，其中包括整个数据中心之间的延迟，以及多个数据中心或公共云服务之间的延迟。使用快速局域网作为数据中心的核心，在服务器和网络适配器上提供优化的网络路径，避免虚拟交换机过载。连接多个数据中心以减少延迟和数据包丢失，这会严重降低微服务的性能。不能使速度更快的东西应该被阻止。根据需要对新的应用程序部署和DevOps工具进行标准化，以使微服务适用。将微服务托管在靠近它们需要连接的地方，也靠近固定资源，例如数据库，以避免过多的交付延迟。在IT资源上放置微服务时，寻找编排工具要考虑以上几点。培训IT运营人员在安装参数和策略时提供正确的连接信息。由业务敏捷性驱动的微服务和容器可能会产生巨大的力量，迫使数据中心接受私有云并支持混合云部署。当可以在虚拟化环境中构建微服务和容器模型时，对敏捷应用程序的需求将影响特性和功能的迁移。云友好的内部实践和客户创新的公共云采用将允许弹性组件自由扩展。
