AWS reinvent 2016：Primitives not framework
Transformation 是本次 Werner Vogels keynote 的主题。为了契合这个主题，他还穿了印有汽车人标志的T恤上台演讲。这个 keynote 非常值得反复观摩 —— 整个 keynote 的表面上的核心是：我们如何通过 development，data，compute 上的革新来帮助客户成为 internet scale 时代的 transformer，但细思下去，这是一个 aws 架构蓝图和产品路线图的一个回顾和总结。
Werner 把这总结分成了三个部分：development，data，compute。
Development
internet 时代的软件开发有很多挑战，尤其在运营（运维）上。软件需要构建，部署，监控，动态伸缩，保证安全性等等。
之前 aws 对于运维的支持主要体现在各种产品，从计算到存储到数据库到消息队列等等的 scaling 上，几乎所有的工具都具备 internet scale 的能力。然而，由于其它运维工具的缺失，用户不得不采用第三方的工具：监控使用 new relic / datadog / …，构建使用 travis / codeship / …，日志处理使用 loggly / splunk / … 各种各样的第三方工具增加了额外的研发开销。
所以，很自然地，amazon 将触角延伸到了这个领域。之前的 codeCommit，codeDeploy，codePipeline，opsWorks 等只是序曲，今年发布的一种服务，让整个运维的拼图更加完整：
- AWS OpsWorks for Chef：Chef 的支持装进了 OpsWorks
- Amazon EC2 Systems Manager：对于 EC2 从软件安装，系统更新，资源配置等一系列运维活动进行管理。
- AWS Codebuild：在 codeCommit 和 codeDeploy 中缺失的环节终于被补齐了。直接对现有生态圈中的 travis 等构建工具造成威胁。
- Amazon X-Ray：千呼万唤始出来，aws 终于有了自己的 APM 工具。new relic 们要当心了。
- Personal Health Dashboard：这个貌似是对服务状态的一个监控，让你了解你自己的软件是否处在一个健康水准。
- AWS Shield：在不同的层级上对 DDOS 进行自动防范。DDOS 已经成为 internet scale 时代的一个公害，最近对 DNS 服务的 DDOS 让包括 github 在内的很多公司都吃了瘪。
这里面，最振奋人心的是 X-Ray 服务。分布式系统的调试和性能监测是个复杂的问题，传统的 APM 只能通过在目标机器上装 agent 来收集代码运行的状况。如果目标系统无法安装 agent，则无能为力。在 aws 的 serverless 架构下，lambda，dynamodb 等都属于性能监控的黑洞。而 X-Ray 由于是 amazon 自家的监控产品，自然能拿到第一手的可信资料。
Data
Werner 在这个环节里在玩一个拼图游戏，他把数据分析的工作分成了十个部分：
- automated and reliable data ingestion：数据的收集目前有 S3，Kinesis，snowball，dynamodb streams
- perservation of original source data：源数据的持久化可以通过 S3，EFS，EBS，dynamodb，RDS 完成。
- lifecyle management and cold storage：S3 / glacier 提供了完整的数据 life cycle —— 热数据到冷数据的全部方案。
- metadata capture：
- managing governance, security privacy：这是 aws 的强项，aws config，cloudTrail 进行配置和监控；KMS 对数据进行安全保障（confidentialality，accessibility，consistency）。
- self-service discovery, search, access
- managing data quality：elastic mapreduce 可以对数据进行处理。
- preparing for analytics
- orchestration and job scheduling
- capturing data change
然而，如上所示，这个拼图只完成了一半：
因此，新发布的 AWS glue，通过 data catalog 和 ETL 支持，把另一半也囊括了：
由此，我们可以拥有一个完整的数据处理架构：
Compute
2014 年，aws 发布了 lambda，作为其计算架构的一个补充。自此，数据库有了 serverless 的 dynamodb，计算方面又有了 serverless，pay as you go 的 lambda。一个应用程序，可以通过 S3 web hosting（SPA） + API gateway + lambda + dynamodb，不用任何一台服务器搭建而成，且能够满足海量的访问，基本不存在任何 scaling 的问题。某种程度上，lambda 是 aws 有勇气自我革新的一大佐证。在使用 lambda 之后，原先很多 EC2 / ECS 使用的场景可以被取代，用户可以用更小的花费完成更多的工作。尤其后来 API gateway，dynamodb stream，s3 event 可以触发 lambda，更是让 lambda 的使用场景大大扩展。下图是 EC2/ECS/lambda 的一个对比：
在 aws 的计算版图中，lambda 的地位越来越重要。此次发布的 AWS step function 和 lambda@edge 几乎预示了未来 internet scale 应用的发展方向。
先说 lambda@edge。对于这个无比重要的功能，Werner 几乎是几句话带过。
aws 把 lambda 放在了 CDN 中！
aws 把 lambda 放在了 CDN 中！
aws 把 lambda 放在了 CDN 中！
这画面美得不要不要的！以前 CDN 只能分发静态内容，或者对要分发的静态做一些预置的处理，比如说图片的 resize。lambda@edge 把对内容进一步处理的选择权交给了用户 —— 应用程序开发者。使用 cloudfront + lambda@edge，突然之间，我们有了把处理能力部署到全球（不包括我大宋），到离用户最近的地方。
我举个栗子。客户端访问 CDN 上某个视频。根据 user-agent，lambda 可以把对这个视频的访问 rewrite 成另外一个 url（比如 appletv 提供 1080p 的视频，iphone 提供 480 的视频）。这对于像 tubitv 这样拥有十几种客户端平台的应用来说，可以对外只使用一个视频 url。
再举个桃子。客户端界面的 A/B testing 可以在 CDN 上完成。lambda 可以解析 http request 里面的 cookie（或者 query string 里的 device id，authorization header 里的 token 信息），来确定访问者的身份，从而为其提供合适的 A/B testing 资源。
甚至，我们可以对图片 / 短视频 / 语音资源 进行 on-the-fly 的 transcoding。比如说对于一个视频广告平台，其广告是动态获取的，为了适应不同的平台访问，需要转码。如果这个操作在 CDN 端完成，而非 CDN -> origin -> transcoding -> origin -> CDN 走上一大圈，那么第一次访问（广告还没有被转码）时的用户体验会大大增强。
再说说 step function。它把 lambda 的能力大大提上了一个台阶。连 Werner 本人都说，这是本次 keynote 最重要的产品发布！
我们知道，lambda 虽然有按使用次数付费，几乎无限的 scaling 能力，但限制其大范围使用的一个很重要的原因是不好管理和协同。每个 lambda function 都是一个松散的，事件触发的微服务，如果要让多个 lambda functions 协同完成一个复杂的状态机，开发和管理起来会非常痛苦。拿最重要的同步来说，目前我们的方式是：function chaining，database 和 queue。这些方式都各有优劣。
我们希望有一套更好的控制流程来管理和同步 lambda，并且将这个流程可视化，让一个状态机的处理一目了然。step functions 提供了这种可能：
把 step function 和 X-Ray 结合起来，lambda 协同困难和调试困难的局面将得以大大缓解。以后等我实验过 step function 后，再详细讲讲它的能力和不足。
以上是我对 Werner 的 keynote 的一些我认为重要的功能的解读。完整的 keynote 已经在 youtube 上可以访问，大家不妨去看看。
细心的读者看到这里，心中可能存疑：本文的标题是 primitives not framework，文章都快收尾了，怎么这句话提都没提？
这句话出自今年 Werner 的一片博文（allthingsdistributed.com）：10 Lessons from 10 Years of Amazon Web Services，当时我甚至为此写了篇解读，只不过自觉质量不高，狗尾续貂，就没好意思发出来。
翻看当时的文字，其中有一段，我是这么写的：
Primitives not frameworks —— 醍醐灌顶。当 Google 意识到这一点，废掉 GAE，祭起 GCE 反攻时，为时已晚。从战略的角度，IaaS 以一种传统 IT 企业，IT 人才都懂的方式（computing，storage，database，IPC）提供乐高积木，任由这些对新生事物还缺乏信任的人们以其熟悉的方式灵活构建或者重塑它们的系统。这个过程漫长一些，但稳当。而 PaaS 则试图一步到位，提供一个优秀但固化的架构，把一切统筹起来。表面上看，PaaS 怎么看怎么比 IaaS 先进，但由于步子迈得太大，学习和迁移成本过高，传统企业用不了（跨度太大），创业公司用不好，反而败给了看似更落后的 IaaS。当 amazon 把 storage，computing，database 这些 primitives 构建完善，客户用得得心应手后，顺势切到 PaaS，提供各种各样的高端功能，才是正确的方式。
从 2006 起，aws 就一直在稳稳当当地提供云时代的 primitives：
- 计算：ec2，ecs，lambda
- 存储：s3，s3 infrequent access，glacier，snowball，snowmobile
- 数据库：rds，aurora，dynamodb
- 消息队列：sqs
- 大数据：kinesis，redshift，emr，elasticsearch service
- 安全和身份识别：iam，sg，kms，directory service
- 网络：route53，vpc，cloudFront
- 运维：cloudWatch，codeCommit，codeBuild，codeDeploy，opsWorks，X-Ray
这个家族从起初的几种核心服务，一路狂飙到现在的几十种服务，涵盖打造 internet scale application 的方方面面。它提供了足够的灵活度：你可以自己在 EC2 上构建一个 machine learning 的系统，也可以使用 EMR 专注于你的模型的打造，甚至，如果你想处理图片识别或者语音识别，你还可以直接使用 Rekogniton / Lex 等工具。它们构建了一个无可匹敌的 herd，一个互为支援的航母战斗群：
而它的老对手们，已经被甩得越来越远。
这是好事，也是坏事。衷心希望 azure 和 GCE 能够大踏步追赶，让这个领域始终保持充分的竞争，这，才是用户，甚至整个行业的幸事。
software is a mindset，not a skillset。
