Wisen Tanasa在最近的博文當中提到，在目前關於無服務器架構的文獻當中，有相當一部分由雲服務供應商提供贊助，因此在內容上存在單純強調優勢的傾向。但Tanasa認爲，每當有新的技術出現時，最重要的是全面瞭解其意義，因此我們應該從客觀角度出發探討無服務器架構的特性。
作爲Thoughtworks首席開發者，Tanasa表示他更傾向於使用“特質（trait）”、而非特性，因爲他認爲這些屬於無服務器架構的固有元素，我們無法像處理其它可塑特性那樣做出調整。特質是天然存在的，所以我們必須接受，而非與其針鋒相對。
無服務器架構擁有較低的入門門檻；大家能夠遵循教程輕鬆瞭解如何上手。但Tanasa指出，雖然開發人員面對的初步學習曲線比較平緩，但隨着項目變得更爲複雜，曲線也會迅速呈現出陡峭的態勢。在無服務器的世界中，代碼、日誌記錄以及監控等基礎設施仍然必不可少。此外，他還注意到開發人員在面對無服務器架構時往往有忽略代碼設計的傾向——很多人認爲自己只是在直接使用函數。他強調稱，對於最重要的構建原則，我們在無服務器世界中同樣不應忽視。無論是SOLID這類設計概念，還是持續交付原則，都將在無服務器領域繼續發揮重要作用。
在無服務器的世界裏，不存在主機的概念——我們完全不需要面對任何服務器。由此帶來的一大優勢，在於顯著減少了運營開銷——不需要升級服務器、也不必考慮應用程序所必需的安全補丁。但與此同時，這也意味着我們需要對應用程序中的不同度量標準進行監控，換言之我們必須重新學習如何調整整個架構。Tanasa強調稱，儘管能夠自動添加安全補丁，但應用程序安全實踐在無服務器環境仍然適用。一個典型的例子就是不要在代碼當中存儲密碼，這實際上跟無不無服務器沒有關係。
函數即服務（FaaS）具有臨時性，這意味着無服務器本身是無狀態的。由於狀態不會被存儲在應用程序當中，因此橫向擴展就變得非常簡單——只需要直接啓動更多實例即可。另外，無狀態也意味着發生錯誤的空間大大減少。但是，無狀態也意味着我們無法利用衆多有狀態技術進行應用程序開發；例如，我們將無法使用HTTP會話。
再有，無主機也意味着架構本身具有彈性。換言之，我們不必手動管理資源，資源分配方面的很多原有難題也將隨之消失。一般來講，這還意味着我們只需要爲實際使用的資源付費。但在與遺留系統相集成時，這種彈性也有可能帶來新的挑戰。Tanasa指出，除非傳統系統能夠像無服務器組件那樣輕鬆擴展，否則我們必須限制負載以防止其因過載而發生故障。
在默認情況下，無服務器架構當中包含大量通過網絡進行分佈式集成的組件。持久性由後端即服務（BaaS）負責實現，代碼則以多項函數的形式運行，其它服務用於實現身份驗證與隊列等功能。分佈式特質也爲架構帶來了高可用性。如果當前可用區存在問題，則架構可以使用另一可用區。不過分佈式應用程序在一致性方面需要做出權衡，最典型的兩種選項就是寫入後讀取以及最終一致性；我們在更新以及讀取數據時，必須考慮到這些具體情況。
由於利用BaaS支持事件，因此無服務器架構還具有事件驅動特質。Tanasa指出，這並不是說開發者必須完全接受事件驅動型架構，但事件驅動確實能夠帶來諸多優勢。舉例來說，事件驅動能夠顯著降低各組件之間的耦合水平。但這同時也會帶來無法建立系統整體視圖的風險，並提高排除系統故障的難度。
Tanasa最後指出，無服務器架構帶來了一種有趣的範式轉變。其改進了軟件開發當中的諸多方法，同時也引入了一系列需要由開發人員以及團隊加以適應的全新挑戰。
在另外兩篇博文中，來自Symphonia公司的Mike Roberts描述了他對於無服務器的定義。在他看來，無服務器應用程序是一類利用無服務器服務實現的應用程序，且此類服務必須具有以下五點共通特質：
- 不需要管理服務器主機或者服務器進程。
- 根據負載進行自動規模伸縮與自動配置。
- 根據使用情況決定實際成本。
- 性能容量以不同於主機規模或數量的其它術語進行定義。
- 具備隱含的高可用性。
Jonas Bonér在今年早些時候的一篇博文中也提到，雖然他力挺無服務器這波浪潮，但編程模型不應只關注無狀態函數，因爲這同時也會嚴重限制所能支持的用例類型。
另外，在2017年的一篇博文中，Martin Fowler提到了事件通知的風險，並指出雖然事件通知模式非常實用，但也增加了大規模流量長期處於監控之外的風險。
原文鏈接：
https://www.infoq.com/news/2019/08/traits-serverless-architecture/