Elective Introduction to Cloud Computing

Introduction to Cloud ComputingUnit 412 min read

Cloud Programming Models: APIs, Serverless, Containers & Workflows

Unit 4 of Introduction to Cloud Computing explores how developers interact with cloud services through programming models—REST APIs, serverless architectures, containerization (Docker/Kubernetes), and cloud workflow orchestration—with real-world examples from Nepali apps like eSewa and global platforms like AWS Lambda.

Core Concepts and Definitions

What is a Cloud Programming Model?

A cloud programming model defines how developers write, deploy, and manage applications in the cloud. Unlike traditional on-premise software, cloud models abstract infrastructure details (servers, storage, networking) and expose them via standardized interfaces.

Key Idea:

DeveloperWrites CodeCloud Programming ModelAbstracts InfrastructureCloud InfrastructureServers/Storage/Networking
How cloud models abstract infrastructure for developers (simplified)

Why Cloud Models Matter

  • Abstraction: Hide complexity (e.g., no need to manage VMs in serverless).
  • Scalability: Auto-scale resources (e.g., WhatsApp’s message queues).
  • Cost Efficiency: Pay-per-use (e.g., Ncell’s AWS bill for SMS APIs).

1. RESTful APIs: The Backbone of Cloud Communication

How REST Works

REST (Representational State Transfer) is an architectural style for designing networked applications. Cloud services expose APIs (e.g., /users/{id}) to interact with data/resources.

REST Constraints (Key Rules):

  1. Stateless: Each request contains all needed info (no server-side session storage).
  2. Resource-Based: URLs represent resources (e.g., GET /orders/123).
  3. HTTP Methods: GET, POST, PUT, DELETE map to CRUD operations.
  4. Representation: Data exchanged in formats like JSON/XML.

Example: eSewa API

sequenceDiagram
    participant User as Mobile App
    participant API as eSewa REST API
    participant DB as Database
    User->>API: POST /payments (JSON: {amount: 500, to: "12345678"})
    API->>DB: Insert payment record
    DB-->>API: Return transaction_id
    API-->>User: 200 OK (JSON: {status: "success", id: "txn_abc123"})

Worked Example: Fetching NEPSE Stock Data Assume NEPSE’s API endpoint: GET https://api.nepse.com/stocks/{symbol}?token={API_KEY}

  • Request: GET /stocks/NEPSE?token=abc123
  • Response (JSON):
    {
      "symbol": "NEPSE",
      "price": 2100.50,
      "timestamp": "2024-05-20T14:30:00Z"
    }
    

Visual:

08162431Method8 bitsPath24 bitsHeaders16 bitsStatus8 bitsBody16 bits
HTTP request/response structure for NEPSE stock API call

Advantages/Disadvantages:

Pros Cons
Language-agnostic (works with JS, Python, etc.) Latency if API is far from user
Scalable (handled by cloud load balancers) Rate limits (e.g., 1000 calls/day)
Caching support (reduces load) Security risks (e.g., leaked API keys)

Real World:

  • eSewa: Uses REST APIs for mobile payments (e.g., POST /payments to process transactions).
  • Google Maps API: GET /maps/api/geocode to convert addresses to coordinates.
  • Khalti: POST /api/v2/payment for online merchant payments.

2. Serverless Computing: No Servers, No Worries

UserAPI GatewayLambda FunctionDynamoDBS3
Typical serverless application architecture

Definition

Serverless is a cloud model where developers deploy code (functions) without managing servers. The cloud provider (AWS Lambda, Google Cloud Functions) handles scaling, patching, and infrastructure.

How It Works:

  1. Trigger: HTTP request, database change, or schedule.
  2. Execution: Code runs in an isolated environment.
  3. Billing: Pay only for execution time (e.g., $0.00001667 per GB-second in AWS).

Example: Pathao’s Ride Request Handler

sequenceDiagram
    participant User as Mobile App
    participant Lambda as AWS Lambda (ride_request)
    participant DB as DynamoDB
    participant Map as Google Maps API
    User->>Lambda: POST /ride (JSON: {pickup: "KTM", destination: "Lalitpur"})
    Lambda->>DB: Store request
    Lambda->>Map: GET /directions
    Map-->>Lambda: Route data
    Lambda->>User: 200 OK (ride_id: "ride_789")

Worked Example: NTC’s Traffic Violation Fine Calculator Assume a Lambda function calculate_fine triggered by a database update:

def lambda_handler(event, context):
    violation = event["violation_type"]  # e.g., "speeding"
    fine = {
        "speeding": 5000,
        "red_light": 2000,
        "parking": 1000
    }
    return {"fine": fine[violation], "status": "calculated"}

Input:

{"violation_type": "speeding"}

Output:

{"fine": 5000, "status": "calculated"}

Advantages/Disadvantages:

Pros Cons
No server management Cold starts (delay on first use)
Auto-scaling (handles 1000s of requests) Limited execution time (15 mins max)
Pay-per-use (cost-effective for sporadic workloads) Vendor lock-in (AWS Lambda vs. Azure Functions)

Real World:

  • WhatsApp: Uses serverless for media processing (e.g., resizing images on upload).
  • YouTube: Serverless functions handle video transcoding triggers.
  • Ncell: Uses AWS Lambda to process SMS API requests (e.g., send_sms function).

3. Containers: Docker and Kubernetes

Why Containers?

Containers package an app and its dependencies (libraries, config files) into a portable unit. Unlike VMs, they share the host OS kernel, making them lightweight and fast.

Container vs. VM:

Docker Workflow:

  1. Dockerfile: Defines the container’s environment (e.g., FROM python:3.9, COPY app.py .).
  2. Build: docker build -t myapp .
  3. Run: docker run -p 4000:80 myapp
  4. Deploy: Push to Docker Hub or a private registry.

Example: Daraz’s Order Processing Container

FROM python:3.8-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "order_processor.py"]

Order Processor Code (order_processor.py):

from flask import Flask, request
app = Flask(__name__)

@app.route('/process_order', methods=['POST'])
def process_order():
    data = request.json
    # Logic to update inventory, send confirmation email
    return {"status": "order processed", "order_id": data["id"]}

Kubernetes (K8s): Orchestrating Containers K8s automates deployment, scaling, and management of containerized apps. Key components:

  • Pod: Smallest deployable unit (1+ containers).
  • Service: Exposes pods internally/externally.
  • Deployment: Manages pod replicas and updates.

Real World:

  • Google: Uses Kubernetes to run ~2 billion containers/week.
  • Nepal Rastra Bank: Deploys containers for secure financial transaction processing.
  • Pathao: Kubernetes manages driver-app communication pods.

Advantages/Disadvantages:

Pros Cons
Consistent environments (dev = prod) Steep learning curve (YAML configs)
Fast scaling (seconds to minutes) Complexity in multi-container apps
Resource-efficient (vs. VMs) Security risks (container escapes)

4. Cloud Workflow Orchestration

Step 1Trigger(Event/Schedule)Step 2Execute Task 1Step 3Parallel TasksStep 4Execute Task NStep 5Complete Workflow
Workflow execution pattern with parallel processing

What is a Workflow?

A workflow is a sequence of tasks (steps) executed in order or parallel. Cloud platforms (AWS Step Functions, Azure Logic Apps) orchestrate these workflows.

Example: Khalti’s Payment Workflow

stateDiagram-v2
    [*] --> InitiatePayment: User requests payment
    InitiatePayment --> ValidateUser: Check credentials
    ValidateUser --> CheckBalance: Verify account balance
    CheckBalance --> DeductAmount: Subtract from balance
    DeductAmount --> NotifyBank: Trigger interbank transfer
    NotifyBank --> UpdateDB: Mark payment as "completed"
    UpdateDB --> SendReceipt: Email/SMS confirmation
    SendReceipt --> [*]

Worked Example: NTC’s Traffic Fine Workflow

  1. Trigger: Camera detects violation → POST /violations to Step Function.
  2. Steps:
    • Step 1: calculate_fine (Lambda) → Determines fine amount.
    • Step 2: send_notice (Lambda) → Emails owner.
    • Step 3: update_ledger (DynamoDB) → Records fine.
  3. Output: Workflow completes with {"status": "fine_issued", "amount": 5000}.

Real World:

  • YouTube: Workflow for video upload → encoding → CDN distribution.
  • eSewa: Payment → KYC verification → Disbursement workflow.
  • Ncell: SMS API → Rate limiting → Billing workflow.

Advantages/Disadvantages:

Pros Cons
Error handling (retries, dead-letter queues) Complexity in long workflows
Visual debugging (flow charts) Vendor-specific syntax (e.g., AWS States Language)
Microservices integration Cost for high-frequency workflows

In the Real World

  1. eSewa:

    • Model Used: REST APIs + Serverless (AWS Lambda for payment processing).
    • How: Mobile app calls POST /payments → Lambda validates → updates DB → sends SMS receipt.
    • Impact: Handles 10,000+ transactions/minute during festivals.
  2. Pathao:

    • Model Used: Containers (Docker) + Kubernetes for driver-app coordination.
    • How: Each driver runs a container with real-time location updates; K8s scales pods during peak hours (e.g., 7–9 PM).
    • Impact: 99.9% uptime during Dashain/Teej.
  3. Nepal Rastra Bank (NRB):

    • Model Used: Workflow orchestration (AWS Step Functions) for loan approvals.
    • How: submit_loan → credit_check (Lambda) → approval_workflow (human + auto steps) → disburse_funds.
    • Impact: Reduced loan processing time from 15 days to 2 hours.

Exam Tip

What to Expect in TU/PU Exams

  1. Definitions:

    • Expect 2–3 marks for defining REST, serverless, or containers. Use bullet points for clarity.
    • Example:

      "Serverless computing is a cloud execution model where the provider dynamically manages infrastructure, charging only for compute time consumed by individual function executions."

  2. Diagrams:

    • Draw sequence diagrams for API calls (e.g., eSewa payment flow).
    • Draw state diagrams for workflows (e.g., Khalti’s payment states).
    • Label all components (e.g., "User," "Lambda," "DynamoDB").
  3. Code Snippets:

    • Write a Dockerfile or Lambda function in Python/JavaScript. Focus on key lines:
      FROM python:3.8
      COPY app.py .
      CMD ["python", "app.py"]
      
    • For APIs, show a request/response pair with headers and JSON.
  4. Comparisons:

    • Compare VMs vs. Containers or REST vs. SOAP in a table. Highlight 2–3 key differences.
    • Example:
      Feature REST SOAP
      Protocol HTTP/HTTPS HTTP, SMTP, etc.
      Data Format JSON/XML (flexible) XML only
      State Stateless Can be stateful
  5. Scenario-Based Questions:

    • Example Question:

      "Design a serverless architecture for a Daraz order processing system. Include triggers, functions, and data stores."

    • Answer Structure:
      1. Trigger: POST /orders (HTTP API Gateway).
      2. Functions:
        • validate_order (Lambda) → Checks stock.
        • process_payment (Lambda) → Calls Khalti API.
      3. Data Stores: DynamoDB for orders, S3 for receipts.
      4. Workflow: Step Function to orchestrate steps.
  6. Short Answer:

    • For 5-mark questions, list 3 advantages and 2 disadvantages of a model (e.g., containers).
    • For 10-mark questions, explain how a real system (e.g., eSewa) uses the model with a diagram.
  7. True/False:

    • Common pitfalls:
      • ❌ "Serverless means no code." → False (you still write code).
      • ✅ "REST APIs are stateless." → True.

Based on the TU BSc CSIT syllabus for Introduction to Cloud Computing, unit 4.

Discussion

Loading…