過去幾年我一直在無伺服器社群中試圖弄清楚如何幫助其他人理解“無伺服器”意味著什麼。對於我來說，最近幾個月談論無伺服器一直試圖避免談論技術，並試圖開始討論該方法的商業價值。我甚至寫過關於其中一些內容的部落格：

雲2.0:程式碼不再是王者，無伺服器已經廢除了它

我注意到的一件事是，過去幾年我以各種不同的方式改變了自己的想法。我現在對特定的技術選擇不太感興趣，對組織內部如何實施技術的戰略方法更感興趣，以及組織需要實現的過渡以接受無伺服器的思維模式。

然後昨天我偶然發現了斯沃德利在2016年寫回一篇關於組織的普遍學說的文章。我意識到了......

無伺服器是一種學說

什麼是學說？為了我們的目的，一個學說是你從經驗中學到的一套原則，並編成了一些書面形式，例如一套最佳實踐......就像我的最佳實踐部落格文章......

考慮到“無伺服器作為一種學說”，我認為當有人將任何技術或服務稱為“無伺服器”時，我發現它真的令人沮喪。最常見的例子是當有人說“無伺服器”這個詞的意思是“作為服務的函式”或FaaS時 - 它沒有。FaaS是無伺服器方法的主要支援技術之一，FaaS本身並不是無伺服器的。

讓我再說一遍：

FaaS不是無伺服器的

讓我解釋…

無伺服器特點：

1. 將您的想法從程式碼轉移到配置

無伺服器應用程式不是由程式碼定義，而是由定義資源的配置定義，以及觸發將這些資源粘合在一起的少量程式碼的事件。

程式碼變得更加關注獨特的業務邏輯

配置定義非業務關鍵應用程式。

2. 將您的思維從高量程式碼行轉移到低量程式碼行

今天的程式碼是明天的技術債務

在我的世界中，最好是零程式碼（全部在配置中）

我們越可以轉向配置，我們需要的程式碼行越少

3. 將您的想法從架構服務轉移到消費服務

如果存在可以做我們想要的服務，那麼我們就有理由想要構建該服務。

因此，除非業務至關重要，否則不要構建該服務。

4. 將您的想法從擁有工作量轉移到不再使用工作量

在執行系統時，您應該只關注業務關鍵系統。其他一切都不重要。

沒有例項，伺服器或容器，除非沒有其他方法

如果我不需要，為什麼我要再管理這些了！除非它是關鍵業務，否則這些是技術預算中最大的浪費時間之一！

向上和向下縮放應儘可能由服務處理

向上和向下縮放至關鍵是關鍵。

這包括基本上配置伺服器以在其上執行某些內容的服務。在AWS上執行RDS資料庫之類的東西在這一點上是有問題的，因為您必須配置例項，並且縮放是手動的。這也是為什麼RDBMS通常不合適存在我的無伺服器應用程式檢視中的原因 。

資料層應該是特定於應用程式的 - 沒有“一刀切”的方法

這個對我來說是關鍵的，它只是挑戰“一切都必須是RDBMS”的假設。

有沒有說你不能使用RDBMS，但記得要顧及縮放和管理學說太多。

但是，在過去幾年中我遇到的幾乎所有場景中，應用程式資料層都有比RDBMS更好的解決方案。

沒有有效的業務案例，沒有新的服務或技術

我經常讓開發人員來找我說“我能做到這一點的唯一方法就是使用X服務/技術”。但願這永遠不會成真。

我的回答是將他們送走並要求他們寫一個“業務案例”。在他們編寫了一個業務案例（通常需要幾個，因為他們不知道是什麼）後，我告訴他們離開並確定他們是否可以使用當前的技術堆疊來實現他們所需要的。答案几乎總是肯定的，或者如果不是，它通常是一種完全不同的技術。

例如，我有一個開發人員來問我是否可以使用RedShift，我把他送走了，經過一輪“商業案例”賓果遊戲，他意識到他可以使用雅典娜來實現同樣的目標。它沒有伺服器，符合原則。

開發人員需要了解他們必須證明決策的合理性，當他們意識到他們必須瞭解他們所處的業務時，他們往往會成為更好的開發人員。

企業中的所有技術人員都在那裡提供商業價值

企業中的人的工作不是提供技術，而是提供商業價值。

這應該是顯而易見的，但對大多數開發人員來說並非如此。

現在，對我而言，無伺服器是一種學說