knative_Knative可能是您需要的无服务器计算标准

knative

当任何实践变得普遍并且解决问题的许多不同方法都受到人们的欢迎时，标准就必不可少。

这种情况适用于当今的无服务器计算市场。 在平台即服务（PaaS）上下文中，无服务器计算非常适合事件驱动，潜在易变的工作负载，这些工作负载是按需，可伸缩，高效且按使用付费的。 开发人员无需基础架构即可快速部署功能。 他们可以定义触发自动缩放功能的触发器。 他们可以在工作完成后自动关闭功能。

[开发人员指南： 无服务器：AWS，Google Cloud和Microsoft Azure 。 | 然后学习如何使用Microsoft的Azure功能以及如何使用AWS Lambda进行无服务器计算。 ]

无服务器计算的惊人动力

如今，无服务器计算在云原生计算中取得了惊人的发展势头。 正如RightScale的2018年云状态报告中所指出的那样，这种用于构建事件驱动的无状态云应用程序的方法现在是增长最快的微服务模型 ，企业采用率以每年75％的速度扩展。 用于轻量级云功能的无服务器计算的优势引发了商业和开源无服务器平台的激增 。

许多无服务器环境都是公共云的本机。 无服务器计算已经在很大程度上侵入了公共云服务，可以通过采用AWS Lambda ， Azure Functions ， Google Functions ，IBM Cloud Functions，Oracle Functions以及其他商业功能即服务产品来看出。

但是无服务器计算也开始深入渗透私有云。 在过去的几年中，出现了令人眼花range乱的用于内部部署，混合云和多云部署的替代无服务器平台。 其中包括OpenWhisk ， Fission ， Gestalt ， IronFunctions ， Nuclio ， Fn Project ， Funktion ， Fission ， Kubeless ， Funcatron ， OpenFaaS和Webtask.io 。

无服务器平台的激增为早期采用者带来了非常现实的孤立和锁定。 当前，大多数无服务器开发工具都支持针对特定孤岛的构建功能，尤其是AWS的Lambda产品。 但是，越来越多的无服务器IDE（例如HashiCorp的Terraform ，Serverless.com的Serverless Framework和Solo.io的Gloo）与多个主要后端集成，并为各种语言的编程功能提供了抽象，包括Node.js。 ，Python，Java和Go。

混合无服务器多云正在企业应用程序环境中缓慢但肯定地出现。 但是，跨平台无服务器标准的前景充其量仍然是模糊的。 真正的标准是正式的，有文件证明的，开放的规范，它建立统一的实践，并由提供者，用户和其他有关方面组成的社区通过共识性流程进行管理。

可能有一天是无服务器标准

一些行业观察家指出，开源的Knative项目是无服务器标准化的基础，但这将为人们所接受。 Knative项目于去年在Cloud Native Computing Foundation（CNCF）的主持下发布，其目标是简化可在任何云上部署和运行的基于容器的无服务器应用程序的构建。 单独的Project Riff使用开发人员和操作员工具扩展了Knative，以简化其安装并添加关键的用户体验组件。

随着它在商业上的吸引力，Knative有一天可能会启用无服务器功能的多语言“在任何地方运行一次写入”编程，但是这一天仍然遥遥无期。 像CNCF下的许多项目一样 ，Knative要收获真正标准化和广泛采用的成果还有很长的路要走。 我应该指出，CNCF在将Knative纳入旗下之前，已经定义了CloudEvents规范 ，这是一组标准的事件触发器，用于确保无服务器的多云应用程序可移植性和重用性，但仅引起了关注。

Knative当前是0.2版，由Google与IBM的Red Hat部门，Pivotal和SAP合作开发。 Knative前景目前面临的一个明显缺陷是，它尚未使用AWS Lambda等领先的公共无服务器平台的功能，也没有使用针对本地，混合和多云部署的各种无服务器环境的功能。

哪些供应商支持Knative

尽管如此，Knative的每个主要开发人员最近都做出了重大宣布，将其纳入各自的解决方案产品组合：

