Cloud & Infrastructure

Cloud Platforms

Cloud computing has fundamentally shifted how organizations provision, manage, and scale infrastructure. Rather than investing millions in physical data centers with 3-5 year hardware refresh cycles, enterprises now consume computing resources on demand — paying only for what they use while gaining access to services that would take years to build internally. In 2026, global cloud spending exceeds $830 billion, with the three hyperscalers — AWS, Microsoft Azure, and Google Cloud Platform — commanding over 65% of the market.

Multi-Cloud Strategy

Most large enterprises adopt a multi-cloud approach — using two or more cloud providers strategically. This isn't about avoiding vendor lock-in (a common misconception) but about leveraging each provider's unique strengths:

• AWS: Broadest service catalog (200+ services), mature ecosystem, strongest in compute/storage/networking, dominant in startups and digital-native companies
• Microsoft Azure: Enterprise integration (Active Directory, Microsoft 365, Dynamics), hybrid cloud leadership (Azure Arc), strongest in regulated industries and government
• Google Cloud: Data analytics and AI/ML leadership (BigQuery, Vertex AI), Kubernetes originator (GKE), strongest in data-intensive workloads and open-source alignment

Platform Comparison

Cloud Architecture

Cloud-native architecture fundamentally differs from traditional enterprise application design. Instead of monolithic applications running on dedicated servers, cloud-native systems decompose into small, independently deployable services connected through APIs and event streams — enabling teams to build, test, and release features independently at high velocity.

flowchart TD
    LB[Load Balancer / API Gateway] --> MS1[Microservice A
User Service]
    LB --> MS2[Microservice B
Order Service]
    LB --> MS3[Microservice C
Payment Service]
    MS1 --> DB1[(User DB
PostgreSQL)]
    MS2 --> DB2[(Order DB
MongoDB)]
    MS3 --> DB3[(Payment DB
DynamoDB)]
    MS1 --> MQ[Message Queue
Kafka / SQS]
    MS2 --> MQ
    MS3 --> MQ
    MQ --> EH[Event Handler
Serverless Functions]
    EH --> NOTIFY[Notification Service]
    EH --> ANALYTICS[Analytics Pipeline]
    MS1 --> CACHE[Redis Cache]
    MS2 --> CACHE
                            

Serverless Computing

Serverless computing represents the highest level of cloud abstraction — developers write functions that execute in response to events without managing any infrastructure. The cloud provider handles provisioning, scaling, patching, and availability. Serverless follows a pure pay-per-execution model: zero cost when idle, automatic scaling to millions of concurrent executions during peak loads.

• Functions as a Service (FaaS): AWS Lambda, Azure Functions, Google Cloud Functions — event-triggered code execution with sub-second billing granularity
• Serverless containers: AWS Fargate, Azure Container Apps, Google Cloud Run — containerized workloads without cluster management
• Serverless databases: Aurora Serverless, Cosmos DB serverless, Firestore — auto-scaling storage with per-request pricing
• Event-driven patterns: API Gateway triggers, queue processors, scheduled tasks, file upload handlers, stream processors

Containers & Kubernetes

Containers package applications with all dependencies into lightweight, portable units that run identically across environments. Kubernetes orchestrates thousands of containers — handling scheduling, scaling, networking, and self-healing automatically. Together, they form the backbone of modern cloud infrastructure:

# Docker Compose for a multi-service application
# docker-compose.yml

cat <<'EOF'
version: "3.9"
services:
  # API Gateway
  gateway:
    image: envoyproxy/envoy:v1.28
    ports:
      - "8080:8080"
      - "9901:9901"
    volumes:
      - ./envoy.yaml:/etc/envoy/envoy.yaml
    depends_on:
      - user-service
      - order-service

  # User Microservice
  user-service:
    build: ./services/user
    environment:
      - DATABASE_URL=postgresql://postgres:secret@user-db:5432/users
      - REDIS_URL=redis://cache:6379
      - KAFKA_BROKERS=kafka:9092
    depends_on:
      - user-db
      - cache
      - kafka

  # Order Microservice
  order-service:
    build: ./services/order
    environment:
      - MONGODB_URI=mongodb://order-db:27017/orders
      - KAFKA_BROKERS=kafka:9092
    depends_on:
      - order-db
      - kafka

  # Databases
  user-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: users
      POSTGRES_PASSWORD: secret
    volumes:
      - user-data:/var/lib/postgresql/data

  order-db:
    image: mongo:7
    volumes:
      - order-data:/data/db

  # Infrastructure
  cache:
    image: redis:7-alpine

  kafka:
    image: confluentinc/cp-kafka:7.5.0
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092

  zookeeper:
    image: confluentinc/cp-zookeeper:7.5.0
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181

