DevOps Serverless and Platform Engineering

Serverless computing and platform engineering represent two distinct but complementary evolutions in how DevOps teams build and operate software. Serverless removes the need to think about servers entirely for certain workloads. Platform engineering builds internal developer platforms that make the rest of the developer experience — including cloud, containers, and CI/CD — simple and self-service.

Part 1: Serverless Computing

Serverless does not mean there are no servers. It means developers do not manage servers. The cloud provider handles provisioning, scaling, patching, and availability automatically. Teams deploy code (or configuration) and the provider runs it on demand.

Key Characteristics of Serverless

  • No server management: No OS to patch, no infrastructure to provision.
  • Auto-scaling: Scales from zero to millions of requests and back automatically.
  • Pay-per-use: Charges are based on actual executions, not idle running time.
  • Event-driven: Functions execute in response to events — HTTP requests, queue messages, file uploads, database changes.

AWS Lambda – The Leading FaaS Platform

AWS Lambda runs functions in response to events. Each function is a small, single-purpose unit of code. Lambda supports Python, Node.js, Java, Go, and more.

Simple Lambda Function (Python)

import json
import boto3

def lambda_handler(event, context):
    # This function resizes an image uploaded to S3

    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']

    print(f"Processing file: {key} from bucket: {bucket}")

    # Process the image...
    result = process_image(bucket, key)

    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': 'Image processed successfully',
            'output_key': result
        })
    }

This function triggers automatically whenever a file is uploaded to an S3 bucket. No server runs idle waiting — Lambda wakes up, executes, and stops.

Common Serverless Use Cases

Use CaseExample
API backendsREST API built with API Gateway + Lambda
Event processingProcess every S3 upload, SQS message, or DynamoDB change
Scheduled tasksNightly reports, data cleanup, cron jobs
CI/CD automationTrigger deployments, send notifications, run checks
Data transformationETL pipelines processing streaming data
WebhooksReceive and process GitHub or Stripe webhooks

Serverless Framework and AWS SAM

The Serverless Framework and AWS SAM (Serverless Application Model) provide a developer-friendly way to define, test, and deploy serverless applications as code.

# serverless.yml
service: image-processor

provider:
  name: aws
  runtime: python3.11
  region: us-east-1

functions:
  processImage:
    handler: handler.lambda_handler
    timeout: 30
    memorySize: 512
    events:
      - s3:
          bucket: my-upload-bucket
          event: s3:ObjectCreated:*
          rules:
            - suffix: .jpg
    environment:
      OUTPUT_BUCKET: my-processed-bucket

Serverless Trade-offs

AdvantagesLimitations
Zero server managementCold starts add latency (first invocation delay)
Infinite auto-scalingExecution time limits (15 min on Lambda)
Pay only for useVendor lock-in
No idle costsStateless — persistent state requires external storage
Fast to deployHarder to debug and test locally

Part 2: Platform Engineering

Platform engineering is the discipline of building and maintaining an Internal Developer Platform (IDP) — a self-service layer on top of cloud, Kubernetes, CI/CD, and DevOps tools. The goal is to reduce developer cognitive load so product engineers can build and deploy applications without becoming Kubernetes or cloud experts.

The Problem Platform Engineering Solves

As organizations grow, each development team independently manages its own CI/CD pipelines, Kubernetes clusters, monitoring, secrets, and cloud resources. This creates:

  • Inconsistent practices and security configurations across teams.
  • Massive duplication — 10 teams write 10 nearly identical pipelines.
  • Developer time wasted on infrastructure instead of product features.
  • New teams spending weeks setting up their environment before writing a line of product code.

Platform engineering creates a shared, curated platform that teams use instead. Developers interact with a simple, opinionated interface. The platform team handles the complexity underneath.

What an Internal Developer Platform Includes

  • Self-service environment provisioning: Developers request a new environment from a portal or CLI — it appears in minutes, fully configured.
  • Golden paths: Pre-built, approved templates for creating new services that include CI/CD, monitoring, security scanning, and logging by default.
  • Service catalog: A browsable catalog of available infrastructure (databases, caches, queues) that developers provision without writing cloud configuration.
  • Developer portal: A centralized UI showing all services, their owners, documentation, deployment history, and health.
  • Standardized CI/CD: Reusable pipeline templates maintained by the platform team — developers call them instead of building from scratch.

Backstage – The Developer Portal Standard

Backstage is an open-source developer portal created by Spotify and donated to the CNCF. It provides a unified interface for all developer tools and services. Teams register their services in Backstage's Software Catalog with a simple YAML file:

# catalog-info.yaml in the service's repository
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles all payment processing
  tags:
    - java
    - payments
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: checkout-system
  dependsOn:
    - component:stripe-integration
    - resource:payments-database

Platform Engineering Tools

ToolPurpose
BackstageDeveloper portal and service catalog
CrossplaneProvision cloud resources from Kubernetes using CRDs
PortDeveloper portal with built-in scorecards and self-service
HumanitecDynamic configuration management for application environments
ScoreWorkload specification standard for platform-agnostic deployment
Argo CD / FluxGitOps deployment engine for the platform

The Golden Path

A golden path is a pre-built, opinionated, fully-featured template for creating a new service. A typical golden path includes:

  • Service scaffolding (repository structure, README, CODEOWNERS)
  • Dockerfile with best-practice multi-stage build
  • CI/CD pipeline (GitHub Actions or GitLab CI) with tests, scanning, and deployment
  • Kubernetes manifests pre-configured for dev/staging/production
  • Monitoring configured (Prometheus metrics endpoint, default dashboards)
  • Logging configured (structured JSON output to central EFK stack)
  • Security scanning (Trivy, Snyk) already integrated
  • Service registered in Backstage catalog automatically

A developer runs a single command — platform new-service --name payment-gateway --type rest-api — and receives a fully operational, production-ready service structure in minutes.

Summary

  • Serverless removes infrastructure management for event-driven, short-lived workloads — teams deploy code, not servers.
  • AWS Lambda is the leading FaaS platform — functions execute on demand, scale automatically, and charge per invocation.
  • Serverless trade-offs include cold starts, execution time limits, and vendor lock-in.
  • Platform engineering builds Internal Developer Platforms that abstract cloud and DevOps complexity behind self-service interfaces.
  • Golden paths give developers opinionated, production-ready service templates — CI/CD, monitoring, security, and deployment included by default.
  • Backstage provides a unified developer portal for the software catalog, documentation, and tooling discovery.

Leave a Comment