亞馬遜為什麼要推Serverless Architecture？

01-26

亞馬遜當前的AWS已經一騎絕塵了，而且按照趨勢，和後面幾位的差距會不斷拉大。從大多數用戶角度，考慮數據忠誠性、轉移成本等因素，使用AWS也是目前和未來一段時間最理性的選擇。
而近期亞馬遜推出的Serverless Architecture，從某種方面來講，是在革自己的命，將自己的蛋糕做小。我們可以說亞馬遜是在為未來開路，但是Serverless Architecture完全可以作為技術儲備，沒必要現在就推向市場啊。
我自己能想到的理由：
1、培養未來的用戶和使用習慣，為下一個10年提前圈地。
2、亞馬遜當前的擴展模式，其內部資源使用效率仍然不夠，導致IDC擴展跟不上業務發展。需要從架構上提升效率，為未來更大的業務量轉型，現在花錢，未來省錢。

3、大客戶的架構轉型需要時間，受大客戶的技術需求壓力，必須匹配客戶演進路線。

AWS 在 serverless 架構上布局很久了，廣義上來說，它發布的第一個服務 S3 就是 serverless 的，加上後來出的 Lambda，DynamoDB，Aurora for RDS 等服務，現在已經慢慢地把整個生態系統給搭起來了。Lambda是其中一環，說是最重要的一環也不過分，但 serverless 絕不僅僅是 Lambda 而已。2016 年推出的 SAM (Serverless Application Model) 和 Lambda Step Functions 可以認為是 AWS 已經大致布局完畢，開始合圍了。

為什麼要推 serverless 架構？Serverless Serverless 的本質是把亞馬遜已經經過極度苛刻的生產環境考驗的成熟技術和架構，通過簡單易用的產品形態提供給開發者，使得開發者不需要去考慮下一層的架構就可以擁有高彈性、高可用的服務，可以專註在業務邏輯上面。要說革命的話，就像雲平台上的其他服務一樣，革的是傳統運維的命，只不過這一次革得更加徹底。Serverless 不會革掉 AWS 自己的命，原因有兩個：

Serverless 有特定的應用場景，至少在可預見的將來無法完全替代傳統架構。在這個前提下，少量傳統架構的應用遷移到 Serverless 架構上，看上去好像收入減少了，蛋糕小了，但 Serverless 提供的這些特性可以極大激發開發者的想像力，提高開發效率，最後反而利潤上可能有所提升。
當然就像題主所說，更重要的是圈地，吸引新用戶，留存老用戶，這麼好用的東西放在那裡，對開發者的吸引力是巨大的。只要用戶在，利潤就是有保證的。

至於「IDC 擴展跟不上業務發展」應該不大可能。AWS 上有一類 EC2 實例叫做 Spot Instance，就是把IDC里的空閑資源放出來通過競價的形式賣給用戶，我們的大數據處理系統就常年利用 Reserved Instance + Spot Instance 來省錢。從 2016 re:Invent 看來，AWS 對於數據中心的建設是充滿信心的，「一天新增的伺服器數量可以支撐一個世界500強」不是蓋的。不過 EC2 虛擬機資源使用效率不高也是事實，為了在高流量的情況下有足夠的緩衝供 Auto Scaling Group 增加實例數目，用戶在選擇 EC2 大小的時候通常也是留有餘量的。Serverless 可以把這些餘量都充分利用起來。

說句題外話，我覺得 serverless 還會革掉一部分系統架構師的命。接下來其他雲廠商都會往 serverless 的方向去努力。因此對於傳統意義上的系統架構師和運維工程師來說，需要重新考慮自己在這一波新的浪潮下如何重新自我定位。

按伺服器賣虛擬機是非常浪費的。我手頭的數據是按虛擬機賣的話資源浪費率不低於75%。意思就是說，如果我現在賣給你掙1塊錢的東西如果能提高到100%利用率，我至少能掙4塊錢。所以我需要提高資源利用率。

但如何提高資源利用率呢？

以前的玩法，是PaaS甚至SaaS。我只提供你一個特定功能的環境，這樣我可以更加自由地調整我的資源。因為特定環境總比虛機的外部依賴少，容易配置和移動。

但是這樣依舊有很多浪費，不低於50%，而且對用戶來說其實並不好用，因為特定環境雖然外部依賴少，但裡面跑的東西內部依賴不見得少，導致所有的內部依賴總會需要轉移到外部依賴上，還不如用虛擬機。

很顯然，要進一步提高資源利用率就要尋找一個解耦度更高的框架。

那麼什麼東西解耦度更高呢？

兩個方向，一個是提供一攬子解決方案。比如用戶你要Hadoop做數據分析，那麼我直接提供數據分析服務好了，你啥都不要管，分析框架丟給我，我給你配置，給你出結果。這是一種思路，但它其實適用面很小——現在的互聯網公司大多依賴快速迭代，這樣的服務的重配置前後時間成本很高。

