一、背景
Serverless 概念從2012年開始提出，真正推出相關雲產品是2014年AWS推出Lambda。如果我們將 Serverless 比作一個嬰兒，那麼它已經6歲了。
雖然業界對Serverless尚無一致認可的定義，但是我相信大部分開發者在聽到 Serverless時，會聯想到Lambda，並且冒出“函數”、“按需（調用次數）收費”、“事件驅動”等關鍵詞。確實當年剛剛誕生的Serverless就像下面可愛的“紫薯人”，紫色充滿神祕感（當年剛推出的時候絕對是黑科技），讓人印象深刻。
AWS的巨大影響力以及本身攜帶的一身黑科技，確實讓人記住了 Serverless，但是也正因為誕生的時候太印象深刻，以至於現在提到已經6歲的 Serverless，很多人的印象還是停留在Serverless=Lambda或者Serverless=FC（Function Compute），這不得不說是某種遺憾。
今天企業都在全面數字化轉型，整個技術架構體系都渴望依託雲原生來獲取巨大技術紅利，Serverless從誕生的第一天起就是雲原生的，所以我們有必要再系統的認識一下Serverless的理念以及這些年誕生的相關產品，相信不管你是前端、後端、架構師、SRE、CTO都會有所收穫，並且在未來能更好的發揮Serverless的技術價值助力商業成功。
二、定義
業界一直在嘗試定義Serverless，比如CNCF給出的定義是：NoOps 和Pay as You Run，還有伯克利說 Serverless=FaaS+BaaS。但是我想說，Serverless 其實無需再去定義，他本身就已經非常清晰明確：“Server+less”，他是一個理念，核心思想就是你不再需要關注 Server，作為對比的是 IaaS 時代，購買服務器，安裝各種工具，再在上面開發自己的業務。
Server不會消失，而是讓一般的開發者不需要再關注 Server，這意味著【智能彈性】、【快速交付】、【更低成本】，這也是 Serverless 相關產品的典型特性。
所以沒必要再去給 Serverless 做什麼定義，他本身已經描述的很清晰。我們拋開概念，具體看看在各個具體技術領域的產品，相信你會有更直觀的認識。
三、PaaS在 Serverless 時代的重生
PaaS 本身的概念挺大，廣義的說它處於IaaS和SaaS之間，我們先從一個具體的產品說起：GAE（Google App Engine）。2006年AWS推出了IaaS的雲計算，Google認為雲計算不應該是IaaS這樣的底層形態，所以在2008年推出了自己的雲計算代表產品GAE（關於這裡的發展緣由，可以參考張磊的這篇文章：容器十年 ，一部軟件交付編年史）。
初推出的GAE，也像Lambda，讓人眼前一亮，但是很快開發者就發現它的限制非常多，用今天的話說就是典型的“我不要你覺得，我要我覺得”，最後的結果就是大家都紛紛回到了IaaS的懷抱。
到後來的PaaS產品比如Cloud Foundry，這類PaaS產品相對更實際一些，底層IaaS還是雲廠商提供，上層提供一套應用管理生態，背後的思想還是不希望開發者通過IaaS這麼底層的方式去使用雲計算，而是從PaaS開始，不過它也不是Serverless化的，你還是要考慮服務器的維護、更新、擴展和容量規劃等等。
SAE（Serverless App Engine）
到了現在，隨著容器技術的成熟，以及Serverless理念的進一步發展，PaaS和Serverless理念也開始融合，這樣的產品既有PaaS為代表的【快速交付】，又有Serverless的特點【智能彈性】、【更低成本】，典型的產品代表就是阿里雲在2019年推出的產品：SAE（Serverless App Engine）。
首先，它是一個PaaS，再具體一點說，是一個應用PaaS。這意味著大部分開發者使用起來都會非常自然，因為裡面的概念你會非常熟悉，比如應用發佈、重啟、灰度、環境變量、配置管理等等。
同時，它也是Serverless化的。這意味著你不必再關心服務器，不用再申請機器，維護服務器，裝一堆工具，而是按需使用，按分鐘計費，結合強大的彈性能力（定時彈性、指標彈性）實現極致成本。
最後，得益於Docker為代表的容器技術的發展，SAE解決了經典PaaS的突出問題（各種限制和強綁定），依託於容器鏡像，在上面可以跑任意的語言的應用
看到這裡，我相信大部分開發者對於 PaaS 和 Serverless 結合的產品已經有了一個輪廓，在中國雲原生用戶調研報告中(2020年) ，這種形態的Serverless產品開始被越來越多的開發者採用。
在這個基礎上，還有另外一個話題值得再討論一下，那就是微服務和 Serverless。
微服務和 Serverless
現在業界關於微服務和 Serverless，會有部分這樣的認知：認為當前雲計算典型代表技術是微服務，下一代的代表技術是 Serverless，這會讓你 Serverless 比微服務要先進，甚至會覺得未來有了 Serverless 就沒有微服務了，類似下面這張圖：
個人認為產生這一認知還是因為將 Serverless 的理念具象化到函數計算（FaaS）這樣的產品。現在我們聊到微服務，會想到背後的技術框架，比如Spring Cloud、Dubbo，但是其實微服務這個詞已經遠遠超出了純技術框架的範疇，他背後也有核心的支撐思想，包括：
1 . 微服務雖然一定程度上增加了技術複雜度，但是在一定規模下他會降低系統複雜度和組織複雜度。
2 . 現代業務系統越來越複雜，很多業務系統會基於領域驅動設計（DDD）設計，微服務其實是DDD背後的支撐技術。
所以如果到了Serverless時代就沒法用微服務，我相信很多開發者會覺得不知所措，或者會“牴觸未來”，因為他們會覺得有人給我描繪了一個未來，但是完全不知道怎麼走過去。
拋開各種具體的技術實現，回到背後的理念，Serverless代表的是一種無需關注服務器，降低使用雲計算服務的理念，所以它和微服務其實不衝突，完全可以共存。在阿里雲的SAE中，集成了微服務的能力（依託於阿里雲產品MSE），這意味著：
1 . 部署在SAE這類Serverless平臺上的應用，完全可以繼續使用微服務開發，不需要經過任何改造。
2 . 在SAE上甚至提供了很多微服務能力增強，包括了註冊中心託管、服務治理等等，進一步降低開發者使用微服務的門檻和負擔。
所以在Serverless類的PaaS產品上，Serverless和微服務不再是對立的，開發者完全可以繼續使用微服務技術開發，同時也可以享受Serverless理念所帶來的【智能彈性】、【更低成本】等。
四、函數計算FC
講完Serverless Application（應用），我們再來看看Serverless Function（函數），FC作為”根正苗紅“的Serverless產品，相信大家都對他不陌生，經過這麼些年的發展，它已經在前端Serverless、多媒體處理、AI、事件類的場景（雲產品事件、數據庫變更事件等等）、物聯網消息等場景得到了很好的應用，甚至也有越來越多的公司將業務完全構建在FC之上，比如：世紀聯華的 Serverless 實踐。
另外針對早期的很多技術限制，現在也已經有了解決方案：
1 . 早期大多數的函數計算產品都對磁盤大小、代碼包大小、運行時長、內存規格等有限制，阿里雲函數計算推出了性能實例基本解決了這些限制。
2 . 針對冷啟動問題，可以使用預留性能實例解決。
下面我們就具體介紹部分使用FC的典型的場景
前端Serverless
前端經過了Ajax、Nodejs、React等技術迭代後，已經形成了相對成熟的技術體系，特別是Nodejs，使前端和服務端產生了聯繫。
前端和後端的分工發揮了各個的優點，但是在協作的過程中也一直存在一個問題，後端同學通常是面向領域和服務提供接口，但是前端是面向用戶具體的數據接口，有時候一個簡單的需求會因為兩邊的定義和聯調搞半天。所以也誕生了BFF（Backends For Frontends）這樣一層，誰使用誰開發，專門解決領域模型 - UI 模型的轉換。
理想很美好，現實也很骨幹，如果前端同學去做BFF這一層，發現要學習後端的DevOps、高可用、容量規劃等等，這些其實是前端同學不想關心的，這種訴求在Serverless時代得到了很好的解決，由BFF變為了SFF（Serverless For Frontend）,讓前端同學只要寫幾個 Function，其他都交給Serverless平臺
類似的還有服務端渲染 SSR（Server Side Rendering），本來前後端分工後，後端只需要寫接口，前端負責渲染，但是在SEO友好以及快速首屏渲染等需求背景下，有時候會用到服務端渲染的方案，同樣，使用Serverless 前端同學又可以愉快的玩耍了。
其實現在很多偏前端產品裡面（比如各類小程序以及語雀等產品），前端同學會全棧完成整體開發，越來越多的會用到Serverless相關技術
當然，要用好Serverless，需要完整的生態，包括相關的框架，運行時，工具鏈，配置規範等等，這方面可以參考阿里 Midway
多媒體處理
現在在線教育、直播、短視頻等等行業都蓬勃發展，也催生了很多視頻需求，包括視頻的處理，包括視頻剪輯、切分、組合、轉碼、分辨率調整、客戶端適配等等，典型場景的比如：
每週五定期產生幾百個 4G 以上的 1080P 大視頻， 但是希望當天幾個小時後全部處理完
甚至您有更高級的自定義處理需求，比如視頻轉碼完成後， 需要記錄轉碼詳情到數據庫， 或者在轉碼完成後， 自動將熱度很高的視頻預熱到 CDN 上， 從而緩解源站壓力。
這些訴求在Serverfull的場景下，你可能需要搭建一套複雜的系統來支撐，但是如果使用FC那麼你會發現一切都變得那麼簡單。
AI Serverless
AI Model Serving 是函數計算一個比較典型的應用場景。數據科學家訓練好模型以後往往需要找軟件工程師把模型變成系統或者服務，通常把這個過程稱之為 Model Serving。函數計算無需運維和彈性伸縮的特性，正好符合數據科學家對高可用分佈式系統的訴求。
五、Serverless容器-ASK
Kubernetes作為生產級別的容器編排系統，現在已經成為了容器編排的事實標準，被廣泛用於自動部署，擴展和管理容器化應用。它也有相應的Serverless Kubernetes產品，比如阿里雲的ASK、AWS Fargate等。在這類產品中，你無需購買節點即可直接部署容器應用，無需對集群進行節點維護和容量規劃，並且根據應用配置的CPU和內存資源量進行按需付費。ASK集群提供完善的 Kubernetes 兼容能力，同時降低了 Kubernetes 使用門檻，讓您更專注於應用程序，而不是管理底層基礎設施。
如果您是K8S的重度用戶，那麼使用Serverless Kubernetes是一個不錯的選擇，典型客戶場景包括：
微博：在30s之內可以極速擴容500個應用實例，應對跨年活動和熱點事件；
曠視科技：基於ASK開發智能、免運維的AI應用平臺；
趣頭條：基於ASK構建Serverless大數據計算平臺。
六、BaaS
上面提到的都是”計算類“Serverless產品，FC、SAE、ASK等，但是我們都知道，開發過程中不可能只有計算邏輯，還有很多其他依賴，比如存儲、中間件等。BaaS(Backend-as-a-Service，後端即服務）類產品，提供基於API的服務，這些API一般都是按需使用、免運維、自動擴縮容的，所以他們也是Serverless的。
典型的比如阿里雲的OSS，具有與平臺無關的 RESTful API 接口，可以在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。
值得一提還有開發企業級應用時大家非常熟悉的中間件，以阿里為例當前也在進行4.0技術架構升級，全面BaaS化，統一運維、交付、計費、支持模式，開箱即用，產品化程度持續提升
七、總結
總結一下，上面提到的一系列Serverless的產品，覆蓋了前端，後端，容器，BaaS各個領域，包括很多上面沒有提到的（比如CDN）其實也算是Serverless的產品，所以我不認同伯克利的Serverless=BaaS+FaaS的觀點，但是我非常認可他的另一個觀點：“Serverless will dominate cloud computing”。
Serverless首先是一個理念，不是某一種具體的技術，當未來某一天，99%的雲產品都有Serverless化的形態時，雲計算也就Serverless化了，這種變化我認為不是非黑即白的，不是推翻重來這種革命性的，而是全面的降低用戶使用雲的成本，全面的提升開發者的研發效率。
作者簡介：陳濤，10年軟件開發經驗，4年創業經歷，曾在淘寶、滴滴任職，關注雲原生、微服務、Serverless 等技術領域，積累了在雲計算、電商、從0到1創業等方面的研發、管理和業務經驗。目前就職阿里雲，在雲原生應用平臺從事Serverless應用引擎（SAE）的設計和研發。
