Develop Serverless Functions with Google Cloud Functions 2nd Gen

Imagine your e-commerce site processing 10,000 webhooks from a payment gateway daily. A dedicated server sits idle 90% of the time, and peak load during sales hours crushes the infrastructure. Cloud Functions 2nd gen solves this: you pay only for actual invocations, and scaling happens automatically. Functions start within 100 ms and can handle up to 1000 concurrent requests per instance.

We are a team with 5+ years of GCP experience, having delivered 20+ serverless solutions for e-commerce, fintech, and media. We are Google certified, use event-driven architecture, and fully managed services. We guarantee stability under any load.

A typical scenario: an online store on WooCommerce processes webhooks from Stripe. A dedicated server sits idle, while peak rates increase. Cloud Functions starts within 100 ms, processes the request, and releases resources. Infrastructure budget savings reach 70%, and the solution pays for itself within the first few months.

What problems do we solve?

Business faces three typical challenges:

• Auto-scaling. Traditional servers cannot keep up with spikes. Cloud Functions scales from 0 to 1000 instances in seconds. Stripe webhook processing: function starts in 100 ms, executes, and stops.
• Cost. You pay only for execution time and number of invocations. Up to 70% savings compared to a dedicated server running 24/7.
• Integration with the GCP ecosystem. Seamless connection with Pub/Sub, Cloud SQL, Secret Manager, Cloud Build, BigQuery. No need to set up additional infrastructure.

How we do it: a real case

Recently for a fintech startup, we implemented Stripe webhook handling with HMAC signature verification, publishing to Pub/Sub, and writing to BigQuery. The function is written in Python, deployed via Cloud Build, monitored via Cloud Logging. The system handles 5000 requests per minute without a single failure. The entire architecture was done in 5 days. As stated in the official Google Cloud documentation, 2nd gen supports up to 1000 concurrent requests.

Stack: Node.js 20, Python 3.12, Go 1.21, TypeScript, Secret Manager, Cloud SQL, VPC Connector.

1st Gen vs 2nd Gen

2nd gen functions use Cloud Run under the hood. This provides: concurrency up to 1000 requests per instance (vs 1 in 1st gen), support for VPC Connector, larger memory limit (32 GB), custom domains without proxying.

Why choose Google Cloud Functions 2nd gen?

First, 2nd gen is 10 times faster than 1st gen in throughput due to multithreading. Second, it supports event-driven architecture: Pub/Sub, Cloud Storage, Firestore, BigQuery. Third, security: all functions run inside a VPC with access to Cloud SQL, Memorystore, and other services via internal IPs.

How to integrate Cloud Functions with Pub/Sub?

Create a subscriber function that triggers when a message is published to a topic. This is an asynchronous model: invocation is decoupled from processing. Python example:

@functions_framework.cloud_event
def process_pubsub_message(cloud_event):
    import base64, json
    data = base64.b64decode(cloud_event.data["message"]["data"]).decode("utf-8")
    event = json.loads(data)
    handle_event(event)

Example function: webhook handler in Python

import functions_framework, json, hmac, hashlib
from google.cloud import pubsub_v1

publisher = pubsub_v1.PublisherClient()
TOPIC_PATH = "projects/my-project/topics/webhook-events"