另一個方向，就是Serverless了。如果我給你一攬子方案不行，那麼我也可以走另一個極端——允許你以函數為單位包裝代碼，我來執行。以前這是很難做到的，因為命令式語言的自由度太大，幾乎沒法讓代碼在保證安全和正確的前提下由機器自動拆分成可單獨執行的模塊。Node.js這樣的回調框架的函數式編程（Lambda）允許這樣的代碼生成，也相對容易理解，正好可以實現這樣的運行模式。而且，Serverless這樣的模式是有希望做到資源利用率100%的，可以說比其他目前能看到的方式都要好。

說白了，錢的事。

PaaS比IaaS難換一萬倍。一個大型系統如果用了某家的PaaS，那就基本上就要永遠用下去了

為什麼會覺得是把蛋糕做小呢？

serverless確實很有吸引力，但是用它做複雜業務應用的方法論還需要摸索，早點推出來讓大家一起來尋找適合serverless的設計模式。

等設計模式和配套工具都成熟的差不都的時候，雲端部署的門檻可能比現在又下了一大截了，這樣可以吸引更多的用戶往雲端轉。

而且從我目前實驗的情況看，serverless的函數粒度會變得非常小而且清晰（入參=&>出參），目前看很適合flow based programming，而fbp是很方便可視化的，說不定將來的編程門檻都會下降一大截。到時候可能有想法的創業者自己稍微學一學就能開發個基礎的應用出來了。就差一個程序員了這種事情會變少咯。

Serverless Architecture

現在最火熱的技術話題莫過於Docker和Container，除此之外恐怕是serverless architecture。」serverless architecture「故名思義沒有伺服器。但是這怎麼可能呢？

代碼當然還是運行在伺服器上，只是不需要用戶來管理。

這多少和使用雲存儲有些類似，我們上傳數據到雲端，然後從雲端讀取數據。當然這背後技術並非這麼簡單。serverless也是這樣，而且相當酷。

serverless如何工作？我將以aws lambda為例進行解釋。aws lambda允許用戶專註於業務功能的實現，而無需考慮伺服器的事情。比如你寫一個function（向DynamoDB插入數據），並且配置了合適的許可權（該function可以寫DynamoDB），剩下要做的就是設置function什麼時候執行。function何時才會被運行起來？事件，當事件發生時，會自動觸發function的運行。事件可以是用戶登陸／用戶上傳／更新計數器等。這些事件可以來自於你的應用，比如mobile或者web應用，甚至於aws自己的服務。這些服務包括S3/DynamoDB／kinesis／SNS／SES／cognito／cloudwatch logsevents／cloudformation／scheduled events。只要你配置了lambda和相應的服務，就可以讓他們一起自動工作。這簡直棒極了。

讓我們看個例子：

假設有一個註冊過程，用戶上傳頭像圖片和用戶信息。這裡有幾個事情：把用戶信息存儲在數據中，便於後續查找；創建圖片的縮略圖。原因嘛，現在的手機圖片動輒數MB，以至於太大需要優化。

如何優化呢？當然，可以在本地伺服器上配置，使用腳本進行處理。老實說，這也許會工作的挺好。但是當你有更大的業務流量，這種做法的問題也會凸顯出來；而對低流量的小型網站勉強可以對付。但是，我們想下，我們需要做那些事？安裝配置伺服器，部署腳本，安裝正確的包（圖片處理庫），存儲多個不同版本的縮略圖，在資料庫中存儲縮略圖的關聯信息，最後你需要讓上傳圖片的事件觸發你的function。還有，對圖片的操作需要是非同步的，除非你想讓用戶等很久。

如果我告訴你，你只需要花幾分鐘使用AWS lambda寫兩個函數並進行配置就可以搞定上邊的這個事情你會怎麼想？這當然是可能的，你可以有一個function縮放圖片，另一個function存儲用戶信息到Dynamo DB。如何調用這些函數呢？我們可以在用戶從本地往S3上上傳圖片時觸發。一旦圖片被上傳，S3會自動觸發function並將事件數據傳送給function。Lambda function獲取數據，縮放圖片，然後將優化過的圖片存放在S3上。這一切在用戶還在填寫用戶名，郵箱，密碼時就已經開始執行。

當用戶點擊「完成註冊」，你的代碼會通過AWS API gateway調用DynamoDB function，這個function收到數據並存儲到DynamoDB中。當然，你可以在你的function中在插入前進行其他操作。

即使你有成百上千個用戶同時操作，你也不需要擔心伺服器會變慢或者crash。這些負載被交給AWS來處理。

還有一個重要的地方上是，如何確保你的應用和lambda解偶？構建應用時最困難的地方在於確保後端時可插拔的。後端應該像樂高積木一般可插拔到應用，並且沒有困難。在我們的例子中，你的應用只和S3和AWS API gateway打交道。這使得你很容易進行測試你的應用，並且也容易從lambda遷移。這便於重用，比如你最開始是web應用，後來打算創建web應用，你可以將他們很容易的應用到你的系統。他們其實沒什麼區別。

剩下最後一個問題「什麼時候應該使用lambda？「，有些場景模型與本例子相似，有些場景需要混合使用。你可以使用事件驅動的代碼做某些事情，從而免除伺服器管理的工作，從而讓你的工程師更加專註於關鍵任務而不是重複發明輪子。

