雲端運算這個概念剛問世時，大家對於雲端運算的理解是運算資源將如水電瓦斯一般，只要把電器的插頭接上牆上的插座，任何電器就能開始運作，而且使用者無須理會電力是怎麼提供，當然個人或企業也不必為了用電而要蓋電廠。然而在過去十年，運算資源如水電般便利的願景，遲遲沒有實現。
其實，綜觀近20年IT運算架構演變至雲端的歷程，從虛擬化、雲端運算到軟體容器（Container），可說是一個不折不扣的「去伺服器」革命。這場革命現在更進一步往前推進到無伺服器（Serverless）運算架構，讓我們距離運算資源如水電的願景更近了。
一場20年的去伺服器革命
這場去伺服器的革命濫觴於2001年伺服器虛擬化，在VMware的虛擬化技術問世之後，幫助企業整併了許多x86伺服器，於是資料中心的軟體伺服器──虛擬機器，開始大幅增多，而實體伺服器則逐漸減少。
虛擬化興起的5年後，開始吹起雲端運算的風潮。全球最大的電商Amazon成立雲端服務公司AWS（Amazon Web Services），開始提供IaaS（Infrastructure as a Service）公眾雲端運算服務，從賣書進一步賣運算，讓企業可以在雲端運行虛擬機器。於是企業開始嘗試把虛擬機器搬上雲端，而且有些企業甚至再也不想為實體伺服器花費任何心思，如Dropbox這樣的網路儲存服務公司，在草創期就打著沒有任何一臺硬體伺服器的口號，其IT架構完全藉助AWS的雲端服務。
接著Docker容器（Container）技術於2013年誕生，由於容器技術是作業系統層級的虛擬化技術，每個容器不須附帶作業系統，因此比虛擬機器來得精簡，容器的啟動速度也由虛擬機器的分鐘等級一下子提升至秒級，立刻獲得許多人的青睞。
在容器技術問世後，公眾雲服務廠商也立刻跟進推出容器雲端服務（Container as a Service）。然而不論是虛擬機器或是容器的雲端服務，對使用者而言只是去除了實體伺服器的包袱，事實上還存在著軟體伺服器的部署與維運，使用者仍然必須管理虛擬機器或容器的部署、調度、管理與資安。
對開發者而言，能夠完全不必理會任何伺服器絕對是最完美的。然而，有可能完全不必部署伺服器、不必管理系統、不必在意作業系統版本，甚至不須處理作業系統的更新等資安問題嗎？一個直接稱為無伺服器（Serverless）的運算架構，正在掀起一場新革命。
Serverless新革命
AWS在2014年推出的Lambda無伺服器運算服務，率先吹響無伺服運算革命的號角。這個新型態雲端運算服務訴求使用者不須部署與管理伺服器，只要將程式碼上傳至AWS Lambda服務即可，AWS會馬上調派AWS EC2運算服務，建立Lambda程式的執行環境，程式碼立即可以運作。
AWS Lambda的執行程式稱為Lambda Function（Lambda函數），開發者可以使用Java、Node.JS、Python等程式語言撰寫各種功能的Lambda函數，只是因為AWS Lambda的背後其實是一個微服務（Microservices）架構的運算環境，Lambda執行程式必須是無組態（Stateless）的事件驅動型程式。
當開發者將Lambda函數上傳後，AWS會自動建立執行環境，並負責所有系統維運工作，例如負載平衡、系統備援及高可用性等等，包括在負載量變大時自動擴張系統，負載量減少時縮小系統規模。因此，無伺服器運算架構最大的好處之一，就是開發者可以完全不管系統維運，只要將全部的心力放在撰寫業務邏輯的程式碼。
可口可樂北美集團科技策略總監Michael Connor就曾指出，在傳統的開發模式下，開發團隊真正花在為業務專案寫程式碼的時間只占39％，連5成都不到，其他時間都被突發事件或作業變更等占用了。然而改採用Serverless無伺服器運算服務後，維運工作大幅減少，可用來撰寫程式碼的時間大幅提升為68％。
可口可樂北美集團在開發自動販賣機的行動支付交易時，由EC2架構改為Serverless，對開發團隊的工作重心與總體成本有很大的改變。（圖片來源／Coca Cola North America）
AWS Lambda的另一個好處在於提供事件驅動型服務架構。Lambda函數是基於事件觸發條件而啟動，可由HTTP、API呼叫、AWS或第三方服務來啟動。開發者只要在Lambda函數設定好事件驅動條件、程式執行政策，就能整合串接多種微服務，快速打造一套應用程式。
以現在網站常見的多種圖片尺寸轉檔需求為例，如果網站的圖片檔案已經存放在Amazon S3雲端物件儲存服務，那麼不到一小時就可以開發出來。首先你必須要有轉檔程式，開發者可以直接下載AWS開源的圖片轉檔程式，做為圖片轉檔的Lambda函數，或使用如ImageMagic等開源程式。接著再撰寫程式邏輯的Lambda函數，設定當S3儲存空間有新增的圖片時，即啟動圖片轉檔，完成後再將圖檔回存至S3。把上述這些Lambda函數傳至Lambda之後，圖片轉檔服務就可以開始運作了。
目前AWS旗下的諸多服務皆支援Lambda，如資料儲存服務S3、資料庫服務DynamoDB、資料串流服務Kinesis、身分驗證服務Cognito、電子郵件服務Amazon SES、推送通知服務Amazon SNS、API管理平臺Amazon API Gateway、物聯網平臺AWS IoT、監控服務CloudWatch、日誌服務CloudTrail等等，這些服務皆可透過事件觸發而串接起來。若無現成的服務可用，開發者亦可自己撰寫Lambda函數，與其他微服務整合起來。
由Lambda程式架構可知，無伺服器運算架構適合執行事件驅動型應用，而其微服務架構亦有助於系統彈性擴充。同時，無伺服器並非不需要伺服器，而是從使用者的觀點來看，開發者只要撰寫程式碼即可，無需理會伺服器的部署與維運，可以完全感覺不到伺服器的存在。雲端運算架構發展至此，可說是距離運算資源如水電的願景非常近了。
無伺服器運算服務亦稱為Function as a Service，其架構的特性也帶來全新的計價方式，不論是計價的時間，或是價格的算法，都與一般雲端虛擬機器運算服務的計費截然不同。
無伺服器運算服務的計價方式比起其他任何雲端服務更為精準，其價格是依照程式實際執行的時間來計算，一旦程式啟動就開始計價，程式停止運作則不計價。例如上述的圖片轉檔需求，使用無伺服器運算服務的費用，就依照Lambda函數的運算時間與被請求的次數來計價。當網站的使用者上傳了圖片，S3發現檔案新增事件，則會啟動圖片轉檔函數，也就開始計費，待轉檔完成又停止計價。所以，使用者上傳圖片數量多，就要付出較高的價格，一旦使用量減少，費用也相對降低。相較於一般採用雲端虛擬機器的情況，你必須租用一臺EC2主機，才能執行圖片轉檔程式，而且即使圖片轉檔需求量很低，仍然得支付一臺虛擬機器的租用費。
因為架構上的不同，Lambda服務的產品方案與EC2有很大的差異。EC2虛擬機器的產品方案是依照處理器、記憶體的規格畫分不同等級服務，Lambda則是依照分配給函數的記憶體容量大小來畫分服務等級，從最小的128MB至最大1536MB，記憶體容量大小會決定Lambda函數執行的速度，以及執行完成所需要的時間。
Lambda的價格是以每100毫秒為單位計算，例如128MB等級的定價是每100毫秒收費0.000000208美元，而整體費用則包含每月的總運算量（運算次數乘上執行時間）與請求量（運算次數乘上0.2美元）來計算。若Lambda函數有整合AWS其他服務，其使用量依照該服務的標準計價。
由於Lambda的計費模式是呈指數型，價格非常容易預測。當程式使用量很低的時候，價格相對低廉。然而採用EC2，則有運算量閒置浪費的問題，即便程式使用量很低，仍要支付最低等級服務的費用，相較起來就貴了不少。
以可口可樂北美集團的經驗來看，他們使用6臺EC2 T2.M等級的虛擬機器，一年的總體成本是12,864美元（含作業系統、管理與資安等支出），而同樣的應用服務改用AWS Lambda，在每月3千萬次使用量的情況下，一年成本是4,490美元，足足省了65%。他們預估，直到每個月的使用量達到8千萬次，Lambda方案的價格才會跟EC2一樣。
此外，AWS還提供Lambda免費方案，每個月有1百萬個請求及每月400,000 GB-秒的免費運算時間，再加上無須維運管理、高度彈性與快速部署上線的特色，對開發人員充滿吸引力。
以Serverless開發企業應用
最近一年，開始有些網路公司直接在Lambda環境開發整套應用程式，像是開發電商平臺的Shopify公司，基於自身使用電子郵件行銷的需求大增，想要自行開發郵件行銷服務，最後選擇採用無伺服器運算架構，在Lambda上開發整個後端系統，以超過70個Lambda函數打造出MoonMail電子郵件行銷服務。
有些企業則開始局部嘗試無伺服器運算架構。可口可樂北美集團利用開發飲料自動販賣機的會員忠誠行銷計畫的機會，導入無伺服器運算架構。他們的目標是提供消費者在自動販賣機使用會員卡、信用卡或行動支付購買飲料，並且結合會員活動以促進銷售，在消費者購買後，將消費資訊、會員卡餘額等資訊傳送給消費者。
其應用流程是消費者以會員卡或信用卡購買飲料後，交易資料會從自動販賣機傳到支付閘道，支付閘道接著透過REST API呼叫Amazon API閘道，API閘道接著將訊息傳送到AWS Lambda去執行，處理所有的交易業務邏輯，接著再將消費資訊更新到Apple Pay或是Android Pay，消費者就能獲得購物資訊。整個流程所需要的時間不到1秒鐘，而AWS目前的收費只要千分之一美分，單就一次交易而言非常便宜。
其他如金融業的Capital One公司，以無伺服器架構開發AWS雲端服務使用管理平臺，並且將程式碼開源；而美國百貨公司Nordstrom，則將網路商店的搜尋功能全部以無伺服器運算架構開發。
然而，無伺服器運算架構並非萬能，如前所述，此一運算架構屬於微服務架構的類型，因此應用程式必須符合微服務架構，也就是無組態，才能快速擴張。不過，即便目前仍有這個限制，無伺服器運算架構仍然適合許多類型的應用程式，例如網站、行動App、Chatbot、ETL、資訊處理、基礎架構管理、IT自動化維運等等應用。而關於無組態的限制，亦是目前許多研發人員正在克服的問題。