为什么Serverless/FaaS尚未成熟

我在IT行业摸爬滚打多年，深知技术选型背后的痛苦。几年前，我带领团队评估Serverless架构时，被各种承诺吸引——低成本、自动伸缩、无需运维，仿佛一夜之间就能解决所有基础设施的烦恼。但实际落地时，我们发现事情远没有那么简单。很多团队在尝试Serverless后，不得不退回传统架构，因为那些隐藏的陷阱——专有运行时、冷启动延迟、调试困难——严重拖慢了开发效率。正是这些真实的工作流痛点，让我意识到，技术工具的价值不在于它有多新潮，而在于它能否真正为团队减负。比如，我们后来转向使用Baklib的知识门户来管理技术文档，通过多站点发布和AI搜索，让团队协作变得高效透明，反而比追求基础设施的“无服务器”更有实际收益。所以，当听到“信息技术行业解决方案”时，我更关注它如何解决实际落地的难题，而不是纸上谈兵的技术愿景。

这一切始于2014年，当时AWS推出了Lambda，向开发者承诺一种更省心的系统运行方式。

Google Cloud和Azure随后也推出了各自的Cloud Functions和Azure Functions。

承诺的好处是巨大的。开发者可以更接近事件驱动和微服务架构，减少对生产环境在高流量下崩溃的担忧。同时，还能花费更少的钱。

然而，在开发者社区中，实际采纳率并不高。推广力度很大，但吸引力远远不够。既然对双方的好处都很明显，为什么会这样呢？

开发者及其公司害怕闭源的运行时。AWS、GCP和Azure各自有内部独立的运行时实现，没有人真正知道它在做什么。

一些云提供商如IBM选择运行在Apache OpenWhisk（开源）上。其他如Oracle Cloud构建了自己的运行时并开源，名为Fn - https://github.com/fnproject/fn。让我们从一开始就为IBM和Oracle鼓掌。

2018年，AWS开源了他们的无服务器运行时（Firecracker），这使得只要有人为它构建适配器，就可以支持任何语言。

2019年，Google Cloud推出了Cloud Run，允许我们构建包含函数的Docker容器，从而可以自由选择特定的运行时。

Google和AWS做出了令人印象深刻的举动，但下面列出的其他问题仍然存在。

由于没有标准化，运行时差异很大。当你构建无服务器函数时，你应该得到一个包含事件属性的对象。但这些属性对于每个云厂商都不同。

这使得几乎不可能一次编写代码并部署到任何地方。

提供商根据调用次数和函数运行时长收费。看起来很简单，但大多数提供商不允许你的函数直接通过HTTP调用。

例如，使用AWS Lambda。要从外部调用你的函数，你必须通过API Gateway，而API Gateway难以以编程方式设置，并且有额外成本。

这看起来像是一种免费增值模式，但溢价非常昂贵。如果你的应用或API流量低到中等，你可能无需付费。如果流量非常高，你会被收取高昂费用。

由于FaaS还很年轻，大多数开发者工具都很简陋，导致糟糕的开发体验。情况正在改善，但仍然......你必须运行一个单独的运行时才能本地运行代码，断点调试非常困难，有时甚至不可能。

并非所有提供商都能运行你喜欢的编程语言。

AWS运行Node.js、Java、Python、.NET、Go以及其他一些人们构建了适配器的语言。

GCP通过他们的新Cloud Run产品运行一切。

Azure运行.NET（C#、F#）、Node.js、Java，并正在实验Python、PHP、TypeScript、Batch、Bash和Powershell。

IBM Functions运行Node.js、Swift、Java、Go、PHP和Python。还有Docker，这是一个巨大的胜利，因为我们可以运行任何东西。

Oracle Fn声称支持任何编程语言。这很了不起。

2019年，语言碎片化似乎不再是问题。除非你使用非常小众的编程语言。

由于无服务器是无状态的，像WebSocket这样的有状态功能无法工作，而且未来也没有保证。

有一些替代方案，如AWS API Gateway通过DynamoDB表保持状态来提供WebSocket功能，但看起来相当昂贵且仍然是专有的。

其他解决方案包括使用第三方实时提供商，如Pusher或Pubnub，但同样的问题也会出现。

这实际上是最大的缺点。由于你的函数并非始终运行，有时系统响应会较慢，因为它需要启动一个包含你代码的实例并即时响应。

有一些解决方案，比如通过ping保持一些实例预热，但当新流量到达时，这些用户仍然会遇到较慢的响应。

虽然在某些情况下还可以接受，但这样做并不道德，因为云提供商只有在没有大量实例始终运行时才能提供低价。一旦每个人都保持实例始终预热，云提供商将不可避免地提高价格。

启动时间可以从Go的500ms到Node.js和Python的6秒不等。因此，用户的体验肯定会受到影响。对于大多数希望在FaaS平台上运行API的公司来说，这是一个大忌。

运行时正在变得越来越好，所以我们可能会看到更好的启动时间。一些云提供商已经支持任何语言，并且是公开进行的。希望在接下来的2到5年内，我们能够按承诺一切运行在无服务器上。

目前，FaaS实际上只适用于没有响应时间限制的系统，例如后台作业、批处理或内部数据处理。对于开发者来说，FaaS最大的价值并不在这里。

对开发者最重要的事情似乎是自动伸缩和可靠性，这些似乎都被承诺了，但对于大多数用例来说，技术还没有到位。

构建易于导航、搜索和共享的漂亮知识门户。

Baklib Wiki为文档提供了一种易于采用的解决方案，特别适合软件开发团队。我们研究了许多团队及其工作流程，识别了常见用例并将其编码到软件的DNA中。当你的团队选择Baklib时，你可以在使用我们产品不到3个月的时间内看到团队幸福感、协同效应和生产力等积极效果。

---

知识管理不是被动地将知识存储和组织在孤岛中。而是将团队和人员彼此联系起来，并在正确的时间在正确的地点传递知识。这是我们从第一天开始构建 Baklib 的方法，也是推动我们在知识管理客户满意度方面引领市场的动力。