带你玩转新一代无服务器产品：IBM Cloud Code Engine（一）

IBM Cloud Code Engine已经正式发布许久，近期终于有时间来介绍这个云中利器。IBM Cloud Code Engine（后称作：代码引擎）是一个完全托管的、无服务器的平台，支持所有本地云容器化的工作负载。用户体验是以开发人员为中心的，这样设计可以让用户和开发者专注于编写代码，而不需要处理底层基础设施及其安全性。传统的Serveless，包括IBM和友商的Functions服务，AWS的Lambda都是基于函数，通过trigger+action的方式实现简单的业务场景，初始启动时间和性能也都一般，而IBM Cloud代码引擎可以作为Serveless 2.0，支持秒级的初始启动时间和可扩展的性能，适用于多种工作负载和业务场景。

有容器经验，但没有管理集群的技能或预算：

开发人员对容器很了解，但整个部门和团队不希望面对管理集群的复杂性和时间消耗。使用代码引擎，不需要担心管理集群所需的技能或所需的时间，也可以消除了这些复杂性，IBM团队将支持基础设施作为IBM云服务的一部分来管理。

具有间歇性峰值的工作负载：

企业运行一个网站，在工作日流量较少但是周末流量非常大。网站经历了这些突发的活动后是一段时间的不活动，代码引擎是一个很好的解决方案。使用代码引擎, 用户网站应用程序会自动扩展应用程序实例，以应对流量的增加，然后在不活动的时期再次缩减(甚至降至零)。使用一般的Kubernetes服务或自建Kubernetes集群时，用户必须首先根据工作负载峰值确定集群的大小，支付大量的费用，即使没有完全利用它。

批处理工作负载与存储集成：

用户有一个在每个月底处理员工工资的批处理工作，因为这个作业每月运行一次，所以它大部分时间都是空闲的，但是在运行时消耗了大量的CPU和内存。为了存储结果，批处理作业需要与存储集成。通过使用代码引擎, 可以将批处理作业与IBM云对象存储集成在一起，并且只对作业运行时使用的资源收费。当作业处于空闲状态时，它不会消耗任何资源，因此也不会产生费用，仅支付IBM Cloud Object Storage产生的极少费用。

部署工作上云：

用户有一部分工作是创建并部署映像，开发团队在创建容器映像和部署它们方面很有经验，但是他们希望简化这个过程，以便能够集中精力于其他任务。有了代码引擎，开发团队可以使用同一个界面构建和部署映像，从而简化了日常任务，节省了开发更多代码的时间。

测试、概念验证或试验过渡：

企业对学习更多关于基于容器的架构感兴趣，团队开发了一个应用程序，但希望在应用程序提交生产环境之前进行测试。这个应用程序很小，所以开发团队不想为一个小型的、专用的Kubernetes集群付费。在这种情况下，用户可以基于代码引擎测试应用程序，然后向管理员提供设计的概念证明，而无需支付专用集群需要的成本。

让我们先看下代码引擎的架构：

代码引擎基于开源的技术，核心是Kubernetes+Knative+Istio，Knative有助于在Kubernetes中隐藏管理基于http的工作负载的复杂性，也用于根据并发的HTTP请求数量扩展应用程序，Istio充当网关，终止HTTPS请求，并将HTTP流量路由到正确的应用程序和修订。此外，IBM Cloud代码引擎通过提供用于创建应用程序的源代码以及与Tekton和Shipwright开源项目集成来将源代码转换为容器映像来支持，代码引擎部署在虚机上，底层是物理机。通过提供容器化的工作负载或源代码来支持开发人员，然后将其构建为一个容器映像，用户可以通过使用传统的Dockerfile构建机制或Paketo Cloud Native Buildpacks来构建镜像。通过这些构建包，无需自己不断地寻找和修复容器映像漏洞问题，开发者可以将事件生成器与IBM Cloud 代码引擎事件集成。

