嘿👋～
今天是周日，我通常会避开辩论和消极的想法。但今天我在浏览dev.to时，无意间看到了一篇标题很吸引眼球的文章，名为“别再用AWS了。”
这并不是我第一次看到有人呼吁放弃使用亚马逊网络服务（AWS），转而使用一些“更简单”的东西，但这一次触动了我的心，不是因为它具有挑衅性，而是因为它误解了这一点。因此，我就坐下来，放松了一下，解释一下你为什么绝对应该继续使用AWS，尤其是如果你真的关心软件、扩展能力和可持续性。
🛑 别再用 AWS文章开头讲述了一个经典的故事：一位开发者使用了所有 AWS 的服务，包括 Lambda、API Gateway、Cognito、S3 和 DynamoDB，构建了一个 MVP，结果却没有人用。结论是使用这么多 AWS 服务有些过度了。
但让我们坦诚一点：把产品失败归咎于 AWS 就像是在想法不被接受时把责任推到你的工具上一样。AWS 并没有扼杀你的创业公司。缺乏市场验证、糟糕的用户体验(UX) 或零营销可能是原因。使用经过实战考验的基础设施并不能保证你的初创公司成功，但避免使用它肯定会让你在未来感到痛苦。
AWS 今天不在于规模，而在于明天的韧性。你可以从一个 Lambda 函数开始，扩展到数百万次调用而无需再次涉及基础设施。支持你早期原型的同一个服务可以成长为你的生产支柱。这并不是过度设计，而是明智的设计。
🤖 模仿 Netflix 的架构太傻了文章中的一个关键论点是，从像 Netflix 这样的巨头那里复制架构是不切实际的。不过，复制经过验证的解决方案才是正确的工程做法。
桥梁在建造时不会为每个跨越设计新的样式。飞机也不会每年重新设计机翼。工程师们借鉴已验证成功的方案，因为经过实战考验的设计能够减少风险并提高可靠性。
奈飞的架构看起来可能很复杂，但其许多核心原则，如持续集成/持续部署（CI/CD）、无服务器扩展、无状态计算和基于IAM的安全性，其实只是亚马逊云科技中的好的默认设置。这些模式之所以存在，不是因为它们很酷，而是因为它们在压力下仍然有效。
再次利用成功不是缺点之一，它就是策略性加速。
🚀 大多数项目并不是因为过度复杂化而夭折，而是因为缺乏用户。这篇帖子说，大多数早期项目失败是因为没有足够的用户，而不是因为基础设施不好。但这并不总是对的。
实际上，大多数有前途的项目因缺乏营销和财务支持而夭折。作为一名目前正在构建一个有竞争力的开源项目的独立创始人，我可以告诉你：唯一的原因就是它还活着，这并不是因为我搭建的基础设施。但是如果明天它在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 是为逐步探索而设计的。
或
-
切换到 CDK（点击访问：https://aws.amazon.com/cdk/） 或 SAM（点击访问：https://aws.amazon.com/serverless/sam）。
- 按需添加服务。
最好的一点是，在你成长的过程中不需要丢弃任何东西。这与过度工程化恰恰相反。这是平台本身的技术成熟。
你可以保持轻便，多年依然拥有选择自由。
✅ AWS 有其意义时：总是这篇文章认为 AWS 只在几个特定场景中有意义：求职、合规和全球规模，这种观点有点狭窄。
这里AWS真正开始有用：
-
你一开始就关心安全和合规问题。
你想要一条无需重写的升级路径。
你特别讨厌运维，想要使用托管服务。
你在意可观察性指标和结构化日志。
你就想要全球延迟时间保持在100毫秒以下，是吧？
你想要细致的访问权限。
-
你想要IaC和回滚。
- 你希望你的基础设施能够轻松运行。
AWS不一定适合每个人。但如果你认真考虑构建一个持久性、灵活且可靠的系统，它可能是你能用到的最明智的工具之一。
🦀 你应该随时随地使用 Rust 的原因还有一个我们还没提到的部分，那就是编程语言。
如果你还在默认选择 Node.js、Python、Ruby 或 Go 作为首选，是时候认真考虑下 Rust 了，不仅仅把它当作一种选择，而是作为你所有栈的主要武器。
Rust 不是一種趨勢。它是在軟件正確性、安全性和性能方面的革命。順便一提，這是你能做出的最理智的長期選擇：涵蓋了從命令行工具、Web 後端到基礎設施工具，再到 WebAssembly 前端，使用 Rust 跨越你的整個技術堆疊，包括這些方面，這是你可以做出的最理智的長期選擇。
-
不依赖垃圾回收的内存安全: Rust 在编译时保证内存安全，而不需要垃圾回收机制。你可以编写既快又安全的代码，且没有任何运行时开销。这意味着更少的生产崩溃、更少的错误、更少的压力，以及更舒心的开发者。
-
闪电般的性能: Rust 在计算密集的任务中胜过 Python、Ruby 甚至 Go 等语言。它拥有接近 C 语言的速度，并具有合理且现代的语法和工具。这使得 Rust 成为一个理想的高性能编程语言选择。
-
一流的 WebAssembly 支持： 可以将 Rust 编译为 WebAssembly 并运行在浏览器或服务器端，这样就可以用一种语言同时驱动前端和后端，从而闭合全栈闭环。
-
舒适的开发体验: 借助诸如
cargo,rust-analyzer等工具，以及强大的编译器消息，Rust 不仅运行速度快，而且一旦熟悉了，使用起来也非常愉快。生态系统已经相当成熟，并且还在迅速发展。 -
无需惧怕的并发： Rust 的所有权模型让并发编程更安全，无需担心。不再害怕多线程，而是欣然拥抱它。
-
非常适合云和基础架构： 如
firecracker（AWS Lambda微VM）、deno和vector.dev这样的主要工具如，采用 Rust 语言编写。它已经成为下一代的DevOps、云基础设施和边缘计算的事实标准语言。 -
低级性能，高级语法： 需要编写高效的网络代码吗？加密算法？操作系统级别的工具和功能？Rust 都能做到，并且代码易于阅读和测试。
- 让你的代码库具备未来性，确保你的代码不会被淘汰: 今天选择 Rust 就是选择了未来 20 年的稳定、安全和高速。它得到了各大公司的支持，并且已经在关键系统中取代了传统的 C 和 C++。
想象一下这样的场景：一种语言可以运行你的服务器，构建你的命令行界面，编译前端代码，运行你的 Lambda 函数脚本，编写 Terraform 配置，并让你能够快速部署任何架构的二进制文件到目标系统。
那可不仅仅是一堆梦想。
那叫Rust呢。
如果你已经在使用 AWS，使用 Rust 更有道理。你可以构建极高效率的 Lambda 函数，优化 EC2 的计算资源，编写极快速的 CLI 工具，并大幅缩短冷启动时间，同时编写更安全的代码。
世界正在逐步地，一个接一个地迁移到 Rust。唯一的问题是：为什么不早点开始呢？
🔚 最后想说的：你的技术组合不应该仅仅是个玩具所以，你并不 需要 AWS。但认为它过于复杂是目光短浅的。一个初创企业不需要一辆 F1 方程式赛车，也不应该用胶带和乐观的心态拼凑出一辆简易的卡丁车。
如果你的产品成功了，你会希望一开始就用上了 AWS。如果它失败了，这一点是肯定的，不会是因为你使用了 AWS。而是因为大家都不买账你做的东西。不要因为想法失败就怪罪基础设施。
精简。聪明。但要不断前进。
AWS可不是你的敌人，而是你的保护伞。
我们是开放的SASS社区，宝贝！
我们正不遗余力地让每个人都能轻松进行Rust网页开发。
如果你看到这里，加入我们的Discord 加入我们。
下次见！👋
共同學(xué)習(xí)，寫下你的評(píng)論
評(píng)論加載中...
作者其他優(yōu)質(zhì)文章
