标准化一直是IT组织降低成本的方式之一。不幸的是，它也降低了灵活性—标准化越多，灵活性越少。通过采纳微服务架构，架构师和开发人员可以使用更加多样化且能够紧密反映问题复杂度的技术栈来设计应用程序。

　　微服务架构风格与许多企业部署软件和分配IT资源的方式相反。许多架构风格的主要目标之一是有效地利用共享资源（操作系统、数据库服务器、应用程序服务器等）。由于资源的成本影响了底线，因此这些公司建立了软件架构以最大化共享资源。

　　然而，共享资源有一个缺点。无论开发人员如何有效地构建与这些服务器的隔离，都会出现对这些资源的竞争。有时组件由于依赖管理而互相干扰，有时由于两个组件争用某些资源（例如CPU）而产生问题。这就不可避免地会导致共享组件以并不期望的方式进行交互。

　　容器和解耦

　　在软件交付中，有两个关键的技术“环境”：开发人员工作的开发环境，以及IT运维人员管辖范围的部署环境。传统情况下，在这两个环境之间移动代码充满了技术错误，冗长的时间延迟以及组织层面的沟通不畅。

　　几年前，一些有趣的事情发生了：Linux对于大多数企业足够友好，Linux的变体在商业上免费—但是这不足以影响技术架构。

　　接下来，开源的创新与敏捷开发技术的结合鼓励了开发人员创建各种工具，将许多繁琐的运维手工操作自动化。这被许多人称为DevOps革命。

　　这场革命使得开发团队和IT运维人员通过使用Puppet、Chef和Docker等高级工具更加紧密地联系在一起。意外地，Linux的变体允许免费操作，开发人员可以在不受干扰的情况下将其组件部署到一个原始的操作系统。一整个可能的错误类别就突然消失了，因为组件之间能够相互解耦。

　　如果开发人员可以构建他们自己的现实环境，他们必须减少与运维部门的协调，也就减少了组织间的摩擦。用程序启动类生产环境的能力消除了测试、集成、共享环境下的资源竞争、以及一系列其他问题。

　　21世纪的架构敏捷度

　　在治理方面，微服务架构风格有其他的好处。传统的做法是，企业架构师定义了组织的共享技术栈，以最大化项目间的资源使用，同时最大程度地减少支撑成本。例如，一个大型企业可能将Java和Oracle标准化以作为其主要开发平台。如果每个人都使用Oracle，那么该企业的一切都可以存储在一个工业强度的数据库中。

　　规范化治理有一个缺点—通常，为了标准化的某一目的，团队必须使用并不太理想的工具。与此同时，还有一个潜在的更微妙的缺点。例如，考虑一个已经选择在特定消息队列上标准化的大型企业。在评估需要此共享基础设施的所有项目时，企业架构师会找出最复杂的场景，并选择一个适合这种复杂度的工具来处理它们。

　　然而，许多项目并不具备这个最复杂的场景。但因为每个项目必须共享相同的基础设施，所以每个团队都得承担其他团队的最大复杂度。这种情况也发生在数据库层。许多项目只需要几个记录的简单数据存储，并不需要复杂的查询功能，但最终都使用了具有工业强度的数据库服务器，只因为这个企业的标准如此。

　　容器化技术解决了这个问题，因为它远离了共享基础设施—每个项目都部署在自己原始的、容器化的环境中。因为不存在共享的动力去选择工具，直播，所以每个项目刻意选择更适合自己的工具。

　　当然，如果企业架构师允许每个项目选择自己的技术栈，那么会存在一些严重的缺点。我们经常看到一个称之为““Goldilocks治理”（企业架构师选择几个技术栈—简单、中等和复杂，并根据规模分配新项目）的实践，它适用于高度解耦的环境。这些知识是可迁移的，该公司仍然可以从中受益，但是却可以远离那些由于疏忽大意而将问题过于复杂化的行为。

　　为什么我们会谈到这儿？

　　一书对微服务架构发展产生了巨大的影响。它介绍了一种将大问题空间分解为领域或重要实体（如客户和订单）及其关系（客户下订单）和行为的技术。领域定义的一部分是有关边界上下文的概念：每个领域形成一个围绕实现细节的封装层。

　　例如，如果分析人员识别了一个Customer领域，那么它存在于自己的边界上下文中。在Customer的上下文中，开发人员知道所有的实现细节：类结构，数据库模式等。