要素6提到：“每个微服务应在独立隔离的进程中执行，将所需状态信息作为外部支撑性服务，例如分布式缓存或数据存储”

最佳实践是将支撑性服务视为附加资源，并使用外部挂载的方式将配置(URL和凭据)动态绑定到微服务。

要素4指出：“支撑性服务“应通过可寻址的URL公开，这样做解耦了将资源与应用”

要素3指出：“将配置信息从微服务中移出并外挂”

Stateless和支撑性服务，这样松散的设计使你可以将一项支撑性服务换成另一项支撑性服务，或将代码移至其他公有云，而无需更改主线服务代码。

支撑性服务将在第5章“云原生数据模式”和第4章“云原生通信模式”中详细讨论。

自动化

如你所见，云原生依赖(微服务、容器和现代设计理念)来实现速度和敏捷性。

但是，你如何配置运行这些系统的云环境?你如何快速部署应用程序功能和更新?

被广泛认可的作法是基础设施即代码(IaC)

借助IaC，你可以将平台配置和应用程序部署自动化，将诸如测试和版本控制之类的软件工程实践应用于你的DevOps实践。你的基础架构和部署是自动化，一致且可重复的。

Automating infrastructure

在底层，IaC是幂等的，这意味着你可以一遍又一遍地运行相同的脚本，而不会产生副作用。

如果团队需要进行更改，可以编辑并重新运行脚本，(仅)需要更新的资源受到影响。

在《基础架构即代码》一书中，作者Sam Guckenheimer指出：“实施IaC的团队可以大规模、快速、稳定地交付。团队不用手动配置环境，通过代码表示 需要的环境状态，来增强交付预期。使用IaC进行基础架构部署是可重复的，可防止由于配置差异或缺少依赖关系而导致运行时问题”。

Automating deployments

"十二要素应用"指出了从代码开发到交付落地的原则

要素5指出：“严格区分构建、发行和运行阶段。每个发行阶段都应标有唯一的ID，并支持回滚功能。”

现代CI/CD实现了这一原则。它们提供的独立部署步骤，确保将一致的、高质量的代码交付给用户。

下图演示了独立的部署过程：