在企业级开发应用进入云原生开发时代之后，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控制台里编写的函数体。