volumes:
  user-data:
  order-data:
EOF

DevOps & CI/CD

DevOps unifies software development (Dev) and IT operations (Ops) into a continuous delivery model where code changes flow from commit to production in minutes rather than months. The CI/CD pipeline automates building, testing, security scanning, and deployment — eliminating manual handoffs, reducing human error, and enabling teams to deploy hundreds of times per day with confidence.

flowchart LR
    DEV[Developer
Commits Code] --> PR[Pull Request
Code Review]
    PR --> CI[CI Pipeline]
    CI --> BUILD[Build &
Unit Tests]
    BUILD --> SAST[Security Scan
SAST/SCA]
    SAST --> INT[Integration
Tests]
    INT --> STAGE[Deploy to
Staging]
    STAGE --> E2E[E2E Tests &
Performance]
    E2E --> APPROVE{Gate:
Approval}
    APPROVE -->|Auto| PROD[Deploy to
Production]
    APPROVE -->|Manual| REVIEW[Manual
Review]
    REVIEW --> PROD
    PROD --> MONITOR[Monitor &
Observe]
    MONITOR -->|Rollback| STAGE
                            

Deployment Pipelines

Modern deployment pipelines implement progressive delivery — gradually rolling out changes to increasing portions of users while monitoring for errors. Key deployment strategies include:

• Blue-green deployment: Two identical production environments; traffic switches instantly from "blue" (current) to "green" (new) — enabling instant rollback
• Canary releases: Route 1-5% of traffic to the new version, monitor error rates and latency, then gradually increase if healthy
• Feature flags: Deploy code to production disabled, enable features for specific users/segments without redeployment
• Rolling updates: Replace instances one at a time in a cluster — no downtime, gradual transition

# GitHub Actions CI/CD Pipeline
# .github/workflows/deploy.yml

name: Build, Test & Deploy

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install pytest pytest-cov

      - name: Run unit tests
        run: pytest tests/ --cov=src --cov-report=xml

      - name: Upload coverage
        uses: codecov/codecov-action@v4
        with:
          file: coverage.xml

  security-scan:
    runs-on: ubuntu-latest
    needs: test
    steps:
      - uses: actions/checkout@v4

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: fs
          severity: CRITICAL,HIGH

      - name: Run SAST with Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten

  build-and-push:
    runs-on: ubuntu-latest
    needs: [test, security-scan]
    if: github.event_name == 'push'
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

  deploy-staging:
    runs-on: ubuntu-latest
    needs: build-and-push
    environment: staging
    steps:
      - name: Deploy to staging
        run: |
          kubectl set image deployment/app \
            app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=staging

      - name: Run E2E tests
        run: npm run test:e2e -- --base-url=$STAGING_URL

  deploy-production:
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production
    steps:
      - name: Canary deployment (10%)
        run: |
          kubectl set image deployment/app-canary \
            app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=production

      - name: Monitor canary (5 minutes)
        run: |
          sleep 300
          ERROR_RATE=$(curl -s "$PROMETHEUS_URL/api/v1/query?query=rate(http_errors_total[5m])")
          if [ "$(echo $ERROR_RATE | jq '.data.result[0].value[1]')" \> "0.01" ]; then
            echo "Error rate too high, rolling back"
            exit 1
          fi

      - name: Full rollout
        run: |
          kubectl set image deployment/app \
            app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }} \
            --namespace=production

GitOps

GitOps extends DevOps by using Git as the single source of truth for both application code and infrastructure state. Tools like ArgoCD and Flux continuously reconcile the desired state declared in Git with the actual state in the cluster — automatically detecting and correcting drift:

Infrastructure as Code

Infrastructure as Code (IaC) treats infrastructure provisioning as a software engineering discipline — infrastructure is defined in declarative configuration files, version-controlled, peer-reviewed, tested, and deployed through automated pipelines. This eliminates "snowflake servers," enables reproducible environments, and makes infrastructure changes auditable and reversible.

