Building Hybrid Serverless Multi-Cloud Architectures: Patterns and Tooling

This article is based on analysis originally published by SiliconAngle / Wikibon (November 2018). Some product details may have evolved since publication.

Why Hybrid Serverless Architecture Matters

Software teams have long composed solutions by mixing and matching deployment models — combining on-premises infrastructure with public cloud services, or federating multiple Kubernetes clusters across different providers. The same hybridization trend is now reaching serverless computing, also known as Function-as-a-Service (FaaS).

Serverless platforms — such as AWS Lambda, Azure Functions, Google Cloud Functions, and IBM Cloud Functions — abstract away server management entirely, letting developers focus on event-driven business logic. As these platforms mature, engineers increasingly need to span more than one of them within a single application, either for resilience, cost optimisation, capability differences, or regulatory data-residency requirements.

Three Core Hybrid Serverless Patterns

Hybrid serverless architectures generally fall into three categories, each with different levels of complexity and coupling:

1. Multi-Public Function Code Deployment

A client application — such as a mobile app or a web front-end — directly calls the APIs of serverless functions hosted on two or more public clouds. Each cloud handles a workload it is best suited for. For example:

• File-transfer event notifications handled by IBM Cloud Functions (formerly OpenWhisk on Bluemix)
• Batch data processing jobs executed on AWS Lambda
• Real-time stream processing triggered through Microsoft Azure Functions

The client orchestrates calls to each provider independently. This is the simplest pattern to implement but places orchestration responsibility on the consuming application.

2. Multi-Public Function Cross-Invocation

In this pattern, microservices deployed on one serverless cloud directly invoke functions running on another cloud via each provider’s public API. For instance, an AWS Lambda function might call an Azure Function to perform a task that Azure handles more efficiently, and vice versa.

This pattern enables finer-grained capability composition but introduces network latency, cross-cloud authentication complexity, and tighter inter-provider coupling. Robust error handling and retry logic become critical.

3. Hybrid Public/Private Function Deployment and Cross-Invocation

The most complex pattern extends the architecture to include on-premises or private-cloud serverless runtimes — such as Oracle Fn or Red Hat OpenShift Cloud Functions — alongside one or more public FaaS platforms. Functions in each environment invoke each other through APIs.

This approach is well-suited to organisations with strict data-residency or compliance requirements, where certain workloads must remain on-premises while others can run in public clouds for elasticity.

Virtual Kubelet: Bridging Kubernetes and Serverless

Building hybrid serverless applications is significantly easier when developers can work within a unified abstraction layer. The Virtual Kubelet project addresses exactly this need.

In a standard Kubernetes cluster, a kubelet is an agent that runs on every node and manages the lifecycle of workloads scheduled to that node. Virtual Kubelet re-implements this interface as a software component that runs inside a container within a Kubernetes cluster, registers itself as a node, and then delegates workloads to external APIs — including serverless platforms — rather than to physical or virtual machines.

Key characteristics of Virtual Kubelet:

• Pluggable provider model: Any serverless or container platform can implement the Virtual Kubelet provider interface, allowing Kubernetes-scheduled workloads to execute on that platform transparently.
• Standard Kubernetes API surface: Developers and operators continue to use familiar kubectl commands and Kubernetes manifests; Virtual Kubelet handles the translation to provider-specific calls.
• Broad provider support: At the time of writing, providers existed for Alibaba Cloud, AWS (via AWS Fargate), and Microsoft Azure (via Azure Container Instances), among others.

Virtual Kubelet was not yet broadly integrated into mainstream developer toolkits as of 2018. Developers who needed multi-cloud serverless orchestration without it were advised to look at infrastructure-as-code tools such as HashiCorp Terraform or API gateway/service-mesh projects like Gloo, both of which offered hooks into multiple serverless platforms.

Knative: A Kubernetes-Native Serverless Platform

For teams that need a unified platform to develop, deploy, and operate both serverless functions and containerised microservices across heterogeneous clouds, Knative is the most significant open-source initiative in this space.

Developed by Google in collaboration with Pivotal, IBM, Red Hat, and SAP, Knative runs on top of Kubernetes and provides three core capabilities:

• Build: Source-to-container build pipelines (this component has since evolved into the Tekton project).
• Serving: Auto-scaling, traffic splitting, and revision management for serverless workloads, including scale-to-zero.
• Eventing: A broker-and-trigger model for wiring event sources — queues, streams, webhooks — to serverless consumers in a loosely coupled, declarative way.

Knative’s abstraction layer allows the same application code to be deployed across different cloud providers without modification, which is foundational for genuine hybrid and multi-cloud serverless strategies.

Note: Knative was eventually donated to the Cloud Native Computing Foundation (CNCF) in 2022, validating the recommendation made in the original Wikibon analysis.

Practical Guidance for Teams Building Today

If your team is planning hybrid serverless workloads, consider the following approach:

1. Start with a single-provider baseline. Validate your event-driven patterns on one platform before introducing cross-cloud complexity.
2. Use Knative for cross-platform portability. Deploying on Knative — hosted on GKE, OpenShift, or a bare Kubernetes cluster — reduces vendor lock-in and provides consistent eventing primitives.
3. Evaluate Virtual Kubelet for Kubernetes-native teams. If your platform team already manages Kubernetes, Virtual Kubelet lets you burst or delegate workloads to external serverless platforms without changing developer workflows.
4. Adopt infrastructure-as-code from day one. Tools such as Terraform (with provider-specific serverless modules) or Pulumi make multi-cloud function deployments reproducible and auditable.
5. Plan for cross-cloud authentication and secrets management. Each cloud provider has its own IAM model. A central secrets manager (e.g., HashiCorp Vault) reduces the risk of credential sprawl across environments.
6. Instrument for distributed tracing. When functions span providers, OpenTelemetry-compatible tracing is essential for diagnosing latency and failures that cross cloud boundaries.

Looking Ahead

The convergence of Knative’s unified development model with Virtual Kubelet’s pluggable node abstraction points toward a future where the distinction between “serverless” and “containerised” is largely invisible to application developers. Workloads will be scheduled to the most appropriate execution environment — public FaaS, private FaaS, or container runtime — based on policy, cost, and capability, with a common API surface stitching them together.

For DevOps engineers, the implication is clear: the skills needed to operate tomorrow’s multi-cloud systems are being defined today by projects like Knative, Virtual Kubelet, OpenTelemetry, and the CNCF ecosystem at large. Investing in these now — even if your organisation is not yet running hybrid serverless workloads — is the right technical bet.