将 AWS 引入应用开发

AWS 的确太难用了，但这并非你的错。今天我加入 Amplify，是为了帮助 AWS 为应用开发者构建更完善的框架，并壮大 Amplify 社区，让更多人能够公开学习 AWS。

泥浆

2006 年 AWS 正式重启时，杰夫·贝佐斯用一句著名的八个字概括了它的理念：“我们构建一切，所以您不必为此费心。”而他们也确实构建了大量的“垃圾” 。2006 年的发布包含三项服务（用于分布式存储的 S3、用于消息队列的 SQS 和用于虚拟服务器的 EC2）。截至 2020 年 1 月，服务数量已增至283 项。如今，仅仅在 AWS 的七种异步消息处理方式中做出选择，就足以让人感到选择疲劳。

AWS 服务的数量之多令人咋舌，但也充分体现了其以客户为中心的原则。除了极少数例外，AWS 几乎总是根据客户需求开发服务，并且从不弃用任何服务（即使是那些失败的服务），只降价。二十年来，AWS 一直坚持这样做，再加上互联网的飞速发展，服务数量竟然没有更多，着实令人惊讶。但最终的结果是，每个人都明白他们可以信赖 AWS，因为 AWS 的服务永远不会“出问题”。因此，AWS 品牌比任何服务都更有价值，因为它无法复制，必须靠实力赢得。AWS 几乎到了极致地将基础设施即服务 (IaaS)的稳定性放在首位，而作为回报，企业知道他们可以将最关键的工作负载交给 AWS。

这种权衡的代价是提升了对初学者的友好度。AWS 控制台这些年来取得了长足的进步，但几乎不可能使其适应超过一百万客户的各种用例和经验水平。对于应用程序开发人员来说尤其如此。AWS 对后端/IT 预算来说简直是天赐之物，它将基础设施的相对成本从 70% 降低到 30%，并通过提供虚拟服务器和弹性容量解决了资源利用率不足的问题。但对于在应用程序层面工作的开发人员来说，复杂性并没有降低。我们只是用一套按需的、更便宜（就总体拥有成本而言）、不熟悉的专有软件定义计算原语替换了一套基于硬件的计算原语。

在 IaaS 与 PaaS 的光谱中，应用程序开发人员想要的只是一个具有良好基础组件的成熟平台，而不是从头开始构建自己的平台：

这就是云发行版发挥作用的地方。

云发行版回顾

我之前写过关于云发行版概念的文章，但在这里我将概括一下要点：

• 从一开始，AWS 就被构想为“互联网的操作系统”（ Dave Cutler 和 Amitabh Srivasta在创建 Azure 时也采用了类似的比喻）。
• Linux 操作系统通常会附带一些用户友好的定制版本，称为“发行版”或简称“发行版”。
• 同样地，“平台即服务”的需求也得到了证明（但最终并没有达到巨大的规模）——2007 年的 Heroku 作为 Rails 开发人员的 PaaS，2011 年的Parse和Firebase分别作为基于 AWS 和 Google 的移动开发人员的 PaaS。
• PaaS（平台即服务）理念被证明是早早应验的——Kubernetes 和 AWS Lambda 在 2014 年的出现预示着现代云创业公司的涌现，从 Netlify 和 Vercel 等 JAMstack CDN，到 Repl.it 和 Glitch 等云 IDE，再到 Render 和 KintoHub 等托管集群，甚至包括 Darklang 等突破性实验。这些旨在提升应用开发者体验的方法多种多样，且都构建于 AWS/GCP 之上，因此我更倾向于将它们称为“云发行版”，而不是过时的 PaaS 术语。

放大

如果不算谷歌收购的 Firebase，Amplify 是第一个真正意义上的第一方“云分发平台”。但这并不意味着它就一定更胜一筹。恰恰相反！AWS 的入门门槛很高，有很多不可协商的要求（从需要预先提供信用卡信息到需要为基本演示设置身份和访问管理权限）。而且说实话，它的用户界面也注定与设计无缘。这足以让许多应用开发者直接放弃它。在开发者体验的竞争中，AWS 并非强大的领头羊，而是处于劣势的挑战者。