// Terraform - Multi-environment Azure infrastructure
// main.tf

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.85"
    }
  }
  backend "azurerm" {
    resource_group_name  = "terraform-state-rg"
    storage_account_name = "tfstateaccount"
    container_name       = "tfstate"
    key                  = "production.terraform.tfstate"
  }
}

provider "azurerm" {
  features {}
}

# Resource Group
resource "azurerm_resource_group" "main" {
  name     = "${var.project}-${var.environment}-rg"
  location = var.location
  tags     = local.common_tags
}

# Virtual Network with subnets
resource "azurerm_virtual_network" "main" {
  name                = "${var.project}-${var.environment}-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
}

resource "azurerm_subnet" "app" {
  name                 = "app-subnet"
  resource_group_name  = azurerm_resource_group.main.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.1.0/24"]
  delegation {
    name = "app-service-delegation"
    service_delegation {
      name = "Microsoft.Web/serverFarms"
    }
  }
}

# Azure Kubernetes Service
resource "azurerm_kubernetes_cluster" "main" {
  name                = "${var.project}-${var.environment}-aks"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "${var.project}-${var.environment}"
  kubernetes_version  = "1.29"

  default_node_pool {
    name                = "system"
    node_count          = var.node_count
    vm_size             = var.node_size
    vnet_subnet_id      = azurerm_subnet.app.id
    enable_auto_scaling = true
    min_count           = 2
    max_count           = 10
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "calico"
  }

  tags = local.common_tags
}

# Azure Container Registry
resource "azurerm_container_registry" "main" {
  name                = "${var.project}${var.environment}acr"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  sku                 = "Premium"
  admin_enabled       = false

  georeplications {
    location = "westeurope"
  }
}

# Outputs
output "kube_config" {
  value     = azurerm_kubernetes_cluster.main.kube_config_raw
  sensitive = true
}

output "acr_login_server" {
  value = azurerm_container_registry.main.login_server
}

Bicep & CloudFormation

While Terraform is cloud-agnostic, each provider offers native IaC tools optimized for their ecosystems: Azure Bicep provides a clean DSL with first-class Azure integration, while AWS CloudFormation offers tight coupling with the AWS service catalog. The choice depends on your multi-cloud strategy — Terraform for multi-cloud, native tools for single-cloud optimization.

IaC Best Practices

Cloud Economics

Cloud spending without governance grows 30-40% faster than planned. FinOps (Financial Operations) is the practice of bringing financial accountability to cloud spending — combining engineering, finance, and business teams to make informed trade-offs between speed, cost, and quality. The FinOps Foundation identifies three phases: Inform (visibility), Optimize (efficiency), and Operate (governance).

Cost Optimization Strategies

• Right-sizing: Match instance sizes to actual utilization — most VMs run at <20% CPU average, indicating over-provisioning by 2-5x
• Reserved instances / Savings Plans: Commit to 1-3 year usage for 40-72% discounts on steady-state workloads
• Spot/Preemptible instances: Use 60-90% discounted capacity for fault-tolerant batch workloads (data processing, CI/CD, rendering)
• Auto-scaling: Scale horizontally based on demand — add capacity during peaks, remove during troughs
• Storage tiering: Automatically move data from hot (SSD) → cool → archive tiers based on access frequency
• Serverless for variable loads: Pay-per-request eliminates idle capacity costs for spiky workloads

Conclusion

Cloud infrastructure is the enablement layer that makes every other digital transformation initiative possible. Without scalable, elastic, well-governed cloud foundations, AI models can't train on massive datasets, customer experiences can't scale globally, and development teams can't iterate at the speed modern markets demand. The key principles to internalize:

• Cloud-native over lift-and-shift: Redesign applications to leverage managed services, event-driven patterns, and auto-scaling — don't just move VMs to the cloud
• Everything as Code: Infrastructure, policies, security controls, and operational runbooks — all version-controlled, reviewed, and deployed through pipelines
• Platform engineering: Build internal developer platforms that abstract cloud complexity — developers ship features, not configure infrastructure
• FinOps from day one: Cloud cost visibility, accountability, and optimization are cultural practices, not one-time projects
• Security embedded, not bolted-on: Shift-left security into CI/CD pipelines with automated scanning, policy enforcement, and compliant-by-default templates