Deploy Multi-Language Serverless Functions

Architecture Overview

This architecture deploys three Cloud Functions, each using a different programming language runtime, into the same Google Cloud project. All three functions share a common infrastructure pattern: source code is packaged as a ZIP archive, uploaded to a Cloud Storage bucket, and deployed as an HTTP-triggered function. The key difference between them is the runtime and entry point configuration.

This approach demonstrates a practical advantage of serverless platforms: you can mix and match languages within the same project without running separate infrastructure per language. A Python function for data processing, a Go function for a high-performance API, and a TypeScript function for a webhook handler can all coexist, each managed as a Pulumi resource in the same stack.

All three functions receive public HTTPS endpoints through Google’s managed infrastructure. Each function scales independently based on its own traffic, so a spike in requests to the Python function does not affect the Go or TypeScript functions. This independence extends to deployments: you can update one function without redeploying the others.

Function Code Packaging

Each function’s source code lives in its own local directory. The deployment packages each directory as a ZIP archive and uploads it to a shared Cloud Storage bucket. Cloud Functions pulls the ZIP from storage during deployment and extracts it into the function’s execution environment.

The storage bucket acts as an artifact repository for all function versions. Each upload creates a new object, and you can reference previous versions for rollback if needed. The bucket can be configured with lifecycle policies to clean up old archives automatically.

Runtime Configuration

Each function specifies its runtime (Python, Go, or TypeScript/Node.js) and its entry point. The entry point is the function name that Cloud Functions invokes when a request arrives. Python and TypeScript use lowercase convention (handler), while Go uses an exported function name (Handler).

The runtime determines which language-specific dependencies are available. Python functions can use pip packages specified in requirements.txt, Go functions use go.mod, and TypeScript functions use package.json. Cloud Functions installs dependencies during deployment.

HTTP Triggers and Public Access

Each function is configured with an HTTP trigger, which provides a dedicated HTTPS endpoint managed by Google. IAM bindings grant the cloudfunctions.invoker role to allUsers, making the endpoints publicly accessible without authentication. For production deployments, you would typically restrict this to authenticated callers or specific service accounts.

The trigger URLs are stable across deployments. Updating a function’s code or configuration does not change its endpoint, which makes it safe to share URLs with external systems or embed them in client applications.

Common Customizations

• Restrict public access: Remove the allUsers IAM binding and require authentication through Google identity tokens or API keys for production functions.
• Add environment variables: Pass configuration like API keys, database connection strings, or feature flags as environment variables instead of hardcoding them in function code.
• Increase memory and timeout: Adjust memory allocation and execution timeout per function based on workload requirements. Data processing functions may need more memory, while API functions prioritize low latency.
• Connect to other GCP services: Grant each function a service account with specific IAM roles to access Cloud SQL, Firestore, Pub/Sub, or other services as needed.