开发人员通常将解决方案组合成模式，将不同的方法混合到开发、托管和管理应用程序资源中。
任何解决方案模式都可以混合使用，这通常取决于开发人员对抽象层的访问，该抽象层旨在支持感兴趣的复杂应用程序环境。在云计算中，我们越来越多地看到公共云和私有云的混合，以处理事务、分析、集成和其他复杂的工作负载。
在平台即服务层面，我们也在云本地计算混合层面看到了它。它们结合了两个或多个运行在不同云或应用平台上的Kubernet集群。在这些既定的模式中，抽象层由云本地容器化、编排和集成工具包中提供的其他接口组成，例如最近推出的IBM MultiCloud Manager。
然而，在无服务器计算方面，Wikibon在将两个或更多公共或基于前提的功能混合为服务云方面没有取得重大进展。但这种杂交当然是可能的。事实上，它可以在云计算社区的几个行业计划中预见到。事实上，考虑到无服务器计算的开发简单性、运营效率和规模经济性，几乎是不可避免的，作为云本地栈中替代全面容器化和排列、laKubernetes、Docker等类似项目的选择。
比如可以构建一个云本地应用，再调用两个公共无服务器产品的应用编程接口，比如AWSLambda、Azure函数、Google函数或者IBMCloud函数。同样，它甚至可能有更复杂的组合，包括公共无服务器环境和各种基于前提的无服务器环境，如OracleFn和Red HatOpen Shift云功能。
考虑到这一点，无服务器杂交的可能性可以分为三类：
如果开发人员可以在云本地编码工作台中访问这些模式，那么构建混合无服务器应用程序将会更加容易。事实上，这就是虚拟Kuberet规范的起源。这抽象了核心的Kuberneteskubelet函数——一个运行在所有Kubernetes节点上管理工作负载生命周期的代理——以便它可以将编排和容器化的微服务连接到其他API，例如无服务器环境公开的那些API。
在这个抽象中，VirtualKuberlet是一个应用程序，它运行在Kubernetes集群中的一个容器中，将自己伪装成一个节点，并通过KubernetesAPI与外部无服务器和其他可插拔应用程序环境接口。它公开了一个可插入的提供者接口，因此几乎任何无服务器环境都可以被设置为直接调用，并由运行在Kubernetes上的任何容器化微服务调用。目前，VirtualKuberlet抽象了Kubernetes与多家云提供商(包括AlibabaCloud、AmazonWe bServices和tAzure的Micros)的无服务器产品之间的互操作性。
但是，虚拟Kubelet还没有在云开发工具包中得到广泛应用。因此，想要开发两个或更多无服务器云应用的开发人员，应该考虑从以基础设施为代码的power tools中编写和部署作为服务逻辑的函数，例如HashiCorpTerraform或Gloo，它们可以链接到不同的无服务器云平台。
在寻找工具来监控、管理和保护混合无服务器环境时，云管理员应该探索开源Knative项目。Knative由谷歌与Pivotal、IBM、Red Hatand SAP合作开发，是一个基于Kubernetes的平台，用于驱动DevOps工作流，围绕统一开发无服务器和容器化的应用，从而跨异构公有云和私有云平台进行部署。
展望未来，Wikibon预计Knative将与VirtualKublets一起催化更多样化和复杂的无服务器和容器化云本地应用的混合。我们敦促Knative社区将该项目提交给云原生计算基金会，以便将其开发为未来云计算架构的核心组件。
