作者 | 蒲鬆洋（秦粵）
作者說
在開始本篇內容前我想與各位開發者達成幾個共識。
第一個共識，軟體工程沒有銀彈， Serverless 也不是銀彈，它並不是解決所有問題的萬能公式。
第二個共識，Serverless 能夠解決的是運維域的問題，它是解決特定領域問題的一個技術，並不是無限延伸的，與低程式碼沒有關係。
第三個共識是複雜度守恆定律-泰斯勒定律（Tesler’s law）。典型例子就是蘋果，蘋果的產品很容易上手操作。但本質上它整體複雜度是守恆的，它其實是把複雜的事情留給了系統開發工程師和軟體開發的工程師，讓使用者可以順滑體驗。同理 Serverless 也是如此，把部署 or 運維應用、網站的煩複轉交給了雲服務商，但整體的複雜度是不變的。
第四個共識是鄧寧-克魯格效應（The Dunning-Kruger Effect），大家在認知學習過程中，都會出現這樣的發展曲線：從剛開始一無所知，到對新知識的幻想，再到失望的低谷，緩慢爬坡。我們學習任何一個新事物都會經歷這樣一個曲線過程。Gartner 採用鄧寧-克魯格曲線，來解釋新技術的發展週期。
個人認知曲線
Gartern 技術發展曲線
作為開發工程師經常會有這種體感，新的技術層出不窮學的很累。Serverless 剛推出來時也一樣，大家對這個技術充滿了無限的想象，當想象到了一個巔峰以後，會慢慢認識到想象與現實的差距，切身去體會在產品中使用時就會掉到技術的低谷，然後再緩慢的爬坡。
Serverless 正當時
本文將會通過三個部分，為各位介紹 Serverless：
第一個部分是 “複雜化 for 雲開發商”
第二個部分是 “簡化 for 開發者”
第三個部分，會介紹一些我自己和我們團隊使用 Serverless 的最佳場景。
複雜化 for 雲開發商
1) Serverless 架構
Serverless 是一個集大成者，它的整發展歷史是站在巨人的肩膀上的。現在很多雲服務商去跑一個函式，底層都是這樣架構。首先 Serverless 的執行底層會有一個 CaaS 層。它是一個 Serverless 化的容器服務，大部分的應用服務都會跑在這一層上面，容器排程現在開源的比較好的解決方案就是 K8s，用 K8s 來排程容器，底層 laaS 就是虛擬機器，最底層則是物理機。
CaaS 的實現的方式有很多，Serverless 應用底層必須有 CaaS 服務的支撐。除了Docker 以外，vm 也可以是 CaaS ；例如 Node.js 的 vm 也可以做 CaaS ，webassembly 也可以做 CaaS 等等。另外在做整體架構設計的時候，還需要一個 Component 層去解決網路東西流量和南北流量的問題，例如 service Mesh 和 ingress 的方案，總體來說 Serverless 背後的架構設計基本都是如此。
2) 雲開發商：不可變基礎設施
CNCF 的架構整套框架是根據配置檔案去遷移的，可以部署在阿里雲、也可以騰訊雲、亞馬遜的雲上，甚至自己搭建的私有云。當所有云服務作為不可變基礎建設，複雜度下沉到 K8s 層，架構會變得通用。
另外對雲服務商來說，他們以前積累的傳統的優勢(虛擬機器 laas 層的運維優勢和 PaaS 層的平臺級的優勢）就會漸漸失去。所以如果是 vendor-unlock 雲服務商之間就會白熱化地打價格戰，看誰能提供更優質便宜的服務。
廣義的 Serverless 是整個雲服務商運維體系的 Serverless 化。如傳統提供一個MySQL 或 Redis，必須讓開發者意識到這是跑在伺服器上的，需要提供出來個 ip ，但 Serverless 化（BaaS 化）後，開發者不需要再去關心這個服務到底是執行在哪裡，只需要申明需要一個 DB，應用就可以自動去連結並消費 DB。
狹義的 Serverless 不僅僅是 Severless Computing，還指一個 FaaS 的應用，是由 trigger（也可以歸併為BaaS） + FaaS + BaaS 的架構組成的。現在雲開發商在 Serverless FaaS 的這一層的核心競爭力是不斷推出新的 BaaS （Backend as a Service） 能力，而 BaaS 主要是跟 FaaS 配套去使用的。
上面講到的雲服務商的不可變基礎建設，如下圖所示，開發者在最上面這層去部署應用，根本不用關心底層的這些基礎建設。現在雲服務商提供的 BaaS SDK 實際上已經包含在你的這個 FaaS 的 runtime 裡面，開發者只需要把它當成一個函式介面去直接呼叫，不用關心資料庫部署在什麼地方、要不要保持長連結等等。
簡化 for 開發者
此圖是 Gartner 在 2017 年推出的新興技術發展狀態，當時 Gartner 覺得 Serverless 還是一個比較新的概念，大家對它的認知還處於爬坡階段；但實際上到今天，Serverless 已經進入了平緩爬升期了，大家對 Serverless 可以解決運維域的問題，有哪些邊界的限制等等這些問題已經有了清晰的認知。
為什麼最近這幾年沒有什麼特別新的東西推出了？原因在於 Serverless 這層沒有特別新的概念誕生，大家更多是在做 FaaS 應用基礎建設。現有的各種 Web 應用場景場景是否可以 Serverless 化，比如近期已經支援了的，資料庫 BaaS 化， websocket 支援 FaaS，另外還有很多 Web 應用場景都是通過諸位的努力慢慢爬坡實現，使其能夠接近理想中的 Serverless 。
2021 年 Gartner 技術採納建議圖
圖中畫框的位置就是 Serverless，綠色代表已經成熟，可以看出，現在的 Serverless 已經是一個比較成熟的技術了，支援大部分 Web 應用的場景了，所以各位開發者大家可以放心大膽地去嘗試 Serverless。
1) 運維領域的 Serverless
國內很多人把 Serverless 翻譯成無伺服器或者叫無服務，這都不太準確，Severless的反義詞是 Serverful，Serverful 的意思是需要特別關注伺服器，Serverless 的本質是為了降低心智負擔，不需要十分關心伺服器，只專注部署函式就行，至於它怎麼執行、底層有多少容器、底層有多少伺服器來支撐它，開發者都不需要關心。
傳統的模式的前後端開發模式是由：後端提供資料服務，以前叫 SOA 是面向服務的程式設計，現在比較流行的是領域驅動微服務，前端消費組裝資料。後端資料介面傳統的方式是提供 HTTP API，到現在的流行的 BFF (Backend For Frontend) 膠水層函式編排。配合微服務提供全量資料，是目前業界比較流行的做法。那麼未來的趨勢將會全部 BaaS 化，理想的狀態是前後端一體化模型驅動，不再需要再寫介面。
2）結合 Serverless 做技術變革
Serverless + = ...
當下 Serverless 所處的階段的優勢是跟其他領域的技術結合， Serverless 結合其他領域來引爆許多技術變革。例如，傳統的微服務 + Serverless 結合起來後，可以做成 BaaS 化微服務。以前提供一個微服務，是需要開發者去關心這個微服務部署在哪裡，但是加上 Serverless 後，便不用管部署在哪裡，只需要關心怎麼去呼叫即可。LowCode 加上 Serverless 可以讓搭建出來的頁面快速部署並上線；之前的介面函式編排如傳統的 BFF，在未來都可以 Serverless 化，變成 SFF（Serverless for frontend），很適合做前後端一體化方案。
3）開發角色的轉變：前後端一體化
Serverless 出現後，未來還會出現前後端一體化的局面。現在已經出現邏輯編排視覺化的工具，例如狼叔的 iMove ，目前已經可以做到後端介面的視覺化編排，前端工程師去做一個後端的介面編排變得非常簡單。由此可以預見，前端工程師未來的職責可以往後端去延伸。
而原來的後端工程師會從傳統的應用部署逐漸轉化去做 BaaS 化服務級別的開發，而未來運維工程師也會更偏向於向雲端遷移。這個就是 Serverless 對研發生產鏈路帶來的一系列變革。
Serverless 的最佳場景實踐
對於 Serverless 使用最近場景的判定，最便捷的方式就是去看雲開發商支援哪些 Trigger 事件觸發。
所以目前這個階段，各個雲開發商都在不停的增加新的 Trigger。如圖所示，開發人員在寫 FaaS 時，是將 HTTP request 包裝成了 Trigger，可以把 FaaS 函式想象成在封閉的一個包裹裡面，要如何喚醒這個包裹，怎麼開啟這個包裹呢？其實就是通過 Trigger 來喚醒。
另外 Serverless 的現階段，開發語言的重要性沒那麼高了，語言只是去實現功能所需要的工具。CNCF 推出來以後 FaaS 就已經是與語言無關的了，那麼其實到底是 Node.js，PHP，Python 亦或是其他主流語言的程式碼 FaaS 都可以，你甚至可以自建一個映象自定義語言和執行環境。因此在 Serverless 後，多語言的優勢我們都可以借用，比如用 Python 去處理 AI 資料，Node.js 去處理高併發網路 I/O 等等。
1）SFF 資料編排
最佳實踐就是 BFF + Serverless，這在阿里集團內部是十分常見的。由於阿里內部的大多場景後端都是 Java 工程師，前端團隊需要跟工程師去對接，而後端工程師提供的就是 HSF 微服務，可以把它理解為一堆 RPC 介面。以前就是部署一個 Node.js 應用去調介面，拿到資料後對這些資料進行是清洗、處理，放到前端頁面去渲染。但是採用 Serverless 部署 BFF 的 Node.js 應用後，基本不需要考慮跟進流量擴縮容、節省成本等問題。
2）GitOps 模型
GitOps 對於小企業來說，是非常適用的場景，相當於可以自建一套自動釋出上線的管道，不再需要像以前一樣，修改一個版本便要測試一遍，目前整個方案已經十分成熟了。Git 本身支援大量的 hook 函式，所以打造這樣一個流程也是非常容易的。需要關注的是要結合雲開發商的能力，比如阿里雲釋出流程便十分自動化，在雲下平臺釋出上線後可以支援線上的流量錄製、回放。
3）小而美的技術團隊
最後一點是打造小而美的團隊。在我的認知中，技術架構有個強大制約就是：組織架構會決定我們的技術架構。
就像前後端分離，大多是因為組織架構定義了：前端有前端的領導，後端有後端的領導，所以就會產生前端由前端的開發，後端由後端的開發，需要中間去聯調基於 API溝通。那我們如果要想打造一個小而美的團隊怎樣打破這個隔閡呢？
Serverless 一個比較適合的場景就是，通過前端的服務編排 SFF 將解決掉中間 API溝通的問題，後端去提供全量的服務即可。這種變革會迫使後端去做微服務化，甚至後端研發採用 Serverless 去做 BaaS 化，這是反向的導推過程。如果我們的前端團隊掌握了 Serverless， 有三個優勢：前端的資料編排便不再需要再找後端工程師了；GitOps 解決部署運維，可以降低前端心智負擔；前端同學能夠專心抽象業務模型。
講師簡介：
蒲鬆洋，花名秦粵。極客時間《Serverless 入門課》作者。Serverless 和 Node.js 佈道者，目前負責阿里巴巴前端委員會標準化小組，低程式碼小組--中後臺搭建，Node.js 應用微服務架構。在微服務、Serverless 以及中臺專案中有著豐富經驗。
戳此處，可觀看 Serverless Meetup 深圳站回放！