如果你在之前就已经使用 Docker ，那基本上都是自己编写 Dockerfile并维护其版本 ，然后自己写脚本使用 Dockerfile 打镜像包。但是这种方式适用于个人测试，如果是团队开发协作开发企业级应用，那么还有个更好的选择，那就是Cloud Native Buildpacks，它可以在开发工具比如IDE中以plugin形式安装，在Spring Boot中构建Docker镜像。在IBM Cloud代码引擎中我们推荐使用Paketo Cloud Native Buildpacks。如果你了解 Dockerfiles 的话，那你肯定了解用 Dockerfiles 构建镜像的过程，需要你创建一个 Dockerfile 文件然后在里面写上构建镜像所需的一系列动作，而 Cloud Native Buildpacks 则无需配置类似的过程文件，很大程度上减轻了开发者的工作，提高了效率。这还不是最重要的，最重要的是它提供了更高层次的抽象能力，使镜像的分层更加清晰，并且合理有效的利用层缓存，这样一来，当我们对应用程序进行修改之后，再次构建镜像时的速度飞快，比如我们的应用只改了几行代码，那当我们使用Cloud Native Buildpacks 构建镜像时，只需要在应用程序层进行重新构建，其他层使用缓存就可以，也就是只对变化了的层重新构建。总结下Paketo Cloud Native Buildpacks的五大能力：

1. 提供一种简单的方式将源代码转换为安全的容器映像，而不需要开发人员编写和维护dockerfile。
2. 允许构建功能以可重用、上下文独立和透明的方式模块化。
3. 通过最小化重建图像层的数量来优化构建体验。(Dockerfiles也这样做，但CNB的图层顺序并不重要!)
4. 提供一种简单且几乎即时的方法来修补操作系统级漏洞。
5. 通过料清单提供关于容器映像内容的元数据。

接下来我们通过几个场景的动手练习来升入了解Code Engine，首先我们先看看代码引擎的应用程序是什么？

IBM Cloud代码引擎应用程序结合了平台即服务(PaaS)、容器即服务(CaaS)和无服务器部署模型所需的所有特性。如果你有一个容器映像，您可以轻松地将其作为代码引擎上的应用程序运行，以提供直观的用户体验，而无需管理基础设施。你可能会想，“我可以在Kubernetes上运行我的应用程序。”IBM Cloud代码引擎基于Kubernetes作为底层容器编排。由于Kubernetes不是为开发人员本地构建的，它要求你需要考虑许多技术方面，如网络、基础设施和自动伸缩。例如，要在Kubernetes上部署应用程序，需要遵循几个步骤来创建Kubernetes部署、服务和进入负载平衡，并启用自动伸缩。在代码引擎中，运行一个CLI命令，即ibmcloud代码引擎应用程序create—name helloworld—image docker。以正确地设置一切，包括运行容器映像、公开HTTPS端点和设置自动伸缩。而且由于代码引擎是基于Kubernetes的，如果IBM云代码引擎的抽象妨碍到您，高级用户仍然可以使用Kubernetes命令和api，比如kubectl get pods。

大多数自动伸缩技术都是基于CPU和内存监控的，并且没有一种简单的方法可以根据到达应用程序的实际HTTP流量伸缩到零或从零伸缩到零。例如，如果应用程序连接到事件源，则应用程序必须仅在事件发生时运行，因此没有必要一直运行应用程序容器。有了“至零扩展”和“从零扩展”功能，应用程序可以在需要时进行扩展，用户只需按应用程序运行的时间付费。IBM Cloud代码引擎支持基于HTTP请求并发性进行伸缩的应用程序实例。单个应用程序实例处理的请求数量可以由用户配置。

代码引擎为开发人员提供了简化的UI和CLI体验，要创建应用程序，只需提供一个容器图像作为强制输入属性。当然，你还可以提供其他可选属性，包括用于运行应用程序的CPU和内存、作为应用程序输入的环境变量以及用于伸缩的应用程序实例数量范围。可以使用IBM Cloud Shell，创建应用程序的CLI示例如下面3步:

ibmcloud ce project create -n proj-den -t den

ibmcloud ce project select -n proj-den

ibmcloud ce application create --name helloworld --image docker.io/ibmcom/helloworld

应用程序可能在几十秒内完成部署，这取决于您的图像大小。完成后，IBM Cloud Code Engine CLI将返回一个专用URL来访问您的应用程序。URL模式是https://<application-name>.<project-id>.<region>.codeengine.appdomain.cloud。IBM Cloud Code Engine还支持Knative CLI，这意味着您可以像以前一样继续使用Knative CLI。

代码引擎第二个强大的能力就是批处理作业是分配在计算机上运行的程序，无需进一步的用户交互，让让开发人员可以在统一的无服务器平台上运行任何类型的批处理作业，而无需部署、配置、管理或保护任何集群、网络或虚拟机，并且只在批处理作业运行时才需要支付费用。IBM云代码引擎中的批处理作业作为容器运行，这意味着只需要将批处理作业打包为镜像，并将其提交给代码引擎，它将确保批处理作业是隔离的安全性，并保证指定的批处理作业CPU和内存请求。IBM Cloud代码引擎还可以将批处理作业作为作业实例的数组运行，所有实例将并行启动并运行，每个实例将在数组列表中获得唯一的索引值，该实例将一直运行直到完成，代码引擎将监视实例并自动重试失败实例。

使用批处理作业IBM Cloud代码引擎，用户可以轻松且高效地并行运行大规模批处理作业实例，以支持各种类型的工作负载，例如繁重的计算任务、ETL工作负载(例如，转码)、Map and Reduce工作负载、模拟(科学计算)、呈现和任何类型的并行数据处理。

简单的用户体验

与Kubernetes中必须处理复杂YAML文件的作业相比，IBM Cloud代码引擎抽象了两个概念，job和job run，它是为最终用户设计的，可以轻松管理批处理作业。IBM Cloud Code Engine还提供了一个更简单的UI和CLI，指导您如何通过从用户角度提供一些输入参数来创建作业。创建作业后，可以随时提交作业，以启动重复运行的作业。

并行运行多个批处理作业实例

目标支持分布式计算的繁重工作负载，当定义或批处理作业时，您可以指定“数组索引”以并行运行多个实例。例如，用户可以指定从1到10的值，这将导致并行创建并运行10个作业实例，其中每个作业实例获得1到10之间的索引值，作为分区工作负载的环境变量。

要创建批处理作业，只需要提供一个容器映像作为强制输入属性。您还可以提供其他可选属性，如命令和参数、环境变量、CPU和内存，以及数组索引。创建和运行Job，用户也可以直接在UI上方便的操作，也可以执行下面两部CLI命令。

ibmcloud code-engine job create --name batchjob --image docker.io/ibmcom/testjob

ibmcloud code-engine jobrun submit --job batchjob

当然，也可以将这将上面两个步骤集合成一个命令运行，我们可以发现这种方式结合系统Shell，更适合CLI运行复杂的任务。

ibmcloud code-engine jobrun submit --image docker.io/ibmcom/testjob --name batchjobrun

完成后可以简单的看一下执行结果，当然也可以使用IBM LogDNA来看代码引擎的所有日志。 

ibmcloud code-engine jobrun logs --jobrun batchjobrun

用户会问什么时候他们应该使用Jobs, Apps，甚至两者都使用。

应用程序主要是为了运行微服务或web应用程序来响应http请求而设计的。因此，应用程序得到了客户机可以调用的端点(路由)。请求被路由到应用程序实例，并且连接一直保持打开状态，直到将响应发送回客户机。应用程序实例根据它们接收到的http请求的数量向上或向下伸缩。扩展应用程序的标准可以由用户定义，并由某个应用程序实例的并发请求数给出(即，用户可以指定只允许处理10个并发请求)。如果系统中并发请求的数量大于10, 代码引擎将扩展实例的数量以满足用户的标准。应用程序最适合处理低延迟的大量http请求/响应工作负载。应用程序提供了具有更高并发性的同步请求-响应模型。