• 谷歌已于2018年7月通过其Google Kubernetes Engine（GKE）的无服务器附件向用户提供Knative 。 利用Knative，开发人员可以构建，服务和管理基于容器的无服务器应用程序，这些应用程序可以在云提供商之间轻松移动。
• IBM允许企业在其IBM Cloud Kubernetes Service部署中安装Knative。 此外，IBM的Red Hat部门还在其OpenShift Kubernetes平台中增加了对Knative的支持，以帮助客户构建和运行无服务器应用程序，并与基于Istio和Kiali项目的OpenShift Server Mesh集成。
• Pivotal最近宣布了其Pivotal Function Service（PFS）的Alpha版本，PFS是基于Kubernetes的多云无服务器平台。 它是Knative的多云打包，可以安装在任何Kubernetes环境中。 它包括“构建包”，可安全地打包功能，保留功能实例的先前版本以支持透明的回滚，并在松散耦合，流传输和其他分布式环境中无中断地自动执行功能资源扩展和性能优化。
• SAP正在其SAP Cloud Platform中提供Knative，并将其作为Project Kyma的一部分，以实现企业软件的可扩展性。 该项目满足了开发人员对敏捷，开放源代码工具的需求，这些工具可以连接，自定义和扩展任何启用了API的应用程序。 它提供了一致的服务使用层，从而模糊了传统企业软件和各种提供商的云服务之间的界限。 它在标准Kubernetes服务目录上使用Knative，并通过使用Open Service Broker标准对其进行扩展。

Knative还有其他行业支持。 例如，GitLab和TriggerMesh最近发布了GitLab Serverless，它可以通过直接从GitLab UI部署无服务器功能和应用程序，使企业使用Knative在任何云或本地基础结构上运行无服务器工作负载。

什么会减慢Knative的采用速度

尽管Knative拥有大量的支持者和一定的市场吸引力，但一些抵消趋势可能会减慢其在无服务器提供商，开发人员和用户中的采用：

• 云提供商正在发展各自专有的无服务器平台 ：为了吸引更多公共云上的使用，从而减少对异构无服务器的需求（通过Knative和其他接口），每个主要的公共云提供商将继续投资以完善其各自的功能即服务平台。 两家公司将继续发展其无服务器编程语言，在其云IaaS和PaaS产品组合中嵌入无服务器接口，并在其云集成开发环境中增强无服务器API。 例如，AWS最近发布了Firecracker ，这是一个轻量级的开源虚拟机监视器，可在无服务器云中创建和管理安全的多租户容器和AWS Lambda功能。
• 开发工具为桥接孤立的无服务器平台提供了替代的抽象方法 ：后端无服务器代码相当棘手，并将继续编写以有效访问特定于云的服务，例如消息传递和数据库。 已经有几个开源项目（包括Fn Project ， Funktion ， Fission ， Kubeless ， Virtual Kubelets ， Funcatron和OpenFaaS）在Kubernetes，Docker和其他容器调度程序之上提供了无服务器抽象，以促进在孤立集群中使用功能。 这些抽象使企业IT专业人员免于繁琐的任务，即在其企业多云环境中突然出现的无服务器后端之间移植容器化功能。 我期望更多的云原生开发工具将添加使用这些API和其他API的抽象，以支持使用在异构后端无服务器环境中运行的微服务。 这可以免除对开放标准的跨服务器无API的需求，例如Knative。
• 无服务器漏洞需要超出当前标准框架范围的抽象 ：无服务器计算往往使开发人员陷入“视线之外”的思想，在这种思想中，物理和网络安全是云服务提供商的职责。 但是，如最近的一项研究所示，这是一种危险的态度。 对1,000个无服务器应用程序的审核显示，其中20％包含严重的应用程序漏洞。 这些主要是由于不良的开发实践，缺乏无服务器安全性教育以及将不安全的示例代码，API密钥和凭据发布到实际项目中。 随着混合部署的增长，这些漏洞将变得更加严重，除非云原生工具将安全实践强制实施到无服务器开发抽象中。 在Knative或其他行业标准的多云抽象结合强大的防护措施以消除功能代码中的这些漏洞之前，无服务器应用程序开发人员可能会依赖于首选的云原生API中内置的任何专有安全工具。

除了安全性外，还需要将许多其他功能集成到使多云无服务器成为市场现实的任何多云抽象中。 这些包括用于跨云功能并行化，负载平衡，事件关联，数据访问抽象，编排，遥测，性能跟踪，事件关联，使用情况监视，异常检测，日志分析，交互式诊断，事件驱动的警报以及调试。

对于开发人员而言，所有这些工作的底线是，他们需要选择任何可以帮助他们尽可能简单有效地构建和部署无服务器，容器化，虚拟化和其他代码的云原生工具。 如果您的工具集成了用于一次性编写功能代码并将其移植到任何无服务器后端的标准API，那将是您的最佳选择。

翻译自: https://www.infoworld.com/article/3336164/knative-may-be-the-serverless-computing-standard-you-need.html

knative