（接前文）

组织转变

这一节我们将讨论为了更好地应用云架构，组织在建立团队方面将如何改进。这个理论的背后是著名的Conway’s Law，我们的办法是围绕一个长期的产品线建立多职责的团队，而不是鼓励每种职责的人员呆在自己单独的团队里（比如testing）。

（接前文）

需要转变

文化转变

从竖井到DevOps

企业IT常常被组织为一些竖井：软件开发、QA、DBA、系统管理、运营、发布管理、项目管理等。这些竖井往往有不同的管理层次、工具集、沟通方式、词汇和激励形式。这些不同鼓励了做事方法的不同。

（接前文）

云架构的定义

十二因子应用

“十二因子应用”是一些云架构模式。它们专注于速度、稳定、伸缩，主要包括强调声明性配置、无状态和无共享的横向伸缩进程、全面与部署环境解耦合等方面。当前大量的云平台都为部署十二因子应用优化。

在“十二因子应用”的说法中，“应用”指的是单个部署单元。

十二因子应用表述为：
（省略，可参见官方中文版：十二因子应用）

原文：Migrating to Cloud-Native Application Architectures

本文为“节选译”，不是逐句逐段翻译，是意译和无废话译。

云架构的兴起

创新型公司遇到的问题是：

• 创新的速度
• 总是可用的服务
• Web的伸缩
• 移动为中心的用户体验

“首席程序员负责制”是我常向团队推荐的一种敏捷实践。

（接上篇）

业务正确性和容错性

系统不仅需要业务功能结果正确，还需要在业务发生问题的时候能够尽量多的提供诊断和恢复支持。

（接上篇）

可用性

可用性风险通常比较被重视，企业默认架构中往往有较多应对措施。而且很多可用性风险与性能与容量风险有关，所以这里总结的风险和保障措施显得比较少。

“服务化”，就是既有系统进化为“服务”的努力。

什么是服务？每个架构师都有不同的定义，在不同的场景下可能也有不同的定义。

为更好的应对业务快速变化带来的挑战，许多系统正在从“关联系统”角色向着“服务”角色转变。这样的转变对系统各方面质量特别是运行时质量提出了不一样的要求。如何管理并始终满足这些要求，打造弹性、容错、可管理的服务，是我们需要重点考虑的问题。

已复制到gitcafe——

http://nielinjie.gitcafe.io

github.io的访问（由于它前面的墙）不太稳定，现保存一份copy在gitcafe，两边同步发布。