现在我们的工业终于从大众的错觉（微服务将是未来）中恢复过来了，又掉入了一个更大的错觉：无服务器Serverless将提供万能的拯救。
试图从无服务器的基础上制作整个应用程序，例如Basecamp或Shopify或GitHub或几乎任何东西，无服务器沿着微服务所有坏主意继续挖坑，并说“但是如果我们要更多的话”，这是严重误导。
众说纷纭：
我正处在无服务器漩涡的中间，我听不到有人说“通用”。在某些工作负载中，它会赢得更大的收益，而在其他工作负载中，它却无关紧要。
从来没有意识到人们是如此反微服务。。
显而易见的答案是纳米服务：每个容器一个功能
架构是有成本的。单体monolith搞混了成本，无服务器/微服务使之很清楚。作为一家企业，我对某物的成本了解得越多，我就可以做出更好的决定。有单体地方，确实能提供敏捷性，但不扩展。
“您永远不会成为Netflix”并不是某些技术兄弟想要听到的东西。
我正在阅读“构建演化架构”。详细介绍各种架构，向上/向下的方面，可演化性，……该章的重要提示：“确保您的架构与业务问题域相匹配。不要试图强行安装不合适的体系结构。”
没有什么真正的“万能拯救”，但是正确完成无服务器将带来很多好处。例如：monorepo可以在云功能之间共享逻辑，就像在整体中的模块一样。
Nocode的无服务器显然是未来！
为了不编写不需要的代码。而且包括您不需要的库。就像开发一个简单待办事项应用程序却需要加载不必要的ORM一样。
无服务器/ PaaS非常适合于早期实验，MVP，概念验证，在这种情况下，人们无法花太多时间对devops机械进行微调。从规模上讲，无服务器停止具有成本效益。此时，最好将其扩展到K8之类的东西。
无服务器不是万能的救赎，但对于某些已定义的用例来说，它当然是救赎。
我认为，微服务和无服务器等技术普遍存在的问题是人们全力以赴。他们认为最好在微服务中或无服务器的情况下进行所有操作。任何有经验的人都知道，或者应该知道，这不是一个好方法。
最后，我们回到了Rails，这是我们不应该离开的地方。
无服务器是实现细节。您可以具有无服务器和非无服务器微服务，也可以具单体无服务器后端。微服务模式已被广泛采用，因为边界决策很困难，并且在某些规模上是一个很大的默认值。
无服务器无须表示“较小的服务”，它主要是关于使用不同的平台（FaaS），而更多地依赖于更高的抽象服务。如果您确实愿意，可以使用Serverless构建单体。
无服务器不像微服务。微服务是一个完整的隔离片，并且未与事件分发绑定。无服务器使用其他服务，并且本质上是事件驱动的。
我认为微服务和无服务器是正交的和互补的。MSA微服务是一种人员组织技术。无服务器是一种实现技术。我可以使用100％无服务器技术或0％或混合使用来实现服务。服务可以是事件驱动的，也可以不是事件驱动的，或者是混合的。
我将serverless的当前状态与Rails之前的Web开发进行了比较。在那个时候，通常使用诸如Struts或J2EE之类的东西。这太疯狂了，太复杂了，Rails向我们展示了更好的方法。现在最终有人会提出“无服务器的实现路径”。
追逐趋势总是被误导。无服务器擅长的一件事是在云环境中进行事件驱动的小规模工作。但这对于健壮的应用程序可能不是一个好方法。
就像微服务一样，无服务器正在成为一种新的信仰。
是微银弹吗？
如果您能以几分之一的成本获得微服务结构和DDD模式，该怎么办？如果使用模型驱动架构+ DSL和DDD富域抽象了复杂性，并且架构正在建模，该怎么办？工具，例如https://intentarchitect.com
我认为它们（本质上）是不同的野兽：微服务试图解决开发人员的技术复杂性（并以忘记交互复杂性的方式），而“无服务器”则是关于运行时的组件化。像cloud / k8s一样是基础架构/配置的组件化。
我希望这是未来，但是在微服务上的投资是如此巨大，以至于除非进行大规模的工业大修，否则我们会坚持使用它们。同样，经理人喜欢它们，因为它使他们在项目中产生虚假的速度感.
如果您无法正确设计和分解单体，微服务将造成更大的危害，而无服务器将杀死您。
对于整个应用程序而言，无服务器就是对Actor模型（Erlang等）的错误、昂贵且明显笨拙的重新实现。
一个开发人员可以完成多少工作是有限制的。Serverless可以使他做更多的事情，还可以使用其他服务，而这些服务对于他来说太复杂了。我相信，未来将是无服务器的，时间将证明这一点。
除了名称不佳之外，“无服务器”在.net世界中也非常有用。我现在避免了需要远程桌面/更新许多服务器的需求。
banq注：
Serverless = DDD + EventSourcing!
Microservices = DDD + RPC