Kubernetes近来受到高度关注,且已经成为容器领域的主要抽象方案。考虑到Kubernetes强大的容器调度能力,及其为基础设施自动化带来的坚实基础,这一切自然是在情理之中。
不过我们注意到,开发团队在使用普通Kubernetes进行应用程序部署时,往往会遇到困难。推送容器本身虽然无甚挑战,但如果大家希望利用其推送应用程序代码——或者函数,那么单凭Kubernetes自身就不太够用了。
正因为如此,才会有大量供应商围绕Kubernetes推出层级更高的抽象技术,Knative[1]应运而生。
函数,您需要关注的下一个抽象概念
这对开发人员而言,无疑是个极具吸引力的主张。为什么?因为将一切基础设施与事件处理流程抽象出来(直到其触发函数为止)意味着开发人员能够完全专注于自己的功能性代码——是的,再没有任何其它事务会分散他们的精力。
当然,世界上没有免费的午餐。那么,函数的复杂性又体现在哪里?
目前市面上存在着大量函数即服务选项。而对每款产品而言,其在触发函数的具体方法、可以处理的事件格式、扩展能力以及帮助开发人员抽象出的实际复杂度数量方面皆有所区别。
对于具备实用性的抽象,公有云供应商往往会将其打包为一项服务。其中包括Azure Functions(微软)、Lambda(AWS)以及Google Cloud Functions等等。每种服务都运行函数代码以唾液事件,并根据当前需求进行扩展。此类产品采用务实的计费方式——用户需要按照函数的具体调用次数付费。
开源开发人员也投身于无服务器阵营,并开发出OpenFaaS、Fission、Kubeless以及Project riff等项目。这一切都是函数即服务的典型例子,且建立在Kubernetes基础之上。但各项目之间的共通之处也就仅此而已。
各个项目在以下三大核心领域都有着略有区别的实现方式:
不过我们注意到,开发团队在使用普通Kubernetes进行应用程序部署时,往往会遇到困难。推送容器本身虽然无甚挑战,但如果大家希望利用其推送应用程序代码——或者函数,那么单凭Kubernetes自身就不太够用了。
正因为如此,才会有大量供应商围绕Kubernetes推出层级更高的抽象技术,Knative[1]应运而生。
函数,您需要关注的下一个抽象概念
这对开发人员而言,无疑是个极具吸引力的主张。为什么?因为将一切基础设施与事件处理流程抽象出来(直到其触发函数为止)意味着开发人员能够完全专注于自己的功能性代码——是的,再没有任何其它事务会分散他们的精力。
当然,世界上没有免费的午餐。那么,函数的复杂性又体现在哪里?
目前市面上存在着大量函数即服务选项。而对每款产品而言,其在触发函数的具体方法、可以处理的事件格式、扩展能力以及帮助开发人员抽象出的实际复杂度数量方面皆有所区别。
对于具备实用性的抽象,公有云供应商往往会将其打包为一项服务。其中包括Azure Functions(微软)、Lambda(AWS)以及Google Cloud Functions等等。每种服务都运行函数代码以唾液事件,并根据当前需求进行扩展。此类产品采用务实的计费方式——用户需要按照函数的具体调用次数付费。
开源开发人员也投身于无服务器阵营,并开发出OpenFaaS、Fission、Kubeless以及Project riff等项目。这一切都是函数即服务的典型例子,且建立在Kubernetes基础之上。但各项目之间的共通之处也就仅此而已。
各个项目在以下三大核心领域都有着略有区别的实现方式:
各项目都拥有一种构建服务,或者利用函数代码构建并部署容器的方法。
各项目都拥有一种实现扩展伸缩以响应对函数调用需求的方法。
各项目都提供一种基