在企業級開發應用進入雲原生開發時代之後，Serverless 架構這個詞也頻繁出沒於各大技術媒體裡。
Serverless的字面意思容易給人以 不再需要伺服器了 的誤解。
站在整個企業的角度上講，ABAP Netweaver 的 SICF 開發模式，和 Serverless 架構幾乎沒有任何聯絡，兩者區別很大：一個是需要在部署於企業本地的伺服器上編寫函式程式碼，另一個則是直接在雲服務提供商提供的平臺上編寫程式碼。
然而，從只需要專心搬磚的程式設計師個體視角出發，兩者也有一些相似之處：程式設計師都不需要關注自己編寫的程式碼在伺服器端如何儲存, 也不用操心這些函式在何時被呼叫。
當然，技術總是在向前發展的，執行在現代雲服務提供商基於Serverless架構平臺之上的函式，和執行在ABAP Netweaver伺服器上的SICF服務相比，就像一個含著金鑰匙出生的富二代，天生就具備雲原生應用的一些基本特質，比如高可用性，彈性伸縮，按需裝載，動態計費等等。
SAP 近些年來在雲原生開發領域進行了巨大的持續投入，自然少不了基於Serverless架構的解決方案，其中一個典型例子就是 SAP Kyma上的Lambda Function.
SAP Kyma Serverless的實現基於Kubeless，一個Kubernetes原生支援的Serverless框架，實現了執行於Kubernetes之上資源的自動伸縮，API路由，監控和排錯等功能。
藉助Kubeless提供的命令列介面，我們可以在Kyma上建立和部署具備Serverless特性的Lambda Function.
kubeless命令列介面提供的CRUD操作：
當然也可以在Kyma提供的瀏覽器控制檯裡進行建立工作。
如下圖所示，我建立了一個Hello World級別的Lambda Function，執行的邏輯是簡單的把傳入的字串尾部加上一個字尾，函式基於nodejs8實現。
我們試試透過 HTTPS 協議觸發這個 Lambda Function.
這個HTTPS-endpoint就是將來我們呼叫這個Lambda Function的url.
這個Lambda Function的認證由dex完成，一個基於openID的開源認證框架。
在Kyma提供的函式測試控制檯裡，傳送一個請求，得到新增了字尾的字串，簡單易懂。
當我們建立了一個Lambda Function，背後發生了什麼？雖然名稱為Serverless，但是這些函式物理上總得執行於伺服器上某種容器內，這種容器就是Kubernetes的pod，Jerry之前強調過，SAP Kubernetes基於Kubernetes，因此Kubernetes支援的命令，SAP Kyma也完全支援。
命令列檢視剛剛建立的函式：
kubeless function list -n ctu-demo
使用命令列檢視這個函式的明細：
kubectl describe function zjerry-lambda -n ctu-demo
Deployment和ReplicationSet：
水平自動伸縮的實現：
Lambda Function這個概念是SAP Kyma基於Kubernetes的Custom Resource Definitions(CRD)機制建立的一種自定義資源，而上圖顯示的這些函式屬性都是Kubernetes裡資源支援的原生屬性。
在Kyma的控制檯裡能找到Lambda Function建立後，Kyma後臺自動生成的對應資源：
Pod，即Lambda Function程式碼的執行環境：
同樣的，使用kubectl describe pod命令可以檢視這個pod的明細，找到裡面包含的docker ID和docker映象ID.
前面提到SAP Kyma的Lambda Function採取dex進行認證，如果想在程式語言裡顯式呼叫，需要提供相應的token.
在Kyma的控制檯裡拿到token，
傳到Postman的Authorization頭部欄位裡，得到期望的響應。
下面介紹如何在 Kyma 控制檯裡擴充套件新的 UI.
方法是建立一個新的resource，型別為ClusterMicroFrontend.
使用命令列kubectl get ClusterMicroFrontend檢視這些UI擴充套件：
最後自定義的UI出現在Kyma console的這個位置：
下面我們詳細分析 Kyma Lambda Function 的技術實現細節。
我在Kyma上建立了一個名為zjerry-lambda的函式，基於nodejs8：
可以直接在Kyma的測試控制檯裡呼叫這個Lambda Function：
Serverless的字面意思，不是暗示我們沒有伺服器了嗎？那麼這段函式程式碼到底執行在哪裡的？
因為SAP Kyma是基於Kubernetes的，因此我們還是可以透過Kubernetes提供的一些工具，來探索SAP Kyma上Lambda Function執行原理的一些蛛絲馬跡。
首先找到zjerry-lambda函式建立後，對應生成的pod，把名字抄下來：zjerry-lambda-86668f75d4-pfbk6
使用kubectl的互動式引數-ti，進入這個pod內部：
kubectl exec -ti zjerry-lambda-86668f75d4-pfbk6 -n ctu-demo -- /bin/sh
進入之後，檢視程序列表，發現了node kubeless這個程序，Jerry頓時覺得有點眉目了：
看樣子，SAP Kyma的Lambda Function是透過一個node程序執行的。檢視一下這個pod裡都有哪些檔案：
開啟kubeless.js看看裡面的內容：
如果您是一位nodejs開發人員，看到上面Jerry高亮的紅色內容，一定會恍然大悟。SAP Kyma的Lambda Function，其實執行在對應的Kubernetes pod裡啟動的express應用框架上。
Express的依賴定義在pod內部的package.json裡：
而待執行的Lambda Function邏輯，透過環境變數FUNC_HANDLER進行注入，在Jerry這個例子裡，函式體名稱為main：
在Lambda Function的Serverless框架，即kubeless.js執行時，會從pod內部的kubeless這個資料夾裡，找到應用開發人員編寫的Lambda Function，載入並執行。
大家可以看到，Jerry紅色高亮的位於pod內部的handler.js, 其內容就是Kyma控制檯裡編寫的函式體。
至此，SAP Kyma的Lambda Function實現，在Jerry眼中沒有任何神秘可言了。回到Serverless這個術語本身，並不意味著整個場景裡不再需要伺服器的參與，而是伺服器的這個關注點，在Serverless架構下，已經從應用開發人員的視角中隱藏起來罷了。
總結
本文首先介紹了在雲原生平臺 Kyma 上建立 Lambda Function 的詳細步驟，接著深入分析了 Kyma Lambda Function 的實現原理，希望對希望瞭解 Lambda Function 幕後實現細節的雲原生開發人員有所幫助。