关于作者
原文作者Werner Vogels作为亚马逊首席技术官（CTO）和副总裁，是AWS的灵魂人物，也是云计算领域响当当的顶级专家。Werner Vogel拥有计算机博士学位，主要负责驱动亚马逊的技术创新，Werner还曾是康奈尔大学计算机系的研究科学家，主要研究高可靠高可扩展的企业系统。2004年加入亚马逊担任系统研究总监，2005年1月被任命为CTO和副总裁至今。Werner Vogels也是殊荣多多，因其在云计算的教育和推广方面的贡献，被信息周刊（InformationWeek）评为“2008年度CTO/CIO”；2010年被ReadWriteWeb读者投票评为“最具影响力的云计算高管”。
亚马逊在2006年3月14日发布AWS，到现在差不多10年了。回首过去的10年里，我们在构建 安全，高可用性，可扩展性，低成本的服务方面积累了几百条经验与教训。 由于AWS是建设并在全球运营这些服务的先驱，这些教训对我们的业务至关重要。正如我们以前多次说， “没有压缩经验的算法”，每月有超过百万的活跃客户，这些客户服务几个亿的用户，在这个过程我们不乏机会积累经验并持续优化从而为客户提供更好的服务。
我选择了下面这些经验教训，与大家分享，希望它们对你们有用。
1. 构建不断进化的系统
几乎从第一天开始,我们知道自己开发的软件在一年后将不会继续运行。我们需要重新审视和改进架构，以确保我们可以解决订单规模增长一到二个数量级所带来的问题。 但是我们不能采取停电检修这种旧方法升级系统，这是因为遍布世界各地的许多业务需要依靠我们的平台提供的7*24小时高可用性服务。我们需要建立这样架构：能够在不停止服务的情况下引入新的组件。Marvin Theimer,亚马逊杰出工程师，曾开玩笑地说，亚马逊S3的演变可以描述为从当初的单引擎飞机，随着时间的推移飞机不断升级，先是升级到737，然后一组747的，现在成了3805的空中舰队。在此期间，我们在飞行过程中完成加油，而客户甚至没有觉察到这一点。
2. 视异常为常态
异常总是会发生的，随着时间的推移，一切都将会出现异常：从路由器到硬盘，从操作系统到内存单元，从瞬态错误到永久性故障。无论你使用的是最高品质的硬件或最低成本的硬件，这些总是会发生的。在大规模系统中更是如此，例如，在S3中处理和存储的万亿级交易，任何异常，即使是最小的可能性也将成为现实。部分这样的异常可以事先预见的，但更多的异常却在设计和开发过程中未能被发现。
我们需要开发一个视异常为常态的系统，即使我们不知道会有什么样的异常。即使“房子着火了”，系统也需要保持运行。重要的是在整个系统在不宕机的情况下能够处理这些异常。我们掌握隔离异常与控制异常的影响范围的方法从而使整个系统能够正常运行。
3. 提供基元而不是框架
我们很快意识到，客户的需求是不断变化的。当客户摆脱传统的IT硬件和数据中心的限制，他们开始使用感兴趣却没有使用过的模式搭建系统。因此，我们努力做到超级敏捷以确保满足客户的需求。
其中一个最重要的策略是向客户提供的基元和工具，让客户从中选择最适合他们的集合，而不是只提供一个框架，迫使他们不得不使用。这种做法使我们的客户取得了成功，随后的AWS服务也同样利用这些客户已经熟悉的基础服务。
同样重要的是我们不知道客户下一个关心问题是什么，直到他们开始使用我们的服务。这就是为什么我们经常用最少的功能集提供新的服务，让我们的客户能够帮助推动产品路线图规划与新功能的开发。
4. 自动化是关键
提供云计算服务不同于开发并交付软件，管理大规模系统需要不同的思维方式，以确保满足用户的高可用性，高性能和可扩展性的需求。
这其中关键的一点是尽可能地实现自动化管理以避免容易出错的手动操作。要做到这一点，我们需要实现管理API从而管理我们的业务的关键功能。AWS可以帮助客户做到这一点。通过为应用程序的每一个分解组件提供管理API，从而应用自动化的规则来保证可靠性和预期的性能。
如果你需要SSH到一个服务器或一个实例，那么你仍然需要更多的自动化，这是一个衡量自动化水平的好方法。
5. API是一成不变的
这是我们从亚马逊零售业务经验中吸取的教训，它的重要性甚至超过了AWS中那些以API为中心的业务。 一旦客户开始使用我们的API构建他们的应用程序和系统，修改这些API是不可能，因我们修改这些API,会影响客户的业务运营。我们只有一次机会定义API,所以设计API是一个非常重要的工作。
6. 监控资源
当构建一个服务，一定要有服务及其运营成本的数据以确定相应的计费方式，尤其是对于运行高营业额-低利润率的业务。AWS理所应当关注服务的成本，这样我们在为客户的提供服务的同时能够明确在哪些地方可以提高运营效率，以进一步削减成本，以更低的价格回馈客户。
在创业初期，我们不知道S3服务应该采用哪种计费方式：我们曾认为应该对存储和带宽资源计费;经过一段时间，我们认识到请求的数量也应当计费。如果客户有许多微小的文件，即使他们上百万次数请求服务，消耗的存储和带宽都不会很高。我们不得不针对资源使用各个维度调整计费方式使AWS成为是一个可持续发展的业务。
7. 从一开始集成安全
保护你的客户应该永远是你的首选，对于AWS来说亦是如此。不管运营的角度，还是策略方面，这将永远是我们投入的头号领域。
我们很快地发现只有在一开始就把安全考虑进去才能提供安全的服务。安全团队的工作不是服务开发完成之后进行验证，他们必须在服务设计的第一天确认安全已经落实，且稳如泰山。总之对于安全，没有任何妥协。
8. 加密是一等公民
加密是为确保客户能控制谁有权访问他们的数据一个关键机制。十年前，加密工具和服务很难使用，直到几年前我们学会更好地将加密集成到我们的服务当中。最早的加密是从S3服务端开始的。如果您想检查我们的数据中心的任何磁盘，任何数据都不可访问的。但随着亚马逊推出CloudHSM（硬件安全模块）和Amazon Key Management Service（密钥管理服务），客户可以加密自己的密钥，从而不再需要AWS来管理钥匙。一段时间以来，每个新服务均支持加密。例如，Amazon Redshift的每个数据块默认以随机密钥加密，随后这些随机密钥被私钥再加密。私钥由客户提供，确保他们是唯一可以解密和访问他们的关键业务数据或个人身份信息。 加密仍然是我们业务的重点。我们将继续为我们的客户提供更加便捷的加密方式，使他们能够更好地保护自身及其客户的数据。
9. 网络很重要
AWS已经支持许多不同类型业务：大规模的事务处理，大规模网站流量，视频转码，高性能并行计算。其中每个业务具有独特的要求，但都涉及到网络。 利用AWS特有的数据中心技术，我们实现了弹性网络以满足客户的各种不同网络负载。随着时间的推移，我们确信自己开发的硬件解决方案能够帮助客户实现他们的目标。这使我们能够满足非常具体的要求，比如实现不同AWS用户在网络方面达到最高级别的安全（也就是实现不同租户之间的网络隔离）。
AWS设计的网络硬件和软件是如何进一步提高我们的客户性能的另一个成功的例子是解决虚拟机的虚拟网络访问的问题。由于网络接入是不同客户共享的，导致客户的网络访问时常有明显的抖动。开发一个支持SRIOV网卡让每个虚拟机拥有自身的虚拟网卡，从而使延迟时间降低2倍以上，并在延迟网络环境的改善超过10倍。
10. 保持开放
随着时间的推移，AWS团队通过提供多种服务和功能已经为客户创造了非常广泛且深厚的平台。AWS上现有服务数量远远超过我们开发的服务数量：通过我们的合作伙伴，该平台不断扩展新的方向，已经成为一个丰富的生态系统。
例如，我们合作伙伴Stripe在AWS上为Twilio提供支付服务。还有许多客户基于AWS构建自己的平台服务于特定垂直需求：飞利浦正在建设自己的Healthsuite数字平台来管理医疗数据，Ohpen已经建立了AWS零售银行业务的平台，Eagle Genomics已经建立了一个基因处理平台，还有很多。最重要的是，目前在AWS平台上没有条条框框告诉我们的合作伙伴，他们可以做什么和不能做什么。 没有条条框框的限制解放了创新，从而诞生了许多意想不到的发明，这是一定要遵循的原则。
原文：https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html
来源：oschina
链接：https://my.oschina.net/u/2277392/blog/3166132