Werner Vogels 脑中的未来世界 @AWS re:Invent 2017

2017 年 11 月 30 日，拉斯维加斯。这是 Werner Vogels 第六次站在 AWS re:Invent 主题演讲的舞台上。作为 AWS 的 CTO，多年来他发起、参与并见证了无数的变化，但是有一件事情一直没有变过——

他一直在想象一件事：未来的开发会发生怎样的变化？

“虽然我无法预测五年后的世界会变成什么样子，正如同五年之前的我无法预测今天一样。但是有一点我们非常清楚：靠我们自己是无法把 AWS 建设成今天这样的。不是我们去教育开发者们应该如何开发软件，而是他们教会我们应该去开发怎样的软件。”

“举个例子，当年我们之所以开发 DynamoDB，是因为我们听到了开发者对于另一种数据库的需求。然而当我们发布 DynamoDB 的时候，我们并不知道开发者们会需要 IAM 层面的访问控制功能。是开发者们教会我们 DynamoDB 的服务应该要怎样去做。”

“我们的发展路线图掌握在你们手中。”

以后的 App 开发会是怎样的？

想象的能力建立在观察的积累之上，观察的积累建立在用心的基础上。技术提供方与技术需求方之间的交流，本质上是人与人之间的交流。当客户有意或无意间说出一句话的时候，身为希望去帮助客户解决问题的这一个人，他听到了什么？他听见了什么？

“一位 GE 客户曾经说过一句话：我们晚上睡觉的时候还是一家制造公司，结果一觉睡醒，变成一家数据分析公司了。”

Vogels 举了这个例子之后，说了两件事：

1、机器学习领域过去两三年的发展，最大的意义在于两个字：“实时”。实时在线数据和离线历史数据完全是两码事。TensorFlow 和 MXNet 这样的神经网络框架，有它们和没有它们最大的区别就在于是以天为单位出结果，还是以秒为单位出结果。以天为单位出结果，就限制了只能对那些离线的历史数据进行学习。以秒为单位出结果，才使得我们有能力对现在正在发生的事情进行学习。

Real time 这个词组在 Vogels 大叔的这段话里至少出现了三次。我想他应该是希望我们听见什么。

2、大家为什么要花费这么大精力来到我的 Keynote 现场呢？为什么你的爷爷奶奶除了 Skype 之外不会用别的 App？为什么菲律宾的贫困农民不会用智能手机 App 来改进他们的生产？为什么同样的人机交互方式，我们就可以无障碍的使用，他们却不行？

有的观点会说，如果他们真的需要某个 App，他们肯定还是能学会的。之所以学不会，是因为他们还并没有那么想要这个 App 的功能。

Vogels 绝对不认同这个观点。

“他们怎么可能会不想要？”

图：迄今为止的人机交互方式

“我们之所以具备了人机交互的能力，是因为我们去适应了机器的交互方式。我们学会了使用键盘、鼠标和屏幕，是因为我们具备了特定的学习条件，但这些并不是人类的自然交互方式。大家来到我的 Keynote 现场，难道会是为了来看我背后这块屏幕的吗？肯定不能！你们是来听我说话的。”

“未来的软件一定要去适应人类天然的交互方式。人类天然的交互方式就是说话、倾听。这是你的爷爷奶奶和菲律宾的农民们都会用的交互方式。”

图：以人类为中心的交互方式

的确，Amazon 是已经发布了 Echo 设备，发布了 Polly、Lex、Transcribe 和 Comprehend，以及基于其所构建的 Alexa for Home、Alexa for Business 服务，但这些只不过是微不足道的小小几步。这个领域需要更多开发者们的关怀，需要开发者们持续不断的进行更多的观察和想象。

以上是 Vogels 对于机器技术栈的最上层——人机交互接口层面的未来思考。

“语音能力一定会是下一代系统的构建核心，这也是深度学习技术将发挥重大意义的第一个阵地。”

其实从技术背景来说，Vogels 的关注点主要是在底层技术栈，应用层的工作算不上 AWS 的主业。如果是强调语音交互能力的战略重要性，完全可以由 AWS CEO Andy Jassy 而不是 Vogels 来讲。如果只是产品发布的话，这次连 GuardDuty 这个量级的安全服务都没上主题演讲（GuardDuty 这次是安排了一次晚场活动做的发布，该服务利用机器学习技术实现了一些威胁自动报警的功能），Transcribe 和 Comprehend 在 Andy 的演讲里都只是在中间小小的露了一个脸，Alexa for Business 身为一个应用层服务，为什么能排在 Vogels 演讲的第一部分、而且还占了这么大篇幅呢？InfoQ 编辑认为，Vogels 来讲语音交互这个事情是想表达他的一个态度：

他觉得开发者们现在对语音交互领域的关注力度实在是太不够了。

所以，Vogels 要动用自己技术领导者的影响力来号召开发者们赶紧往这个方向多跑跑。

回到底层

讲完语音交互，Vogels 把话题收回到 IT 架构的底层领域。

底层的几件事主要是在实践层面，即所谓的“最佳实践”推荐。“最佳实践”在 AWS re:Invent 期间有很多专门的课程，此类课程特别受到一线工程师们的欢迎。其实这些最佳实践，Vogels 想必已经说了不知道多少遍了，可是他还是继续说。也许他觉得听进去的人还不够多吧？

