稍等缓冲中
要理解微服务和容器，可以从抓住它的价值定义开始，然后将IT和数据中心的性能与这个变革的驱动者进行匹配。最后，为了敏捷性来构建架构，而不是为了追随下一个大热点来构建架构。
IT策划者和经理们一定要了解到应用程序和工作者之间基本关系的变化——特别是事件驱动型、移动的工作者——他们是使用容器和微服务的驱动者。IT方向的转变会让昂贵、长期存在的基础架构向动态的市场进行靠齐。这意味着不仅仅是更多高效的云服务或者更低的操作复杂性，还能更好地对他们IT的需求进行响应。
现代的工作者
应用软件从记录业务活动进化到促进业务活动。应用程序创建了一条企业可以跟随的创建运营计划的最小阻力路径。企业架构师已经通过数十年的努力想把应用程序与业务的目标达成契合，但是他们通常会被现在用来经营业务所使用的可用的IT工具所阻碍。
智能手机设备的出现加速了这个现象。手机app的工作者需要得到对他们工作的支持，而不是遵循一些已经预定义好的工作流。手机工作者是事件驱动型的，这意味着应用程序也需要这样。微服务不是为了IT发展所寻求得商业计划，而是一种响应战略性需求的构造应用的方法。
比传统的虚拟化更少的日常开销
在应用程序的层面，微服务促使架构师和开发者不仅仅把产品特点和流程当成是服务，而是重新思考整个流程和应用组成的概念。伴随着面向服务的架构体系( SOA))和其他基于服务的方法论，流程将组件捆绑变成组合的应用程序。微服务的目标是让工作者的工作和组合的营养程序绑定到一起。每一步和特性都是按需求而定的。
可能微服务和敏捷IT带来的最大的影响就是每一个组件都变得很关键。在一个应用模型中，每一个组件的组成都是显而易见的，所以你可以有根据地将关键和非关键的app分开。但是在微服务模型里，一个组件可能是关键app的一部分，也可能不是，这取决于工作环境。规则、安全和可用性必须在所有地方都达到要求，而不仅仅是需要的地方达到要求就可以。
微服务临时的特性是驱动着容器技术的关键。而虚拟化，不管是在数据中心还是在云端，不管是如何组合的都会有比较高的应用程序开销。如果服务是小型的、策略性的，那么虚拟化的费用是很难平衡的。如果微服务有广泛的接受程度，那么容器会更加普遍，微服务会成为事件驱动型IT模型的基础。
微服务一定要基于正确的组件架构上，这会让IT能动态地部署和规划组件。非状态化组件和更功能性的编程方法会主动阻止开发者创建状态化的组件。开发经理和架构师现在已经有一些功能性的工具，比如厂家微软和Oracle通过Lambda表达式创建的的功能性编程。但是他们还是需要围绕着微服务的开发环境来做一些功能性的领域，因为编程的必要模型还是存在的。
增强后端
采取容器技术并不意味着保证数据中心会进化成最佳去支持微服务和事件驱动型IT。当程序变得越来越敏捷也意味着对它们的开发会变得越来越没有效率。通过几步来阻止这一切的发生吧，与业务负责人和开发者进行协商，让应用在设计的时候就避免过多的、没有保证的部件化。失控地使用微服务会带来IT的低效率，且不会提高最终用户的敏捷性。除了这些，IT运营团队还必须修正数据中心运营的方式和数据中心本身。
微服务和事件驱动型组件在网络延迟最小的情况下是最有效率的，这包括通过整个数据中心的延迟，以及多个数据中心或者公有云服务之间的延迟。使用快速的局域网作为数据中心的核心，在服务器和网络适配器上提供优化过得网络路径，避免虚拟交换机的过载。连接多个数据中心来减少延迟和丢包，这会严重恶化微服务的性能。
不能变快的应该被阻止。按需要规范新的应用程序部署和DevOps工具，让微服务变得合适。托管微服务到接近需要连接的地方，同样也要离固定的资源比较近，例如数据库，来避免过多的传递延迟。在将微服务放到IT资源的时候，要寻找编排的工具来考量以上这些点。对IT运营人员进行培训，让他们在安装参数和策略的时候提供正确的连接信息。
微服务和容器，被业务敏捷性所驱动着，它可能会产生一个巨大的力量来强迫数据中心接受私有云，支持混合云部署。当在虚拟化环境下建立微服务和容器模型成为可能的时候，对敏捷应用的需求会影响特性和功能的迁移。对云友好的内部实践和客户创新的公有云采纳方案会让弹性组件缩放自如。