但 Amplify 至少有两个独特的杀手级属性，使其对某些用户极具吸引力，至少值得大多数人考虑：

• 它的扩展性与 AWS 的扩展性相同。Amplify 的所有功能都构建于现有的 AWS 服务之上，例如 S3、DynamoDB 和 Cognito。如果您想切换到底层服务，完全可以。第三方云发行版则不然（Begin是一个值得注意的例外）。这也意味着您只需支付理论上的最低成本，因为第三方云发行版要么必须向用户收取成本加成费用，要么必须依靠风险投资来补贴（这在长期来看是不可持续的）。AWS 的扩展性不仅仅意味着强大的吞吐量处理能力，还意味着边缘案例、安全性、合规性、监控和高级功能都经过了前人的充分实战检验。
• 它拥有一支由 AWS 内部精英组成的团队。我对他们还不甚了解，但显而易见，在 AWS 内部开发云发行版比在外部开发具有巨大的优势。（当然，它也存在大型公司相对于初创公司敏捷性的常见劣势。）如果你要创办一家公司并需要组建一个平台团队，你可能负担不起这样的团队。但如果你符合 Amplify 的目标客户群体，你就可以免费获得这个团队。

简化需要一定的理念，而 Amplify 的最大优势就在于此——精心挑选并整合其他 AWS 服务的“最佳”功能。您无需使用繁杂的方法来设置 AWS Lambda 和配置 API Gateway，只需输入命令amplify add api，相应的 GraphQL 或 REST 资源就会自动设置好，您的基础设施也会以代码的形式完整呈现。存储？amplify add storage身份验证？amplify add auth还有六七个我还没提到。所有这些专用服务的整合意味着您无需管理服务器即可完成应用程序所需的一切。

Amplify助力实现“全栈无服务器”的未来。AWS目前主要依靠提供虚拟服务器盈利，但无论从内部还是外部指标来看，无服务器模式才是未来的发展方向。投资Amplify就是投资AWS的未来。

注意：传统的 VPS 甚至本地数据中心永远都会有一席之地——无服务器化趋势是锦上添花，而不是破坏性的。

Amplify 是一家以团队各自独立运作而闻名的公司，但它的做法却截然相反。它将各个组成部分的工作流程整合到一个统一的工具链中，涵盖了从托管的Amplify 控制台、本地命令行界面 ( CLI)到用户设备上运行的库/SDK 的所有环节。无论您开发的是 iOS、Android、React Native 还是 JS（React、Vue、Svelte 等）Web 应用，其运作方式都完全相同。

最后，显而易见，Amplify 代表了一种与我们以往熟悉的 AWS 服务截然不同的模式。与大多数 AWS 产品不同，Amplify 完全开源。他们为所有流行的 JS 框架（React、React Native、Angular、Ionic 和 Vue）以及 iOS 的 Swift 和 Android 的 Java/Kotlin 编写了集成。他们在GitHub上提供支持，并在Discord上进行交流。他们甚至在我们常听的播客节目中投放广告，例如ShopTalk Show和Ladybug。简而言之，他们真正做到了贴近用户需求。

据我所知，这在 AWS 对待应用开发者的方式上是前所未有的。我认为这种做法正在取得成效。据我观察，Amplify 的增长速度是AWS 其他业务的三倍。

注：如果您想了解更多关于 Amplify 的信息，欢迎参加6 月 10 日至 11 日举行的免费虚拟 Amplify Days 活动，聆听已将 Amplify 各个功能投入生产使用的客户案例分享。我也会和您一起参与，认真聆听！

个人笔记