技术细节在主题演讲的有限时间也讲不了太深，InfoQ 编辑在这里给 Vogels 的分享做个简单的综述。

第一件事：别让你的架构被最初的计划限制死了。你还在预测“我两年后会需要多少容量”这件事吗？那已经是老黄历了，现在再这样做是要坑死自己的！请从一开始就以“可以伸展的方式”设计你的架构（extensive architecture）。

第二件事：安全必须在所有工作之前进行。安全的优先级高于任何一个特性开发！你的每一位开发者都应该是一个安全工程师。与此同时，如果你想确保你的数据只有你自己能访问，那么加密是唯一的保证（Vogels 在这里提到了本次 re:Invent 发布的 KMS 服务——bring your own keys）。当然，你一定会需要各种自动化工具来记录系统的一切变化、检测系统的任何异常——Macie 和 GuardDuty 就是做这事儿的。

第三件事：你需要更好的开发工具。也许你可以试试我们的 Cloud9 IDE？

图：与 AWS 各服务深度集成的 Cloud9 IDE

第四件事：关于可用性的一些常识。如果你在一个可用性区域（AZ）上部署，其基础架构的理论可用性是 99%。如果你想要四个九，你可能会需要三个 AZ，这意味着三倍的成本。如果你想要五个九，你还需要跨区域部署（region），这意味着六倍的成本。所以在讨论可用性之前，请搞清楚你想要什么。比如，在 AWS 的工程师们就很清楚的知道 Route 53 服务是绝对不能挂的，所以这个服务的可用性做到了绝对的 100%，不骗人。而其他的服务，则根据各自的情况来进行各自的决策。

第五件事：关于测试的一些常识。你还在“测试环境”里做测试吗？别逗啦。这年头，生产环境才应该是你的测试场地。强烈推荐大家都学习一些“混乱工程学”（Chaos Engineering），并在自己的生产系统上赶紧用起来。这一段邀请了 Netflix 的美女工程师、《Chaos Engineering》的作者之一 Nora Jones 为大家上台做了一次科普。这本书的英文电子版可以在他们的网站 Principles of Chaos 上查看。

图：Chaos Engineering 是怎样做的

第六件事：Gall’s Law——可用的复杂系统在一开始都是可用的简单系统。如果你的起点是一个复杂系统，那么最可能得到的结果是一个不可用的复杂系统。你问我怎么才能让系统不那么复杂？我的第一个建议是微服务——不仅仅是容器，同时还需要正确的微服务设计思路、以及好用的容器管理工具。欢迎早点来试试我们的 EKS（Kubernetes）和 Fargate！第二个建议是无服务。Vogels 在这里介绍了 Lambda 最近的一些新功能，包括 API Gateway VPC 集成、并发控制、3GB 的内存、以及.NET core 2.0 语言的支持，同时还发布了 AWS Serverless Application Repository 。

图：Vogels 举例说明无服务（Lambda）的一些实际用法

第七件事：SageMaker！

当 Andy Jassy 正式把 SageMaker 的消息对外发布的时候，Vogels 在 Twitter 上发了一条推：

“SageMaker 有多么重大的意义呢？那就是无论我描述它有多大的意义都不算过分。”

按照 AWS 的惯例，新产品正式对外发布之前都是已经有内部选定的客户秘密使用过一段时间的，对于 SageMaker 而言，DigitalGlobe 就是其中的一个客户。他们是做卫星地图数据的，数据采集了 17 年下来攒了有 100PB。因为这个数据量太大，所以他们首先是成了 AWS Snowmobile 的用户——对，你没想错，就是在 2016 年 re:Invent 上台的那辆卡车：

100PB 的图片在 AWS 上放着，成本实在不低，所以很自然的当作冷数据放进了 Glacier。但是这些图片数据还需要拿来做分析，怎么办？所以 Glacier Select 相当于也是 AWS 配合他们家的需求做的。分析、预测的需求场景那就比较多了，比如从他们自己的层面，需要提升图片缓存命中率；从他们客户的层面，比如某国运营商要部署 5G 网络，会问他们要全国树木的分布情况；某国森林大火要做紧急疏散，会问他们要疏散方案等等。现在，他们在 SageMaker 上每天分析的图片量有 80TB。

图：在某城市卫星地图上标记所有的树木

SageMaker 的意义还不止如此。如果你已经试用过 SageMaker（如果还没有，建议去注册一个 AWS 账号试试，这个服务现在可以免费试用），你大概已经知道 SageMaker 上的训练建模代码是写在 Jupyter Notebook 里面的。然后，Jupyter Notebook 是可以分享的！DigitalGlobe 就把他们的一个 GBDX Notebooks 分享了出来，这套代码是用来从图片里抽取特征的。我想，他们会很希望看到有人能对这套代码进行一些改善。

总结

看完了 Vogels 的分享，你的收获如何？关于最佳实践部分的内容，除了本次 re:Invent 大会上的现场课程之外，有条件的同学也可以了解他们在各地的 AWSome Day 、培训课程，或者是白皮书。