什麼是 Serverless？
從英文的字面意思，跟 Serverful 對比，看起來好像是無伺服器？但這顯然不可能，畢竟無論如何，任何的程式最終都要在機器上執行。
要想了解 Serverless，我們有必要回顧一下我們通常的 Serverful 服務運作方式。
從 Serverful 到 Serverless 的演變
實體機的使用方式似乎從來都沒有變化，無論是 10 年前，還是現在。典型的流程就是硬體采購、拆箱、上電、做 Raid、插網線、調整交換機、做全面的配置檢查，順便還得檢查一些記憶體、硬碟、固件的品質等等，因為說不定跑兩天就挂了。整個環境上線，就是體力活。
虛拟化
感受到了痛苦，就會促使工程師們去改變。
已經辛苦地準備了硬體，當一個開發小哥需要一台機器的時候，作為 IT 管理人員，難道還要再次重複這個過程？
可以說虛拟化解放了 IT 管理者，通過在一台實體機上運作更多的虛拟機，提升了資源使用率以達到更好的财務收益之外，虛拟化還給部署以及運作一台 “機器” 提供了極大的便利。
通過作業系統虛拟化一套硬體，再結合虛拟機模闆鏡像的機制，意味着在實體機上建立和移動虛拟機也隻是分分鐘的事情而已。
以往的機器上線繁重、重複的體力工作消失殆盡。
雲
單機的虛拟化無法滿足大規模的場景，包括對排程，網絡虛拟化的需求等等。此時，雲橫空出世，你既可以選擇公有雲，也可以選擇自己搭建私有雲，如 OpenStack。
甚至你都不需要關心底層的硬體，隻要是通用的架構即可，作業系統、網絡、存儲等均可以自動化安裝、擴充出來。
然而，即使在雲時代，應用軟體的運作方式也沒有變化，無非是軟體看到的是一個虛拟的硬體環境而已。對于使用者而言，不同的一點隻是為軟體準備基礎環境的過程變快了。
容器化
盡管虛拟化充分利用了資源，極大的提高了便利性，但技術發展的車輪滾滾向前，工程師們總是得隴望蜀。虛拟化依舊存在比較 “重” 的問題，鏡像太大，多個虛拟機基本都包含重複的作業系統，實體機上無法運作過多的虛拟機。
容器化，尤其是 2017 年以來 Kubernetes 的流行，又一次帶來了改變。容器隻是一個輕量級的程序，而軟體提供者隻要維護一個 Dockerfile , 生成一個小得多的鏡像，在容器平台部署即可。應用的上線不再關心依賴、沖突，以及諸如 “我這裡運作沒問題，肯定是你的環境問題” 等等困擾。
Serverless，更容易了解的一個名字是 functions-as-a-service，我想這樣起名的一個初衷是讓你不再關心伺服器，也不需要考慮他們，隻要執行你的代碼就好。
設想一下即使是在容器化加持的情況下，應用開發者依然要關注諸如 RestAPI 架構如何搭建、工作流怎麼處理、壓力來了怎麼進行負載均衡、消息中間件如何處理等問題，有可能還要關心安全更新、漏洞掃描這些與業務邏輯關聯不大的瑣事。
2019，UC 伯克利大學發表了一篇“ Cloud Programming Simplified: A Berkeley View on Serverless Computing”的論文(https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf)，論文中有一個很形象的比喻，描述如下：
In the cloud context, serverful computing is like programming in low-level assembly language whereas serverless computing is like programming in a higher-level language such as Python. An assembly language programmer computing a simple expression such as c = a + b must select one or more registers to use, load the values into those registers, perform the arithmetic, and then store the result. This mirrors several of the steps of serverful cloud programming, where one first provisions resources or identifies available ones, then loads those resources with necessary code and data, performs the computation, returns or stores the results, and eventually manages resource release. The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages.
那麼總結起來什麼是 Serverless 呢？其實就是你隻需要關心的業務邏輯，所有其他的全部交給外圍所運作的平台工具等去處理。
實作方式
各大公有雲有各自的實作方式，例如 AWS Lambda, 阿裡的 BatchCompute, Azure Function 等等， 但每家都有不同的使用方式，存在 Lock-in 的風險。那麼如果在私有環境上實作，有什麼選擇呢？
Fn project
Fn project 是 Oracle 開源的一個項目，看起來是非常簡單直接的，有一個 Docker 即可運作起來。問題就是不夠活躍，半年内似乎都沒有新的 commit。
Kubeless
聽起來最正統的名字，是由 Bitnami 貢獻的一個項目，基于原生的 Kubernetes ，通過自定義資源 CRD 的方式來實作，但由于受到 Knative 的影響，前途不太明朗，連創始人都建議關閉掉這個項目。
由 Platform9 貢獻的一個項目，它既可以利用到 Kubernetes 的豐富功能，也可以在需要時候獲得更好的性能，例如冷啟動。這個也是筆者在 Fn project 之後跑起來的第二個項目。
Fission
Knative
名門出品，集大成者。Google 開源的項目，目前參與的公司主要是 Google、Pivotal、IBM、RedHat, 基于 Kubernetes 以及 Istio。
Serverless Over 存儲
阿裡王堅博士的《線上》裡有一句話說的特别好，“需求才是競争力”，想到，做到；做到，用到。在與 AI 的同仁交流過程中，壓榨整個工作流過程中的每一點性能，都是對整個結果的很大提升，這不禁促使我們思考如何才能更加高效的存儲和處理資料。
先不提 Computable Storage , 以 AI 的場景為例，AI 作為一種新的資料處理技術，它涵蓋了采集、準備、訓練和推理四個階段，每個階段都伴随着資料的流動以及處理。
資料采集階段：資料從不同來源聚攏并存儲起來，資料的大小和格式存在各種差異，資料類型往往是檔案形式的非結構化資料。
資料準備階段：由于資料的大小和格式不一樣，為了便于進行 AI 模型訓練，必須改為統一格式，以便後續訓練階段使用，這一過程要對不同格式和尺寸的資料進行規範化處理。
訓練階段：AI 訓練過程的工作負載非常密集，往往需要高性能的 GPU 或者加速器等來執行一系列的數學函數，對資源要求非常高，在做特定訓練時，AI 訓練所需的時間更加取決于所部署的存儲的性能。
推理階段：推理過程是檢驗人工智能的階段。推理基礎設施根據不同的場景，所需配置的處理器、記憶體、存儲不盡相同。
通常的資料準備階段，都是利用 Hadoop 等批量處理工具對資料進行清洗，在 Hadoop 計算節點與分布式資料存儲節點分離的情況，一個典型的過程就是，讀出、計算、寫入，意味着資料要流出存儲叢集，再流入存儲叢集，能否盡量避免資料的流動，讓計算離存儲更近一些呢？
基于 Serverless 架構，我們在 YRCloudFile 的基礎上，可以運作更加實用的功能，例如資料複制，資料壓縮，資料解壓等等更适合發生在存儲端的操作。
以下示例示範了向 Serverless 架構送出一個資料拷貝的請求（函數），讓這個請求在後端存儲自動執行，送出請求者無需關心後端資料的處理過程。
利用對應的架構建立 Function 以及 Trigger 之後，隻要通路對應的URL即可完成相應的動作。
如果你的動作夠快，進入到對應的 Function 容器内，你會看到裡面存在的對應的目錄對存儲的引用。
這隻是一個最簡單的資料拷貝例子，我們可以編寫更複雜的資料處理函數（Function），并直接送出到 Serverless 架構上，由後端的資料存儲去針對複雜操作完成相應優化和處理。工程師們可以快速地實作使用者需要的功能，甚至可以完成工作流你 Pipeline，進而賦予應用更多可能。