@functions_framework.http
def process_webhook(request):
    signature = request.headers.get("X-Signature-256", "")
    secret = get_secret("webhook-secret")
    expected = "sha256=" + hmac.new(secret.encode(), request.data, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(signature, expected):
        return json.dumps({"error": "Invalid signature"}), 401
    event = request.get_json()
    publisher.publish(TOPIC_PATH, json.dumps(event).encode("utf-8"))
    return json.dumps({"received": True}), 200

Deploy and environment

# Node.js
gcloud functions deploy contact-form --gen2 --runtime nodejs20 --region europe-west1 --source . --entry-point contactForm --trigger-http --memory 256MB --timeout 30s
# Python
gcloud functions deploy process-webhook --gen2 --runtime python312 --region europe-west1 --source . --entry-point process_webhook --trigger-http --memory 512MB

Connecting to Cloud SQL

import sqlalchemy

def create_engine():
    return sqlalchemy.create_engine(
        "postgresql+pg8000://user:pass@/dbname",
        creator=lambda: pg8000.connect(
            user="user", password="pass", database="dbname",
            unix_sock="/cloudsql/project:region:instance/.s.PGSQL.5432"
        )
    )

CI/CD via Cloud Build

# cloudbuild.yaml
steps:
  - name: node:20
    entrypoint: npm
    args: [install]
  - name: node:20
    entrypoint: npm
    args: [run, build]
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk
    args:
      - gcloud
      - functions
      - deploy
      - contact-form
      - --gen2
      - --region=europe-west1
      - --source=.
      - --runtime=nodejs20
      - --entry-point=contactForm
      - --trigger-http

How to secure serverless functions?

Use Secret Manager for keys and passwords, verify incoming webhook signatures (HMAC), configure IAM roles with least privilege, enable VPC Connector for traffic isolation. For DDoS protection, use Cloud Armor. More details in Cloud Functions documentation.

What's included

Process

1. Requirements audit — analyze load, usage scenarios, select triggers (HTTP, Pub/Sub, Cloud Storage).
2. Design — develop architecture: functions, topics, queues, databases.
3. Development — write code, cover with tests, set up CI/CD.
4. Testing — load testing (k6), security check, fault tolerance.
5. Deployment — deploy to production, set up monitoring and alerts.
6. Documentation and training — transfer knowledge to your team.

Timeline and pricing

• Basic HTTP function (webhook reception, signature verification, response) — from 3 business days.
• Function with Pub/Sub and Cloud SQL — from 1 week.
• Complex solution (multiple functions, CI/CD, BigQuery integration) — up to 3 weeks.

Pricing is determined individually after a consultation. We will assess your project for free and suggest the optimal solution. Average project budget starts from a few hundred thousand rubles.

We guarantee 99.9% uptime and prompt incident resolution. Experience: 5+ years in GCP, certified engineers, real fintech and e-commerce cases.

Contact us — we will help you select the serverless solution for your needs. Get a consultation today.

Why Serverless Development? The Real Economics and Technical Trade-offs

Serverless does not mean "without servers". Servers exist—you just don't manage them. It's more accurate to think of it as "without server management": no OS patching, no nginx configuration, no disk space monitoring. The function receives an event, processes it, and returns a response. The provider decides where to run it. Мы занимаемся serverless-архитектурой более 5 лет и реализовали 30+ проектов на AWS Lambda, Vercel Functions и Cloudflare Workers. Гарантируем, что ваша система масштабируется без переплат — при условии правильного выбора платформы и оптимизации холодного старта.

Cold start — Lambda's main pain point on Node.js. In VPC, cold start reached 10 seconds before recent improvements. For production functions with latency requirements: Provisioned Concurrency (keeps instances warm), SnapStart for Java, minimize bundle via tree-shaking. Our typical optimization reduces cold start from 3.2s to 400ms.

Practical case: an image processing function (resize, WebP conversion, upload to S3). Bundle with sharp was 40MB due to native binaries. Solution: Lambda Layer with sharp, main function 800KB. Cold start dropped from 3.2s to 400ms. Lambda Layers — shared dependencies between functions. Up to 5 layers per function, each up to 250MB. Standard practice: layer with heavy dependencies (sharp, puppeteer, ffmpeg), layer with common business logic. Infrastructure for Lambda via AWS CDK or Terraform. SAM — for beginners, CDK — for serious projects with type safety.

Edge Runtime is fundamentally different: the function runs on a V8 isolate in the nearest Vercel CDN point (120+ regions). No cold start as such — the isolate starts in ~0ms. But strict limitations: no Node.js API (fs, crypto via Web API), no database access via TCP (only via HTTP API), bundle size up to 4MB. Edge Runtime is ideal for: middleware (auth check, redirect, A/B test), response transformations, geolocation logic, Edge Config. Not suitable for: accessing PostgreSQL, heavy computations, file system operations.

Cloudflare Workers run on V8 isolates in 300+ points of presence. Latency for the user is literally the nearest data center. Cold start < 1ms. Workers Durable Objects solve the state problem at the edge: each Durable Object is a single coordination point, running in one region. Ideal for: game rooms, real-time documents, rate limiting without races. Workers KV — eventually consistent storage. Writes propagate to all regions in ~60 seconds. Not suitable for financial transactions, suitable for configs, feature flags, cache. D1 — SQLite on the edge. Works great on a single read replica, write latency depends on distance to primary region. Not ideal for global write-heavy applications.

Ecosystem: Hono.js — a minimalist router that works on Workers, Deno, Bun, Node.js. Good choice if you need unified code for edge and server.

Vendor lock-in — a real problem. Lambda-specific code (handler signature, Lambda context) is hard to port. Hono.js, Remix, or adapters like @hono/node-server help keep logic portable. Мы проектируем абстракции, позволяющие сменить провайдера с минимальными изменениями.

How We Optimize Cold Start in AWS Lambda?

Cold start is Lambda's worst enemy. Here’s a step‑by‑step optimisation checklist we apply:

1. Minimise bundle size — tree‑shake dependencies, use Lambda Layers for native binaries (sharp, puppeteer). Target < 1MB.
2. Enable Provisioned Concurrency for latency‑critical functions — costs extra but cuts cold start to near zero.
3. Use SnapStart for Java (Lambda) — reduces init time by 90%+.
4. Avoid VPC unless necessary — if you need VPC, use AWS PrivateLink or Elastic Network Interface optimisation.
5. Warm‑up strategies — scheduler pinging function every 5 minutes (but only for low‑volume functions, otherwise Provisioned Concurrency cheaper).

Result: our clients typically see cold start drop from 2–4s to under 500ms. For a fintech API handling 50k requests/day, that means 3 fewer seconds of latency per request during peak scale.

When Does Serverless Not Fit? Cost Comparison

Serverless saves money when traffic is unpredictable or sparse — up to 70% reduction compared to dedicated servers. But it becomes expensive under constant high load. Example: a function processing 1 million requests/day at 300ms each costs about $100–200/month on Lambda. Equivalent EC2 instance might cost $50/month. For such steady workloads, Fargate or EC2 is cheaper.

Long computations (>15 min on Lambda, >30s on Vercel) require Fargate or a regular server. WebSocket server with state — no persistent process. Tasks with frequent disk access — ephemeral storage, /tmp on Lambda 512MB–10GB.

What’s Included in Serverless Development Service?

Мы предлагаем serverless-разработку под ключ. В каждый проект входит:

• Архитектурная документация (схема event‑driven потоков, выбор платформы, justification).
• Реализация функций с unit‑ и integration‑тестами.
• CI/CD pipeline (GitHub Actions / GitLab CI) с preview‑деплоями.
• Infrastructure as Code (Terraform / AWS CDK / Pulumi).
• Мониторинг и observability (OpenTelemetry, structured logging, distributed tracing).
• 30‑дневная пост‑релизная поддержка и оптимизация производительности.

Typical Mistakes in Serverless Development and How We Avoid Them

• Ignoring cold start — we measure and budget for it from day one.
• Over‑engineering state — many teams try to use Workers Durable Objects for simple caching; KV is often enough.
• No distributed tracing — without trace IDs across SQS › Lambda › DynamoDB streams, debugging is blind. We integrate AWS X‑Ray or OpenTelemetry automatically.
• Underestimating cost at scale — we simulate load patterns and compare serverless vs. container costs before committing.

Закажите serverless архитектуру под ключ — свяжитесь с нами для бесплатной оценки вашего проекта. Сроки: от 2 недель для MVP, до 10 недель для миграции монолита. Стоимость рассчитывается индивидуально, ориентировочно от $2,000 до $15,000 в зависимости от сложности.