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 Case | Example |
|---|---|
| API backends | REST API built with API Gateway + Lambda |
| Event processing | Process every S3 upload, SQS message, or DynamoDB change |
| Scheduled tasks | Nightly reports, data cleanup, cron jobs |
| CI/CD automation | Trigger deployments, send notifications, run checks |
| Data transformation | ETL pipelines processing streaming data |
| Webhooks | Receive 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-bucketServerless Trade-offs
| Advantages | Limitations |
|---|---|
| Zero server management | Cold starts add latency (first invocation delay) |
| Infinite auto-scaling | Execution time limits (15 min on Lambda) |
| Pay only for use | Vendor lock-in |
| No idle costs | Stateless — persistent state requires external storage |
| Fast to deploy | Harder 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-databasePlatform Engineering Tools
| Tool | Purpose |
|---|---|
| Backstage | Developer portal and service catalog |
| Crossplane | Provision cloud resources from Kubernetes using CRDs |
| Port | Developer portal with built-in scorecards and self-service |
| Humanitec | Dynamic configuration management for application environments |
| Score | Workload specification standard for platform-agnostic deployment |
| Argo CD / Flux | GitOps 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.
