以下內容轉載自亞馬遜AWS官方博客
前言：
在開發應用程序並將其部署在服務器上的時候，無論是選擇公有云還是私有的數據中心，都需要提前瞭解究竟需要多少臺服務器、多大容量的存儲和數據庫的功能等。並需要部署運行應用程序和依賴的軟件到基礎設施之上。假設我們不想在這些細節上花費精力，是否有一種簡單的架構模型能夠滿足我們這種想法？
這個答案已經存在，這就是今天軟件架構世界中新鮮但是很熱門的一個話題——Serverless（無服務器）架構。
什麼是Serverless
如同許多新的概念一樣，Serverless目前還沒有一個普遍公認的權威的定義。
最新的一個定義是這樣描述的：“無服務器架構是基於互聯網的系統，其中應用開發不使用常規的服務進程。相反，它們僅依賴於第三方服務（例如AWS Lambda服務），客戶端邏輯和服務託管遠程過程調用的組合。”
最開始，“無服務器”架構試圖幫助開發者擺脫運行後端應用程序所需的服務器設備的設置和管理工作。
這項技術的目標並不是爲了實現真正意義上的“無服務器”，而是指由第三方雲計算供應商負責後端基礎結構的維護，以服務的方式爲開發者提供所需功能，例如數據庫、消息，以及身份驗證等。
簡單地說，這個架構的就是要讓開發人員關注代碼的運行而不需要管理任何的基礎設施。程序代碼被部署在諸如AWS Lambda這樣的平臺之上，通過事件驅動的方法去觸發對函數的調用。
很明顯，這是一種完全針對程序員的架構技術。其技術特點包括了事件驅動的調用方式，以及有一定限制的程序運行方式，例如AWS Lambda的函數的運行時間默認爲3秒到5分鐘。
從這種架構技術出現的兩年多時間來看，這個技術已經有了非常廣泛的應用，例如移動應用的後端和物聯網應用等。
簡而言之，無服務器架構的出現不是爲了取代傳統的應用。然而，從具有高度靈活性的使用模式及事件驅動的特點出發，開發人員／架構師應該重視這個新的計算範例，它可以幫助我們達到減少部署、提高擴展性並減少代碼後面的基礎設施的維護負擔。
Serverless的歷史
Serverless這個概念並不容易理解。乍見之下，很容易讓人混淆硬件服務器及軟件上的服務與其所謂的“服務器”差別。在這裏強調的所謂“無服務器”指的是我們的代碼不會明確地部署在某些特定的軟件或者硬件的服務器上。運行代碼託管的環境是由例如AWS這樣的雲計算廠商所提供的。
Serverless這個詞第一次被使用大約是2012年由Ken Form所寫的一篇名爲《Why The Future of Software and Apps is Serverless》的文章。這篇文章談到的內容是關於持續集成及源代碼控制等內容，並不是我們今天所特指的這一種架構模式。但Amazon在2014年發佈的AWS Lambda讓“Serverless”這一範式提高到一個全新的層面，爲雲中運行的應用程序提供了一種
全新的系統體系結構。至此再也不需要在服務器上持續運行進程以等待HTTP請求或API調用，而是可以通過某種事件機制觸發代碼的執行，通常這只需要在AWS的某臺服務器上配置一個簡單的功能。
此後Ant Stanley 在2015年7月的名爲《Server are Dead…》的文章中更是圍繞着AWS Lambda及剛剛發佈的AWS API Gateway這兩個服務解釋了他心目中的Serverless，“Server are dead…they just don’t know it yet”。到了2015年10月份，在那一年的AWS re:Invent大會上，Serverless的這個概念更是反覆出現在了很多場合。印象中就包括了“（ARC308）The Serverless Company Using AWS Lambda”及“（DVO209）JAWS: The Monstrously Scalable Serverless Framework”這些演講當中。隨着這個概念的進一步發酵，2016年10月在倫敦舉辦了第一屆的Serverlessvconf。在兩天時間裏面，來自全世界40多位演講嘉賓爲開發者分享了關於這個領域進展。
在Serverless的世界裏面，AWS扮演了一個非常重要的角色。但是AWS並不是唯一的Serverless架構服務的供應商。其他廠商，例如Google Cloud Functions、Microsoft Azure Functions、IBM OpenWhisk、Iron.io和Webtask等各種開源平臺都提供了類似的服務。
Serverless與FaaS
微服務（MicroService）是軟件架構領域業另一個熱門的話題。如果說微服務是以專注於單一責任與功能的小型功能塊爲基礎，利用模組化的方式組合出複雜的大型應用程序，那麼我們還可以進一步認爲Serverless架構可以提供一種更加“代碼碎片化”的軟件架構範式，我們稱之爲Function as a Services（FaaS）。而所謂的“函數”（Function）提供的是相比微服務更加細小的程序單元。例如，可以通過微服務代表爲某個客戶執行所有CRUD操作所需的代碼，而FaaS中的“函數”可以代表客戶所要執行的每個操作：創建、讀取、更新，以及刪除。當觸發“創建賬戶”事件後，將通過AWS Lambda函數的方式執行相應的“函數”。從這一層意思來說，我們可以簡單地將Serverless架構與FaaS概念等同起來。
FaaS與PaaS的比較
乍看起來，FaaS與PaaS的概念在某些方面有許多相似的地方。人們甚至認爲FaaS就是另一種形式的PaaS。但是Intent Media的工程副總裁Mike Roberts有自己的不同看法：“大部分PaaS應用無法針對每個請求啓動和停止整個應用程序，而FaaS平臺生來就是爲了實現這樣的目的。”
FaaS和PaaS在運維方面最大的差異在於縮放能力。對於大部分PaaS平臺，用戶依然需要考慮縮放。但是對於FaaS應用，這種問題完全是透明的。就算將PaaS應用設置爲自動縮放，依然無法在具體請求的層面上進行縮放，而FaaS應用在成本方面效益就高多了。AWS雲架構戰略副總裁Adrian Cockcroft曾經針對兩者的界定給出了一個簡單的方法：“如果你的PaaS能夠有效地在20毫秒內啓動實例並運行半秒,那麼就可以稱之爲Serverless”。
Serverless架構的優點
降低運營成本：
Serverless是非常簡單的外包解決方案。它可以讓您委託服務提供商管理服務器、數據庫和應用程序甚至邏輯，否則您就不得不自己來維護。由於這個服務使用者的數量會非常龐大，於是就會產生規模經濟效應。在降低成本上包含了兩個方面，即基礎設施的成本和人員（運營/開發）的成本。
降低開發成本：
IaaS和PaaS存在的前提是，服務器和操作系統管理可以商品化。Serverless作爲另一種服務的結果是整個應用程序組件被商品化。
擴展能力：
Serverless架構一個顯而易見的優點即“橫向擴展是完全自動的、有彈性的、且由服務提供者所管理”。從基本的基礎設施方面受益最大的好處是，您只需支付您所需要的計算能力。
更簡單的管理：
Serverless架構明顯比其他架構更簡單。更少的組件，就意味着您的管理開銷會更少。
“綠色”的計算：
按照《福布斯》雜誌的統計，在商業和企業數據中心的典型服務器僅提供5%～15%的平均最大處理能力的輸出。這無疑是一種資源的巨大浪費。隨着Serverless架構的出現，讓服務提供商提供我們的計算能力最大限度滿足實時需求。這將使我們更有效地利用計算資源。
Serverless的架構範式
移動應用後臺Serverless參考架構
實時文件處理Serverless參考架構
Web應用Serverless參考架構
物聯網應用後臺參考架構
實時流處理Serverless參考架構
美麗新世界
技術上不可能有應用程序可以不依賴於服務器，必須要有某種硬件來支持應用程序。但是以AWS Lambda爲代表的Serverless架構可以使得開發人員專注於程序功能本身，而讓AWS處理與服務器部署、存儲和數據庫相關的所有複雜性工作。這聽起來很簡單，但是實現起來卻並不簡單。這種新的架構打破了人們的習慣思維，它讓服務器不可見，並提供了一個極具成本效益的服務。Serverless架構僅有兩年的歷史，仍處於起步階段。未來，這個領域還會有更大的進步，這將是非常有趣的。它給所有開發人員帶來的是軟件架構和應用程序部署的美麗新世界。