理解如何使用lambda，可以為工程師節省很多時間和精力。工程師們不必在操心伺服器的維護和日常管理，應用不但不需要被更多的照看，同時可以跑的更快，擴展性更強。

如果你覺得很有趣，為什麼不看下Lambda Deep Dive Course.

對目前最高票答案部分贊同：

針對答主的疑惑，做一些科普

1 AWS是十年磨一劍，很早就有了，很多功能，都是在客戶的『千錘百鍊』下才出來的。Lambda算是其中之一。S3的確算是serverless 的一個思想體現，但是實際中很多公司還是會有不同於s3的文件需求，這也為之後一些文件存儲新的產品形態做好了鋪墊。所以有一些答案說S3就是AWS早期push serverless觀點，我是不贊成的。

2 Serverless這個想法的雛形到最後成型，應該是拜aws reinvent一場展示所致。

成型的想法叫 jawsframework 展示於2015 十月的AWS reinvent上

https://www.youtube.com/watch?v=D_U6luQ6I90

之後改名叫作serverless，github直接晉級大熱，萬星級別關注度

傳送門 Serverless - The Serverless Application Framework powered by AWS Lambda and API Gateway

3 之前其實好像公司有談和google cloud的合作，最近翻沒聲音了，官網清一色AWS標誌。可見，這個想法成型並不是由Amazon推出的，而是AWS整個社區用戶自行整合想法和產品的借鑒，運用了lambda做的一個event driven的框架，只是最後被AWS又爭取到了優勢而已。

4到現在15個月不到，AWS官方跟進速度非常快，馬上又跟進完善了lambda的產品，同時擴展lambda的部署地區（對，15年lambda只是一個小地區試點產品）

5 某種程度上來說,AWS本身並沒有特彆強的動力去推這樣的產品，畢竟，host一個主機然後賺錢這個老掉牙的套路不是更爽，然而，跟進時代必須要自我革新，平台上有了這種serverless的框架，意味著一些特定用戶的成本和機動性就又有了一個質的飛躍，作為服務方馬上跟進，這是一種公司戰略級別能力的展現。lambda作為一種對AWS整體生態的補充到現在成為一個思想流派，並不是完全取代之前的生態模式，而是在這個基礎上更進一步，一些人照樣用原先的框架獲得特定情境的最優解。

6 AWS在很多細分市場已經碾壓各路對手了，現在還是在瘋狂圈地，比如snowball mobile，基本是開著卡車，幾個月徹底俘虜一個財富500強客戶遷移方案的速度，如果你能翻過_____，進入AWS，你就會看到，現在多出來一個分項是遷移，同時在混合雲（Hybrid cloud)上，AWS也是有自己的部署和打算，這樣的話，就有一個本質的不同了。至於一些新的instance類型，也是對原先的戰略進行一個繼續貫徹的戰術動作罷了。

7 彩蛋，之前提到亞馬遜推我國MXNET作為DL的工具，也是對其雲平台分析能力產品的一個補充，在這裡要注意到Amazon這種半開放自主的產品提供速度可能會讓其他家自己覺得自己產品性能不錯的公司面臨排山倒海的能力。今年AWS 大會30K人參加，也是預示著，AWS已經成為這個行業的標準制定者。這種開放思路一旦和IOT（物聯網）相連，很多新的產品形態藉助於AWS的開發速度相較其他平台快不是一點半點哦。我們未來在amazon echo和google home上可能就要看到amazon藉助完善的雲平台生態擴展echo更多的應用場景和功能，完全碾壓Google home。

8 題主，這才是公司戰略，從這也可一窺我國雲計算行業和美國領先者的差距，在我看來，依然存在技術代差和隨之而來的戰略代差和生態代差。路還很長。

雲計算的發展最後應該是提供計算資源，而不是提供虛擬機的。

這兩年很多企業已經完成了數據上雲的任務接下來就是慢慢去掉傳統伺服器的框架了

建議有關廠商儘快推出serverless的標準名字我都想好了 common gateway interface

它對aws來說更大地拉開和對手的距離，提高市場地位；對用戶來說函數即是服務對於developer來說具有極大的誘惑，市場空間還是很大的，也或將成為容器之後的下一個熱點，docker大會上也做了一個用docker實現serverless的session。

並不會把蛋糕做小，畢竟使用場景不一樣。serverless將load balancing還有requests分發這些logic進一步的隱藏起來，實際上開發需要做的就是直接實現各種handler。個人感覺，用來寫一些無狀態的streaming的job會非常的方便，相當於Storm裡面的bolt，優點是能dynamic scale，還是很有吸引力的。

我不出，別人就不會出了么。（望向隔壁的柯達）

Serverless架構設計的優勢和具體的行業場景

主要是爭取創業公司，適合公司初期沒有業務量的時候或者某些情境下的事件觸發；雖然是serverless，但是數據以及存儲也得另外掏錢，另外結合aws的日誌服務，可以查看任意請求的日誌，lamba基本可以讓開放人員完全專註於業務本身，減少devops的成本。

使用lambda用戶請求少的時候比單獨的伺服器划算，但是當請求到一個量的時候，獨立伺服器就會更經濟了。