Debug Serverless Applications Locally with End‑Cloud Tunneling

Background

Serverless has become a hot paradigm because it removes the need to manage infrastructure; developers only upload code packages or container images and receive elastic, highly‑available services. However, real‑world adoption reveals several debugging pain points, such as difficulty migrating existing SpringBoot, Flask, or ThinkPHP apps, testing micro‑service interactions locally, and reproducing long event‑driven chains.

Why Debugging Is Hard

Custom Runtime/Container functions need to access cloud services (databases, service registries) during startup, making failure diagnosis opaque.

Micro‑service architectures require end‑to‑end testing after local development.

Event‑driven functions involve multiple triggers and long chains that are hard to reproduce locally.

Industry reports (e.g., Hackernoon Serverless Report) identify debugging as the biggest obstacle for Serverless adoption. Existing solutions rely on local environment simulation or log‑only remote debugging, which cannot fully emulate the cloud runtime.

End‑to‑Cloud Tunneling (端云联调)

The Serverless Devs "端云联调" feature creates a secure tunnel that merges the local development machine with the cloud VPC, allowing seamless traffic flow in both directions. This enables developers to start a local instance that can directly access cloud resources (e.g., RDS, Kafka) without changing configuration.

How It Works

Based on the s.yaml VPC configuration, a helper Service/Function is created and a single instance is reserved to act as a proxy.

A local proxy container is launched, establishing a bidirectional TCP tunnel with the helper function.

The developer’s custom runtime container (e.g., a SpringBoot app) shares the network with the proxy, gaining internal VPC access.

Once the local container is running, developers can invoke it via s proxied invoke or curl the custom domain; traffic is routed through the proxy back to the local instance, enabling breakpoint debugging in the local IDE.

Enabling the Tunnel

From the directory containing s.yaml, run: s proxied setup This command creates the proxy service, starts the tunnel, and launches the local function container.

Disabling the Tunnel

After debugging, clean up resources to avoid charges:

Press CTRL + C in the terminal where the tunnel was started.

Or run s proxied cleanup from another terminal in the same directory.

Both methods safely terminate the proxy instance; if the local machine loses network connectivity, the session closes automatically.

Practical Scenario

A real enterprise uses Alibaba Cloud Function Compute with a SpringBoot service that must call downstream VPC resources such as a service registry, RDS, and Kafka. By executing s proxied setup, the local SpringBoot instance can access these resources via their internal addresses without any configuration changes.

When the frontend function (e.g., frontend.abc.com) is invoked, traffic is routed to the local SpringBoot instance, allowing developers to see live logs and perform breakpoint debugging on requests originating from the cloud.

If the local instance fails to start, developers can immediately see whether VPC whitelist issues or misconfigured Nacos cause the failure, because the startup process mirrors the cloud environment.

Comparison with Pure Local Debugging

The following table (originally an image) contrasts traditional local debugging with End‑to‑Cloud tunneling: