Lesson 17-Serverless Technical Foundations

Cloud Service Foundations

1. Differences Between IaaS, PaaS, and FaaS

Layer Relationship Diagram:

User Code
   ↓
FaaS (Functions)
   ↓
PaaS (Runtime Environment)
   ↓
IaaS (Virtual Machines/Containers)
   ↓
Physical Hardware

User Code
   ↓
FaaS (Functions)
   ↓
PaaS (Runtime Environment)
   ↓
IaaS (Virtual Machines/Containers)
   ↓
Physical Hardware

2. Cloud Service Provider Comparison

Selection Recommendations:

• AWS: For the most comprehensive service ecosystem and global coverage
• Azure: For enterprises with existing Microsoft ecosystems (e.g., Active Directory)
• Google Cloud: For scenarios with high data analytics and machine learning needs

3. Relationship Between Serverless and Cloud Computing

Cloud Computing Evolution:

Traditional IT → IaaS → PaaS → FaaS (Serverless)

Traditional IT → IaaS → PaaS → FaaS (Serverless)

Relationship Diagram:

User Application
   ↓
Serverless (FaaS) —— Depends on ——> BaaS (Database/Storage, etc.)
   ↓
PaaS (Runtime Environment) —— Depends on ——> IaaS (Compute Resources)
   ↓
IaaS (Virtual Machines/Containers) —— Runs on ——> Physical Hardware

User Application
   ↓
Serverless (FaaS) —— Depends on ——> BaaS (Database/Storage, etc.)
   ↓
PaaS (Runtime Environment) —— Depends on ——> IaaS (Compute Resources)
   ↓
IaaS (Virtual Machines/Containers) —— Runs on ——> Physical Hardware

Key Distinctions:

• Serverless ≠ No Servers: Still runs on physical servers, but developers don’t manage them
• Serverless is Cloud Computing Evolution: Further abstracts infrastructure, enabling pay-per-use
• Compared to Traditional Cloud Computing:
  • IaaS/PaaS: Requires server/runtime management
  • Serverless: Focus solely on code logic

Complementary Relationship:

• Complex Applications: Combine IaaS/PaaS + Serverless
• Simple Event Handling: Pure Serverless solutions
• Long-Running Tasks: Traditional compute + Serverless supplementation

Function as a Service (FaaS)

1. Definition and Working Principle of FaaS

Definition:
FaaS (Function as a Service) is a serverless computing service that allows developers to upload code functions, which the cloud platform executes automatically when needed and bills accordingly.

Core Characteristics:

1. Event-Driven: Functions triggered by events
2. Stateless: Each execution is independent
3. Automatic Scaling: Scales instances based on request volume
4. Pay-per-Use: Charges based on execution time and invocation count

Workflow:

Event Source → Trigger → FaaS Platform → Execute Function → Return Result

Event Source → Trigger → FaaS Platform → Execute Function → Return Result

Execution Lifecycle:

1. Cold Start Phase:
   • Initialize execution environment
   • Load function code
   • Establish runtime context
2. Execution Phase:
   • Process event input
   • Execute function logic
   • Return result
3. Idle Phase:
   • Retain instance (depending on configuration)
   • Or terminate instance (cost-saving)

2. Event Sources and Triggers

Common Event Sources:

Trigger Configuration Example (AWS Lambda):

{
  "triggers": [
    {
      "type": "s3",
      "bucket": "my-bucket",
      "events": ["s3:ObjectCreated:*"],
      "filter": {
        "prefix": "uploads/",
        "suffix": ".jpg"
      }
    },
    {
      "type": "http",
      "path": "/api/process",
      "method": "POST"
    }
  ]
}

{
  "triggers": [
    {
      "type": "s3",
      "bucket": "my-bucket",
      "events": ["s3:ObjectCreated:*"],
      "filter": {
        "prefix": "uploads/",
        "suffix": ".jpg"
      }
    },
    {
      "type": "http",
      "path": "/api/process",
      "method": "POST"
    }
  ]
}

Event Routing Mechanism:

Event Source → Cloud Platform Event Bus → Trigger Mapping → FaaS Function

Event Source → Cloud Platform Event Bus → Trigger Mapping → FaaS Function

3. FaaS Execution Environment

Execution Environment Characteristics:

1. Isolation: Each function runs in an independent container
2. Ephemeral: Environment may be recycled after execution
3. Stateless: Cannot rely on local storage (except /tmp directory)
4. Resource Limits:
   • Memory: 128MB-10GB (AWS Lambda)
   • Execution Time: 15 minutes (typically)
   • Concurrency: Configurable

Environment Components:

