幽默:Ruby on Rails建立者DHH質疑無伺服器和微服務

banq發表於2020-02-08

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

 

相關文章