不管是哪一方，都有一些事项需要留意。对于无服务器的支持者而言：
-
无服务器应用程序的架构并没有更简单；
-
无服务器消除 / 简化了 devops，因此，部署 /devops 更简单了；
-
为了让无服务器产生预期的效果，你必须采用无服务器架构，这与许多公共框架（如 Rails）的最佳实践建议不相符；
-
没有哪个云提供商的最佳实践是真正的最佳实践。他们的兴趣在于把你锁定，因此，他们会尝试将自己融入到你的开发 / 测试工作流，或者在开发中需要云连接；
-
在同一个项目中使用多种语言并不是一项特性。
对于无服务器的反对者来说：
-
几乎可以肯定，遵循云提供商的最佳实践已经让你吃不消了，忽略那些试图锁定你的云提供商，你会过得更好。
-
运行本地版本是有效的无服务器 DX 的必要条件，任何像样的无服务器架构都很容易像 docker 容器一样运行。
-
有一种无服务器架构可以让每个人在大多数情况下都满意。但这通常不明显，因为它处于无状态服务器最佳实践和云提供商最佳实践的交叉点上，但永远不会完全是哪一个。
好了，现在我们已经冷静下来，我们已经认识到，无服务器不是编程和应用程序架构的救世主。现在可以开始构建简单、易于维护、可测试的应用程序了。
下面是无服务器架构必须做到的一些要点：
-
一切都必须能够在本地运行，与传统的有状态服务器一样（你需要能够运行自己的系统）；
-
每个端点都应该有针对本地运行的无服务器实例运行的测试；
-
以一种简单、易于理解的方式处理路由，例如使用文件路径作为端点或一个中心化的 JSON 配置；
-
完全正常。它应该看起来像一个 npm 包、一个 pip 模块等等。没有人需要通过看图表来理解它是如何工作的；
-
每个端点所需的样板文件都尽可能少；
-
整体式的代码组织，每个应用程序一个库，其中包含多个端点。
云提供商应提供以下特性：
-
自动扩展端点；
-
自动部署和版本控制；
-
易于回滚。
我曾见过有人在云提供商的云 IDE 中编写代码，两次测试之间要等 2 分钟。有时，一个端点连接到如此多的云服务，所以真的只能在生产环境中进行测试。有时不是所有端点都在一个库中，而是有很多库，每个库包含不同的系统组件。
开发体验是快速实施的关键，你应该努力保持快速的反馈循环和测试，让你可以快速前进，而不必担心整个系统崩溃。
优质的无服务器提供商每个无服务器提供商都必须经过改造才能成为有效的架构。
每个无服务器提供商都试图让你不可逆转地将它们融入。你不需要把它们融入。遵循最佳实践，除非它违反了“必须在本地运行”的原则，否则你应该没事。
现在，我喜欢以下这两家无服务器提供商：
-
Vercel——基于 AWS Lambda 构建，重视开发体验。优秀的自动部署和版本控制。非常友好的价格。我在把 collegeai.com 重构到 Vercel 之后遭遇了峰值流量，而它在第一天扩展时就没有出现任何严重的问题。你可能需要放弃他们的开发系统（vc dev ），以获得一个有效的容器化 / 本地运行的应用程序，但这并不困难。
-
Cloudflare Workers——Wrangler（worker 的命令行开发工具）意识到本地开发的重要性，而 cloudflare worker 非常便宜。但是，我要提醒的是，它们对 NodeJS 模块的支持不是很好，所以它们还不是一个重要的选项，除非在低成本扩展绝对关键的情况下。
对于下面这两家提供商，我要提醒你注意：
-
AWS Lambda（直接）——对于应用程序开发人员来说，AWS Lambda 太复杂了，我从未见过一个让人感觉正常、易于理解并且使用 Lambda 在本地运行的架构。
-
Fastly——如果需要一个销售电话来开始，那么我可以打赌开发体验将很垃圾。
我还没有足够的经验，听说得也不是很多：
-
Netlify——它似乎有一个正确的方法，但是我不理解他们的专业级无服务器定价，为什么人们通常是从这里开始。
这个领域正在迅速变化，当看到新的竞争者和新的架构时，我会更新这里的内容。
炒作没问题，但要有理由支撑。无服务器使应用程序易于扩展和维护。我在 7 年前编写的无服务器应用程序仍然在运行，几乎不需要维护，也几乎不需要任何成本。我相信，无服务器可以使个人能够维护大型应用程序，否则将需要一个团队和稳定的收入流。