在企業級開發應用進入雲原生開發時代之後，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控制台裡編寫的函數體。