今天我正式加入AWS Mobile，担任高级开发者布道师。AWS Mobile 旗下拥有 Amplify、Amplify 控制台（一站式 CI/CD + CDN + DNS 服务）、AWS Device Farm（可在真机上运行测试）和AppSync（GraphQL 网关和实时/离线同步功能），并与API Gateway（公共 API 端点）和Amazon Pinpoint（分析与互动）紧密集成。值得一提的是 AppSync，正是它让我萌生了加入 AWS 的想法。

一年前，我写了一篇关于使用无服务器函数和 GraphQL 的乐观型、离线优先应用程序的文章，概述了一系列集成技术。这些技术最终会使应用程序感觉更快、更可靠（因为它们是乐观型和离线优先的），同时使开发这种基本体验变得更加容易（因为 GraphQL schema 允许我们建立最终一致的客户端-服务器契约）。

九个月后，Amplify DataStore 在 Re:Invent 大会上发布（它满足了我大部分的需求）。虽然我的想法并非完全正确，但很明显，我和 AWS 的某位成员（后来证实是Richard Threlkeld，但显然他得到了其他人的支持）的想法不谋而合。AWS 对这个看似异想天开的想法充满信心，并投入了两年时间进行开发。我想我从未在任何一家公司工作过，能做到这样。

我联系了各种规模的公司，探索自己的职业方向，并评估自身的市场价值。（顺便一提：对于开发者布道师来说，在职期间寻找新工作真的非常棘手！）但迄今为止，最顺利、最能与所有人“达成共识”的，是我在AWS面试的那段时间，大概持续了一个月。当时我已经认识我的招聘经理Nader大约两年了，这对我帮助很大，所以我们彼此都非常了解（顺便说一句，这是在公共部门学习的一大优势），他也一样。最后的“超级日”现场面试很有挑战性，我甚至一度担心自己会错过一两轮面试。但令我惊喜的是，我最终获得了全员通过！

Nader是业界的传奇人物，也是我个人的榜样。我在训练营完成第一个独立项目时，用当时我能找到的最好的UI工具包——React Native Elements——做了一个很烂的React Native样板。我当时并不知道那是Nader做的。当我第一次申请会议演讲时，Nader帮我审阅了投稿。当我决定提升CSS水平时，Nader鼓励我，还转发了我的推文。他一直都在帮助开发者，从分享如何成为一名成功的咨询顾问的宝贵建议，到在疫情期间帮助开发者找到工作，再到利用他的平台帮助其他人开启职业生涯。他不仅提携他人，还亲力亲为地承担了所有繁重的工作！我很兴奋他现在领导团队，但同时也有些忐忑，不知道他成为我的经理后，我们的友谊会发生怎样的变化。

通过这次跳槽，我仅仅用了三年时间，就从2017年编程训练营毕业生转型成为一家大型企业L6级别的高管。朋友们都说我不需要这种认可，但说实话，这种感觉确实很棒。

新冠疫情爆发后，我几乎立刻就离开了Netlify，这导致我的签证问题变得复杂（我不是美国公民）。我原本应该在四月份以美国远程员工的身份入职，但现在却要从新加坡开始上班了。这给我造成了不小的经济损失——我估计这次疫情导致的延误和工作变动，让我损失了大约7万美元的收入。更让我难受的是，我现在是家里的主要经济支柱，我们一家四口。为了弥补一些损失，我一直在写书；但总的来说，我很高兴现在还能找到一份稳定的工作。

我从不认为自己是那种“大公司”员工。我重视自主性和灵活性，更看重做正确的事而不是墨守成规。但AWS并非典型的“大公司”——它以“两张披萨团队”而闻名（当然这并非字面意思——Amplify团队的规模更像是20张披萨——但即便如此，也算不上庞大）。从我第二次参加线下聚会演讲开始，我就一直在引用贝佐斯的话，并且一直以来都非常欣赏AWS的实践，从六页纸的简报到史蒂夫·耶格在《平台咆哮》中讲述的轶事，都令我印象深刻。现在是时候从内部了解这家现代巨头了。

AWS 14 年来一直致力于提高开发人员的生产力。对于 AWS 的每一个人，包括我自己，今天都是第一天。