amazon-cloud-computing-best-practices

原文: http://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html

翻译: infoQ.cn

近日，Amazon.com CTO Werner Vogels撰文总结了AWS上线10年来收获的十大经验。我们一起来看看。 

1.构建可演进的系统（Build evolvable systems）

从第一天起，我们就知道今日所构建之软件和一年后所运行的并不一样。我们需要不断地回顾和修定架构，以解决伸缩问题。但是，因为很多业务要求云平台提供7*24的可用性，所以不能采用老式的停机升级方式。我们需要构建这样的架构——可以在不关闭服务的情况下引入新的软件组件。

2.容忍意外（Expect the unexpected）

失效是不可避免的，什么都会随着时间的流逝出现问题：从路由器到硬盘，从操作系统到内存单元，从瞬态错误到永久失效，等等。问题无处不在，不管是使用高质量的硬件还是低成本的组件。

在大规模系统设计方面，很多失效场景可以提前预料到，但更多的是在设计和构建时无法预料的。

系统应该将失效看作很自然的事，即使我们不知道是什么样的失效。能够管理受影响的部分（控制“爆炸半径”），而不用停掉整个系统服务，这点非常重要。

3.提供原语而非框架（Primitives not frameworks）

客户使用服务的方式也是在探索之中。客户离开原有的IT硬件和数据中心，开始以之前从未有过的新的、有趣的模式来开发系统。所以需要提供的东西必须非常灵活，满足客户需求。

AWS提供的最重要的机制之一，就是向客户提供一组原语和工具，他们可以以自己喜欢的方式使用AWS云，而不是提供一个框架强迫他们使用。这种方式使客户取得了很大的成功，而新一代的AWS服务也可以使用客户已经习惯的基本服务。

还有一点非常重要，很难预测某个服务对用户而言优先级如何，除非把服务交到他们手上。所以AWS的做法是，新服务提供最小特性集，让客户驱动服务的演进，然后增加新特性。

4.自动化是关键（Automation is key）

开发需要运维的软件服务和构建交付给客户的软件截然不同。管理大规模系统要求不同的思维模式，以满足客户的可靠性、性能和伸缩性预期。

关键机制就是尽可能将管理自动化，避免容易出错的人工操作。要实现这一点，需要构建控制关键运维功能的管理API。

这方面做的如何，有个很简单的检验手段：如果需要SSH到某个服务器或者实例上去，说明自动化程度还不够。

5.API百世不易（APIs are forever）

对于AWS这种以API为中心的业务，这一点特别重要。一旦客户开始使用我们的API构建应用和系统，再想修那些API就不可能了，因为会影响客户的业务。设计API非常重要，必须一次成功。

6. 关注资源使用（your resource usage）

在为某个服务构建财务模型，以找出恰当的计费模型时，要确保服务及其运维的成本有个不错的数据，尤其是运行大容量、低利润的业务时。AWS也需要充分意识到成本，提高运维效率。

在S3上线之初，资源按存储和带宽收费；但是不久之后，AWS团队意识到，请求数也是一个重要的资源。如果客户有很多小文件，存储和带宽用的并不多，即使有数百万请求。所以他们调整了模型，考虑各种资源使用维度。

7. 一开始就将安全考虑进去（Build security in from the ground up）

保护客户是第一位的。服务设计之初就应该将安全考虑进去，而不是等服务构建好之后找安全团队来验证。涉及安全，不能有任何妥协。

8. 加密是一类需求（Encryption is a first-class citizen）

对客户而言，加密是个关键机制，因为他们要确保对数据访问的完全控制。10年前，加密用的工具和服务很难使用，直到几年前，AWS才学会了如何将加密最好地集成到服务中。

9. 网络的重要性（The importance of the network）

AWS要支持很多不同的负载，从大容量事务处理到大规模视频转码，从高性能并行计算到大流量Web网站。这些负载对网络都有独特的需求。

AWS在数据中心布局和运维方面也有了独特的技术，比如灵活的网络基础设施可以加以调整，满足客户的负载，不管是什么类型的。AWS设计的网络硬件和软件对于进一步改进客户应用的性能也很有意义。

10. 保持开放（No gatekeepers）

AWS团队已经交付了很多服务和特性，但是更重要的是，围绕这些服务构建起来的生态系统。很多客户基于AWS的平台搭建服务，提供更为垂直的一些需求。AWS平台上并没有守门人（gatekeepers）这样的角色，告诉合作伙伴什么能做，什么不能做。这样会有更多创新出现。

希望这些经验对大家有所帮助。