☁️ 继续像往常一样使用 AWS

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

嗨 👋！

好了，今天是星期天，老兄，我通常会避开争论和负面情绪。但今天，我在dev.to上闲逛时，偶然发现了一篇标题大胆的文章：“停止使用 AWS”。

这并非我第一次看到有人呼吁放弃亚马逊云服务（AWS），转而选择“更简单”的方案，但这次的呼吁却触动了我的神经，并非因为它具有煽动性，而是因为它曲解了AWS存在的意义及其解决的问题。因此，我决定冷静下来，好好解释一下为什么你绝对应该继续使用AWS，尤其如果你对软件、可扩展性和可持续性有很高的要求的话。

🛑 停止使用 AWS

文章开头讲了一个经典的轶事：一位开发者构建了一个MVP（最小可行产品），它包含了AWS的所有高级功能，例如Lambda、API Gateway、Cognito、S3和DynamoDB，结果却无人问津。结论是什么？AWS功能过剩。

但说实话，把产品失败归咎于 AWS，就像你的想法没能实现就怪罪工具一样。AWS并没有扼杀你的创业公司。缺乏验证、糟糕的用户体验或零营销才是罪魁祸首。使用久经考验的基础设施并不能保证成功，但避开它肯定会让你在未来遭受痛苦。

AWS关注的不是当下的规模，而是未来的韧性。您可以从一个 Lambda 函数开始，扩展到数百万次的调用，而无需再次修改基础设施。支持早期原型的同一服务可以发展成为您的生产骨干。这并非过度设计，而是巧妙的工程设计。

🚂 抄袭 Netflix 的架构很愚蠢

这篇文章的一个关键论点是，照搬像 Netflix 这样的巨头公司的架构是荒谬的。但事实是：借鉴已被验证有效的解决方案正是工程工作的运作方式。

桥梁并非每次跨越都需要全新设计，飞机也并非每年都重新设计机翼。工程师们会借鉴行之有效的设计，因为经过实战检验的结构能够降低风险，提高可靠性。

Netflix 的架构看似复杂，但其许多核心原则，例如持续集成/持续交付 (CI/CD)、无服务器扩展、无状态计算以及基于身份和访问管理 (IAM) 的安全机制，在 AWS 中都是很好的默认设置。这些模式的存在并非因为它们很酷炫，而是因为它们在压力下反复验证有效。

重复利用成功经验不是缺点，而是战略加速。

🚀 大多数项目失败的原因是缺乏用户，而不是过度设计

文章指出，大多数早期项目失败的原因是用户不足，而非基础设施薄弱。但这并非总是如此。

事实上，大多数有前途的项目最终都会因为缺乏市场推广和资金支持而夭折。作为一名目前正在开发开源项目的独立创始人，我可以负责任地告诉你：这个项目之所以还能存活至今，完全是因为社区的支持，而不是因为我的基础设施。但如果明天它在 Hacker News 上爆红，我知道 AWS 能够确保它正常运行，无需迁移，无需恐慌，也无需系统管理员承担任何责任。

说实话，糟糕的基础设施不会让你获得用户，反而会迅速流失用户。宕机、加载缓慢、身份验证失效、API 不安全，这些问题会在你下次提交代码之前就摧毁用户信任。AWS 让你即使零人员、零预算也能自信地发布产品。

🔧 只需使用 VPS + Docker Compose

啊，没错，5美元VPS的梦想。经典的黑客宣言。虽然这想法很浪漫，但在现实世界的压力下很快就会破灭。

• 谁负责你们服务器的补丁？

• 重启后由谁来恢复？

• 谁负责DDoS攻击防护？

• 谁负责备份你们的数据库？

• 谁负责监控 CPU/内存峰值？

• 谁能给你提供滚动部署？

• 谁会给你提供审计日志？

• 谁来帮你保守秘密？

• 停电期间谁来帮忙？

当你通过 SSH 部署时docker compose up，你就得自己当 SRE。这对于业余项目来说没问题。但如果你要构建任何真正意义上的应用，任何你想盈利、保护或扩展的应用，你需要的就不仅仅是业余代码开发环境了。

AWS 帮你解决这些难题。备份、可观测性、IAM、自动扩展和全球分布式部署等功能开箱即用，无需额外操作，也无需熬夜值班。

🧠 AWS 太复杂了

没错，AWS 的确会让人觉得复杂。它有超过 200 项服务，几十种部署方式，确实会让人感到不知所措。但 Linux 内核也很复杂，Kubernetes 也很复杂，说实话，React 也很复杂。

复杂性本身不是缺陷，缺乏渐进式学习才是。

AWS 的设计初衷就是为了实现渐进式发现：

• 先试试Amplify或Lightsail。

• 迁移到CDK或SAM。

