Skip to main content

Serverless Architecture Building Blocks

This lesson explores the fundamental building blocks of serverless architectures and how they compose across AWS and GCP.

Simple Explanation​

What it is​

This lesson breaks serverless down into its core pieces: compute, APIs, messaging, data, workflows, and security.

Why we need it​

If you do not understand the building blocks, you cannot combine them reliably into real systems.

Benefits​

  • Clear mental model for designing architectures.
  • Better tradeoff decisions across services.
  • Reusable patterns you can apply to many apps.

Tradeoffs​

  • More choices can feel overwhelming at first.
  • Some services are cloud-specific, which affects portability.

Real-world examples (architecture only)​

  • API request -> Function -> Database -> Response.
  • Event -> Queue -> Worker -> Storage.

API request flow Queue worker flow

Core Building Blocks​

Every serverless application is composed of a small set of primitives that work together:

1. Compute (Functions)​

  • AWS Lambda: Event-triggered, auto-scaling functions; supports Python, Node, Go, Java, C#, Ruby, custom runtimes.
  • Google Cloud Functions: Similar auto-scaling; native Python, Node, Go, Java support; lower minimum cold-start overhead.
  • Trade-offs: Lambda has deeper ecosystem; Cloud Functions has simpler mental model but less ecosystem.
# AWS Lambda handler
def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': f"Hello {event.get('name')}"
    }
# Google Cloud Function
def hello_http(request):
    name = request.args.get('name', 'World')
    return f"Hello {name}"

2. Synchronous API Gateway / Entry Point​

  • AWS API Gateway: REST, WebSocket, HTTP APIs; integrates with Lambda, VPC, credentials.
  • Google Cloud API Gateway: REST APIs; integrates with Cloud Functions, Cloud Run, or external backends.

Decision Matrix:

AspectAWS API GatewayGoogle Cloud API Gateway
Cold-start impact~100ms overhead~50ms overhead
Rate limitingBuilt-in throttlingPolicy-based
AuthenticationIAM, Cognito, Lambda authorizersGoogle Cloud Identity, custom

3. Asynchronous Messaging / Queues​

  • AWS: SQS (pull queue), SNS (pub/sub), Kinesis (stream).
  • Google Cloud: Pub/Sub (unified pub/sub + streaming), Cloud Tasks (work queue).

Example: Async Processing

AWS:

  • Lambda polls SQS queue, processes batches
  • DLQ for failed messages

GCP:

  • Cloud Function triggered by Pub/Sub
  • Automatic retries with exponential backoff

4. Data Storage​

  • AWS: DynamoDB (NoSQL), S3 (object), RDS (SQL, Aurora Serverless).
  • Google Cloud: Firestore (NoSQL), Cloud Storage (object), Cloud SQL (managed SQL).

5. Durable Orchestration & Workflows​

  • AWS Step Functions: Visual workflow builder; integrates with Lambda, SNS, SQS, DynamoDB.
  • Google Cloud Workflows: YAML-based; integrates with Cloud Functions, APIs, services.

6. Authentication & Authorization​

  • AWS: IAM roles for Lambdas, Cognito for app users, API Keys.
  • Google Cloud: IAM for services, Firebase Auth for users, API Keys.

Example: Multi-Cloud Microservice​

Multi-cloud API flow

Key Design Principles​

  1. Decoupling: Use queues/pub-sub; functions should be independent.
  2. Scalability: Serverless scales horizontally; no per-instance cost.
  3. Cost Efficiency: Pay only for execution; design for fault tolerance.
  4. Observability: Log all events; set up error budgets.

When to Combine Blocks​

  • Synchronous workflows: API Gateway → Lambda/CFn → Database
  • Asynchronous workflows: (Data source) → Queue/Pub-Sub → Lambda/CFn → Database
  • Complex workflows: Orchestrator (Step Functions / Workflows) → Multiple Lambdas/Functions

Request-response flow Pull delivery model Orchestration flow

Next Steps​

  • Explore API-driven architectures in Lesson 2.
  • Study event-driven patterns in Lesson 3.
  • Learn orchestration vs choreography in Lesson 6.