the twelve factor app

https://12factor.net/

https://pivotal.io/beyond-the-twelve-factor-app

he Twelve-Factor App1

从一个代码库部署到多个环境

一个代码库，包括生产环境软件包，确保了单一的信任源，从而保证了更少的配置错误和更强的容错和复原能力。

2

依赖管理是声明式的

云平台根据这些声明管理依赖，确保云应用所需的库和服务。

3

配置信息保存在环境中

环境变量是一种清楚、容易理解和标准化的配置方法，特别适合用不同编程语言编写的无状态应用的使用。

4

将后台服务视为附加的资源

将每一种资源都视为一种远程的资源，应用因此具有容错和复原能力，因为它一方面要求编码时就要考虑资源不可用的情况，另外一方面也增强微服务方法的好处。

5

区分构建、发布和运行阶段

cloud-native应用的构建流程把大部分发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。

6

作为无状态进程运行

尽量保持应用栈每一层的轻量级，保证cloud-native基础设施的速度和效率。

7

通过端口绑定对外暴露服务

cloud-native应用的服务接口优先选择 HTTP API 作为通用的集成框架。

8

通过添加无状态进程实现横向扩展

强调无状态、无共享的设计，这意味着依赖底层平台就能实现横向扩展，不需要技术难度高的多线程编码。 

9

快速地启动，优雅地关停

假设任何进程随时都能启动和关停。 

10

开发、预发布和生产环境运行同样的应用和依赖配置

由于强调自动化和在每个阶段使用同一个云平台，如果每个人用同样的服务器配置，那么“应用在我这里是可以的”就意味着在其他人或者环境那里也是可以的。 

11

日志输出到标准输出，方便日志聚合和事件响应

当日志是由云平台而不是应用包含的库处理时，日志处理机制必须保持简单。

12

临时任务作为短时进程运行

在cloud-native中，管理任务也是一个进程，而不是特别的工具;同样重要的是，管理任务的进程不应使用秘密的 API 或者内部机制。

http://www.infoq.com/cn/news/2016/07/Heroku-CloudNative

料附：Cloud Native时代12新要素

1. 从一个代码库部署到多个环境——一个代码库，包括生产环境软件包，确保了单一的信任源，从而保证了更少的配置错误和更强的容错和复原能力。
2. 依赖管理是声明式的——云平台根据这些声明管理依赖，确保云应用所需的库和服务。
3. 配置信息保存在环境中——环境变量是一种清楚、容易理解和标准化的配置方法，特别适合用不同编程语言编写的无状态应用的使用。
4. 将后台服务视为附加的资源——将每一种资源都视为一种远程的资源，应用因此具有容错和复原能力，因为它一方面要求编码时就要考虑资源不可用的情况，另外一方面也增强微服务方法的好处。
5. 区分构建、发布和运行阶段——Cloud Native应用的构建流程把大部分发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。
6. 作为无状态进程运行——尽量保持应用栈每一层的轻量级，保证Cloud Native基础设施的速度和效率。
7. 通过端口绑定对外暴露服务——Cloud Native应用的服务接口优先选择 HTTP API 作为通用的集成框架。
8. 通过添加无状态进程实现横向扩展——强调无状态、无共享的设计，这意味着依赖底层平台就能实现横向扩展，不需要技术难度高的多线程编码。
9. 快速地启动，优雅地关停——假设任何进程随时都能启动和关停。
10. 开发、预发布和生产环境运行同样的应用和依赖配置——由于强调自动化和在每个阶段使用同一个云平台，如果每个人用同样的服务器配置，那么“应用在我这里是可以的”就意味着在其他人或者环境那里也是可以的。
11. 日志输出到标准输出，方便日志聚合和事件响应——当日志是由云平台而不是应用包含的库处理时，日志处理机制必须保持简单。
12. 临时任务作为短时进程运行——在Cloud Native中，管理任务也是一个进程，而不是特别的工具；同样重要的是，管理任务的进程不应使用秘密的 API 或者内部机制。

https://github.com/netflix/simianarmy

Chaos Monkey