IT经理、架构师和开发者都尝试妥协于微服务和容器对企业IT方式的改变。在某一个层面来说这是一件好事，但是事实上，一些更深层次的东西在驱动着技术和IT。

要理解微服务和容器，可以从抓住它的价值定义开始，然后将IT和数据中心的性能与这个变革的驱动者进行匹配。***，为了敏捷性来构建架构，而不是为了追随下一个大热点来构建架构。

IT策划者和经理们一定要了解到应用程序和工作者之间基本关系的变化——特别是事件驱动型、移动的工作者——他们是使用容器和微服务的驱动者。IT方向的转变会让昂贵、长期存在的基础架构向动态的市场进行靠齐。这意味着不仅仅是更多高效的云服务或者更低的操作复杂性，还能更好地对他们IT的需求进行响应。

现代的工作者

应用软件从记录业务活动进化到促进业务活动。应用程序创建了一条企业可以跟随的创建运营计划的最小阻力路径。企业架构师已经通过数十年的努力想把应用程序与业务的目标达成契合，但是他们通常会被现在用来经营业务所使用的可用的IT工具所阻碍。

智能手机设备的出现加速了这个现象。手机app的工作者需要得到对他们工作的支持，而不是遵循一些已经预定义好的工作流。手机工作者是事件驱动型的，这意味着应用程序也需要这样。微服务不是为了IT发展所寻求得商业计划，而是一种响应战略性需求的构造应用的方法。

比传统的虚拟化更少的日常开销

在应用程序的层面，微服务促使架构师和开发者不仅仅把产品特点和流程当成是服务，而是重新思考整个流程和应用组成的概念。伴随着面向服务的架构体系( SOA))和其他基于服务的方法论，流程将组件捆绑变成组合的应用程序。微服务的目标是让工作者的工作和组合的营养程序绑定到一起。每一步和特性都是按需求而定的。

可能微服务和敏捷IT带来的***的影响就是每一个组件都变得很关键。在一个应用模型中，每一个组件的组成都是显而易见的，所以你可以有根据地将关键和非关键的app分开。但是在微服务模型里，一个组件可能是关键app的一部分，也可能不是，这取决于工作环境。规则、安全和可用性必须在所有地方都达到要求，而不仅仅是需要的地方达到要求就可以。

微服务临时的特性是驱动着容器技术的关键。而虚拟化，不管是在数据中心还是在云端，不管是如何组合的都会有比较高的应用程序开销。如果服务是小型的、策略性的，那么虚拟化的费用是很难平衡的。如果微服务有广泛的接受程度，那么容器会更加普遍，微服务会成为事件驱动型IT模型的基础。

微服务一定要基于正确的组件架构上，这会让IT能动态地部署和规划组件。非状态化组件和更功能性的编程方法会主动阻止开发者创建状态化的组件。开发经理和架构师现在已经有一些功能性的工具，比如厂家微软和Oracle通过Lambda表达式创建的的功能性编程。但是他们还是需要围绕着微服务的开发环境来做一些功能性的领域，因为编程的必要模型还是存在的。