現在我們的工業終於從大眾的錯覺（微服務將是未來）中恢復過來了，又掉入了一個更大的錯覺：無伺服器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