+---------------------+
|      Function Code  |
+---------------------+
|  Runtime (Ruby/     |
|  Python/Node.js)    |
+---------------------+
|  Cloud Platform SDK/API |
+---------------------+
|  Temporary Storage (/tmp) |
+---------------------+
|  Network Interface  |
+---------------------+

+---------------------+
|      Function Code  |
+---------------------+
|  Runtime (Ruby/     |
|  Python/Node.js)    |
+---------------------+
|  Cloud Platform SDK/API |
+---------------------+
|  Temporary Storage (/tmp) |
+---------------------+
|  Network Interface  |
+---------------------+

Cold Start Optimization Techniques:

1. Provisioned Concurrency: Pre-create and maintain active instances
2. Lightweight Runtimes: Use smaller base images
3. Local Caching: Cache frequently used dependencies
4. Pre-Warming: Periodically send test requests

Serverless Ecosystem

1. AWS Lambda Basics

Core Concepts:

1. Function: Basic execution unit
2. Version: Static snapshot of function code
3. Alias: Pointer to a specific version
4. Trigger: Event source mapping
5. Execution Role: IAM permissions

Configuration Example:

# serverless.yml example
service: my-service

provider:
  name: aws
  runtime: nodejs14.x
  region: us-east-1

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

# serverless.yml example
service: my-service

provider:
  name: aws
  runtime: nodejs14.x
  region: us-east-1

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

Performance Optimization Tips:

1. Optimal Memory Setting: Increasing memory also boosts CPU allocation
2. Use ARM Architecture: Reduces costs by ~20%
3. Optimize Dependencies: Eliminate unnecessary libraries
4. Leverage Layers: Share dependencies

Monitoring Tools:

• CloudWatch Metrics
• X-Ray Tracing
• Third-Party Tools (Datadog, New Relic)

2. Azure Functions Basics

Core Concepts:

1. Function App: Collection of functions
2. Consumption Plan: Pay-per-use
3. Premium Plan: Pre-warmed instances
4. Dedicated Plan (App Service Plan): Fixed resources

Language Support:

• C#, F#, VB.NET
• Java, Python, JavaScript
• PowerShell, TypeScript

Configuration Example:

// host.json example
{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true
      }
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[2.*, 3.0.0)"
  }
}

// host.json example
{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true
      }
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[2.*, 3.0.0)"
  }
}

Unique Features:

1. Hybrid Connections: Access on-premises resources
2. Durable Functions: Stateful workflows
3. Event Grid Integration: Complex event handling

Deployment Options:

1. Visual Studio
2. VS Code Extensions
3. Azure DevOps
4. GitHub Actions

3. Google Cloud Functions Basics

Core Concepts:

1. Function: Execution unit
2. Trigger: Event source
3. Memory Allocation: 128MB-8GB
4. Region: Choose regions close to users

Configuration Example:

# cloudbuild.yaml example
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  args: ['gcloud', 'functions', 'deploy', 'helloWorld',
         '--runtime', 'nodejs14',
         '--trigger-http',
         '--allow-unauthenticated']

# cloudbuild.yaml example
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  args: ['gcloud', 'functions', 'deploy', 'helloWorld',
         '--runtime', 'nodejs14',
         '--trigger-http',
         '--allow-unauthenticated']

Performance Characteristics:

1. Fast Cold Start: ~150ms average
2. Native Integration: Deep integration with BigQuery, Pub/Sub, etc.
3. Concurrency Model: Each instance handles one request

Advantageous Scenarios:

1. Data Analytics Pipelines
2. Real-Time Data Processing
3. GCP Ecosystem Applications

Cost Optimization:

1. Use minimal necessary memory configuration
2. Set reasonable concurrency limits
3. Optimize execution time with Cloud Scheduler

Summary and Recommendations

1. Selection Strategy:
   • AWS: For the most comprehensive cloud services and global coverage
   • Azure: For enterprises within the Microsoft ecosystem
   • GCP: For data analytics and machine learning needs
2. Best Practices:
   • Keep functions stateless and idempotent
   • Set reasonable resource limits (memory/timeout)
   • Implement robust error handling and retry mechanisms
   • Utilize cloud platform monitoring tools
3. Development Trends:
   • Lower cold start times
   • Longer execution times (e.g., AWS Lambda extending beyond 15 minutes)
   • Broader runtime support
   • Tighter integration with edge computing
4. Hybrid Architecture Recommendations:
   • Retain traditional architecture for critical workloads
   • Migrate event-driven components to FaaS
   • Use Serverless for data processing pipelines

By selecting the appropriate cloud provider and FaaS product, and adhering to best practices, enterprises can build efficient, resilient, and cost-optimized cloud-native applications. Start with pilot projects to gain experience and iteratively refine architecture design.