作业主要用于在给定的输入数据集上运行任务和进程，直到完成。因此，可以启动作业以异步运行。用户可以指定一个索引值列表，Code Engine将为列表中的每个索引启动一个Job任务(即，用户可以指定值1-10，这将导致10个任务，其中每个任务将获得分配的值在1到10之间)。根据分配的索引，任务可以决定要处理什么数据(例如，索引1映射到COS桶上的对象1)。如果Job任务失败，将在给定的时间内重试该任务，直到该任务最终失败。由于作业是异步运行的，所以作业可以运行很长时间。

现在我们已经了解了Jobs和Applications的基本功能，让我们来看看什么时候使用两者(或者两者结合使用)。为了选择正确的技术，了解工作负载的性质及其特征至关重要。

• 你的工作负载需要低延迟还是交互性? 使用Application：如果您的工作负载要求客户端或用户同步等待请求的响应，并且响应必须在几毫秒内可用，那么开发人员应该使用应用程序。原因是应用程序提供了外部可到达的端点，并对请求进行同步响应。这类工作负载的例子包括网站、聊天机器人和移动应用程序。
• 你的计算是轻量级的吗?它需要更少的CPU/内存和I/O吗? 使用应用程序：如果您的工作负载是轻量级的，并且需要较少的CPU/内存和I/O，那么您可以从相同应用程序实例中的并发调用中获益。一个典型的例子是提供CRUD操作并支持NoSQL数据库的API服务器。为了处理请求，数据量可能很小，并且不需要太多内存或CPU周期来处理该数据。有了更高的并发性，应用程序可以处理第一个请求的数据，而第二个请求正在等待I/O。由于CPU和内存需求较低，许多请求可以并发执行。也可以使用Jobs，但由于Jobs以单一并发模式运行，因此开销和相关成本更高。
• 你的计算是否与CPU、内存或I/O绑定? 使用Job和Application：如果需要处理给定数量的数据，其中每个数据块都很大，需要大量CPU和内存，作业通常是更好的选择。但是，如果工作负载需要请求-响应模式，也可以使用应用程序。在这两种情况下，计算任务将以单一并发性运行。为了充分利用为实例配置的资源，每个Application实例或Job任务只能并发处理一个请求或数据块。并行性是通过实例/任务的数量来实现的，由于高资源约束，产生额外任务的开销是可以协商的。一个典型的例子是COS桶上的图像数据处理或机器学习模型的服务。
• 你的计算要花很多时间吗? 使用Job：如果计算持续时间较长，作业是更好的选择，因为它们是异步的。应用程序的最大持续时间总是有限的，因为在规模上维持打开的连接是昂贵的。
  典型的工作负载是机器学习模型的训练或超参数优化。
• 你能预先指定计算的并行度吗? 使用Job：如果您知道需要执行多少计算，则可以使用实例的确切数量运行Job直到完成。典型的例子是神经网络的超参数调整或训练。
• 你的工作负载是否会对某些事件做出反应? 使用Application：如果你的工作需要对事件做出反应，如Git存储库提交推到一个对象上传到一个因为桶,或文档修改在你的数据库,你应该使用应用程序,因为它们提供一个端点,可以配置事件源的事件接收。
• 是否需要在短时间内处理大量数据以响应事件/请求? 使用Application：如果您的工作负载需要对未预料到的请求或事件做出快速响应，应用程序通常是更好的选择，因为应用程序是动态伸缩的。

到此，我们对IBM Cloud代码引擎有了全新的认识，也了解两种部署类型的概念和部署方式。再下一篇文章中，我们来聊聊代码引擎的自动扩展、性能，以及如何跟IBM的服务集成和调用。