• 随时添加服务。

最棒的是什么？发展过程中你无需丢弃任何东西。这与过度设计截然相反。这是平台本身就具备的技术成熟度。

你可以保持精简的生活方式，并且在未来几年内仍然拥有多种选择。

✅ 何时选择 AWS：始终

这篇文章认为AWS只在少数特定场景下才有意义：求职、合规、全球规模化。这种观点过于狭隘。

以下情况才是 AWS 真正发挥作用的时候：

• 从一开始，你们就非常重视安全和合规性。

• 你想要一条无需重写的升级路径。

• 你讨厌运维，想要的是托管服务。

• 你重视可观测性和结构化日志。

• 你希望全局延迟低于100毫秒。

• 您需要精细化的访问控制。

• 你需要基础设施即代码和回滚功能。

• 你希望你的基础设施能够正常运行。

AWS 并不适合所有人。但如果您真心想要构建一个具有弹性、灵活性和持久性的系统，那么它是您可以使用的最明智的工具之一。

🦀 为什么你应该在所有地方、所有事情上、始终使用 Rust

技术栈中还有一个我们还没讨论过的组成部分：编程语言。

如果你仍然默认选择 Node.js、Python、Ruby 或 Go，那么是时候停下来认真考虑一下Rust 了，它不仅是一个选项，而且是你所有技术栈的主要工具。

Rust 不是一种潮流，而是一场软件正确性、安全性和性能的革命。以下列举了一些原因，说明为什么在整个技术栈（包括 CLI 工具、Web 后端、基础设施工具和 WebAssembly 前端，顺便一提，还有Open SASS ）中使用 Rust是你所能做的最明智的长期投资：

• 无需垃圾回收的内存安全： Rust 在编译时无需垃圾回收即可保证内存安全。您可以编写快速且安全的代码，运行时开销为零。这意味着更少的生产环境崩溃、更少的 bug、更少的压力和更快乐的开发者。

• 极速性能： Rust 在计算密集型任务中始终优于 Python、Ruby 甚至 Go 等语言。它拥有 C 语言级别的速度，同时兼具简洁现代的语法和工具。

• 一流的 WebAssembly 支持：您可以将 Rust 编译成 WebAssembly 并在浏览器中运行，甚至在服务器端运行。这使得一种语言可以同时驱动前端和后端，从而形成完整的全栈闭环。

• 符合人体工学的开发体验：借助诸如cargo、rust-analyzer和强大的编译器消息等工具，Rust 不仅速度快，而且一旦上手，使用起来也十分愉悦。其生态系统成熟且发展迅速。

• 无惧并发： Rust 的所有权模型使并发编程默认更加安全。你无需惧怕多线程，反而会欣然接受它。

• 非常适合云和基础设施：诸如firecrackerAWS Lambda 微型虚拟机等主要工具deno都是用 Rust 编写的。它正成为下一代 DevOps、云基础设施和边缘计算vector.dev的事实标准语言。

• 底层强大功能，高级语法：需要编写高性能的网络代码？加密原语？操作系统级实用程序？Rust 都能做到，而且代码可读性强，易于测试。

• 让你的代码库面向未来：选择 Rust，就是选择未来 20 年的稳定性、安全性和速度。它得到了业内巨头的支持，并且已经在关键系统中取代了传统的 C/C++。

想象一下：一种单一的语言，可以驱动你的服务器，构建你的 CLI，编译成你的前端，运行你的 Lambda 函数，编写你的 Terraform 替代方案，并让你将速度极快的二进制文件部署到任何架构。

那不仅仅是一个梦幻般的配置。

那是Rust。

如果您已经在使用 AWS，那么采用 Rust 就更有意义了。您可以构建超高效的 Lambda 函数、优化 EC2 计算、编写速度极快的 CLI 工具，并大幅缩短冷启动时间，同时还能编写更安全的代码。

世界正在缓慢地向 Rust 迁移，一次迁移一个子系统。唯一的问题是：为什么不抢占先机呢？

🔚 结语：你的堆栈不应该只是个玩具

所以，不，你不需要AWS。但把它当作多余之物而忽略，未免目光短浅。初创公司不需要F1赛车，但也不应该用胶带和乐观精神造一辆卡丁车。

如果你的产品成功了，你会后悔当初没有一开始就使用 AWS。如果失败了，那不是因为你用了 AWS，而是因为根本没人想要你开发的产品。不要把你的创意失败归咎于基础设施。

精益建造，智慧建造，但要以向前发展为目标。

AWS不是你的敌人，它是你的降落伞。

我们是 Open SASS，宝贝！

我们正不懈努力，让每个人都能轻松上手 Rust Web 开发。

如果你看到了这里，欢迎加入我们的 Discord 服务器。

下次再见👋！