系统与基础设施infoq.com
无服务器架构革命已经停滞
The Serverless Revolution Has Stalled
2020 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
InfoQ 的这篇分析文章回顾了 Serverless（无服务器计算）几年来的发展，认为它虽然曾被寄予厚望、被当作云计算的下一场革命，但实际普及程度远未达到预期。文章从开发体验、厂商锁定、运维复杂度、成本与适用场景等角度，剖析了这场“革命”为何停滞。
为什么经久不衰：它跳出了厂商宣传，提前几年提出了至今仍被反复验证的问题：厂商锁定、调试困难、开发环境糟糕；而评论区两派观点交锋，恰好是这场争论的缩影。
HN 评论精选
质疑 Serverless：调试困难、架构过度复杂、按 import 计费，且技能与代码被厂商锁定。
我不信 Serverless 那套。我去过一个 web 开发大会，结果整场都在炒作 Serverless。台上那些靠推广 Serverless 赚钱的行业专家告诉我，他们没法调试自己的代码，也没法在本机运行。他们展示了极其简单的用例却配上滑稽庞大的系统架构图，然后花一小时讲怎么做“差不多算 ACID”的事务。哦对了，你只能用三五种语言，而且每条 import 语句都对应着具体金额。更重要的是，你练出来的所有技能都绑定在亚马逊或某个巨头身上，你写的代码全凭他们处置，任何问题都得看他们的支持。我该把成百上千个工时押在这上面吗？
nicbou查看英文原文
I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can only use 3-5 languages, and each import statement has a dollar amount tied to it. More importantly, all those skills you develop are tied to Amazon, or some other giant. All the code you write is at their mercy. Any problem you have depends on their support. Am I supposed to bet hundreds or thousands of man hours on that?
AWS SAM 的本地开发与调试体验极差、迭代缓慢，是最被忽视的致命短板。
有点意外文章没提缺乏像样的开发环境。至少在 AWS 上，SAM 的体验大概是我 20 年 web 开发生涯里最糟糕的。迭代速度极慢，到处都要绕过大量复杂的坑；哪怕只是为本地调用和“真实”函数调用加载环境变量，也得费很大劲。补充：我用这套技术不是自愿的，是客户项目需要。我认为他们的 Serverless 用例是合理的，也就是偶尔调用、把几个 AWS 资源粘在一起那种。其他平台的体验会好一些吗？
nickjj查看英文原文
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Note: I'm not working with this tech by choice. It's for a bit of client work. I think their use case for Serverless makes sense (calling something very infrequently that glues together a few AWS resources). Is the experience better on other platforms?
看好派：免运维的诱惑不可抗拒，多数反对意见只是“还不够成熟”，趋势不可逆。
“Serverless 模型不需要用户维护自己的操作系统，甚至不需要构建与特定操作系统兼容的应用；开发者写出通用代码，上传到 Serverless 框架，然后看它跑起来。”这个优势太有说服力了，所以 Serverless 不仅会赢，还会让“租服务器”在 2030 年后变成少数开发者才有过体验的小众市场。自己维护服务器完全是疯了，现在不明显，十年后就明显了，那样极其低效，好比为了让工厂运转就自建发电厂，还得操心安全和日常维护以及服务器周边所有环节。文章里几乎所有反对意见都可以改述为“Serverless 还不够成熟”，这没错；但我怀疑其中也有不愿把控制权交给云厂商的偏见，以及由此产生的想当然。软件开发的未来会由云厂商定义：他们会定义语言生态、应用的标准架构等等。现在只是早期，云还很原始，点点 Azure、GCP 或 AWS 就能看出一切多么零碎。但他们要做的事太多了，光是跟上增长可能就已经够呛。我不确定自己很喜欢这个结局，但我相当确定趋势线就是这样。
randomsearch查看英文原文
This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will have an experience of post 2030. Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Almost all the objections in the article can be rephrased as “serverless is not mature enough yet”, and that’s accurate, but I suspect there’s also a bias against giving up control to the cloud companies, and some wishful thinking as a result. The future of software development is going to be defined by cloud providers. They’re going to define the language ecosystem, the canonical architectures for apps etc... it’s just early days and cloud is really very primitive. Just clicking around Azure or GC or AWS illustrates how piecemeal everything is. But they have a lot to do, and just keeping pace with growth is probably hard enough. I’m not sure I’m super happy with this outcome, but I’m pretty certain the trend line is unmissable.
务实派：Lambda 非常适合小团队的一次性任务、定时任务和粘合服务，但不适合核心生产服务。
作为一个两人小团队的成员，我们用 Serverless Framework 在 AWS Lambda 上跑很多小的“工具型”函数来支撑 DevOps 和构建流程；除了最初的学习曲线，它是我工具箱里最高产的工具之一。它让我能在几小时内搭起一个几乎无需维护的端点，通常用来粘合不同服务：跑个临时 ETL 刷新表或从第三方接口拉数据；给项目经理快速出一个用量报告；构建在 TeamCity 完成后发 Slack 消息让 QA 上手；监控 Crashlytics 日志速率，超过阈值就告警。有大量“一次性”小流程现在能自动运行且无需维护服务器；它们大多功能独立，拆成单独函数很合理；需要协调时我们用 Step Functions。补充：我仍认为它不太适合生产服务，更适合一次性任务和定时任务。
justinram11查看英文原文
As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick ETL process to refresh some tables or pull some data down from a third-party endpoint? * Want to expose a quick usage report for the project manager? * Want to send a slack message when a build finishes from TeamCity so QA can jump on it? * Want to monitor the rate of Crashlytics logs and send a warning to slack if it breeches a threshold? There are tons of "one-off" little processes that now just automatically run and don't require server upkeep. Most of them are functionally independent, so having them as separate functions makes sense (when we do need to coordinate, that's done through Step Functions). Note: I still don't think that they are a great fit for production services (and more fits one-off and cron usage patterns) [1] https://www.serverless.com/
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选