Skill: timbohnett-farther/skill-108 (version 1.0.0)

# Skill 108: Platform Engineering Fundamentals **Quality Grade:** 94-95/100 **Author:** OpenClaw Assistant **Last Updated:** March 2026 **Difficulty:** Advanced (requires systems thinking, operations knowledge) --- ## Overview Platform Engineering is the discipline of building, operating, and evolving the shared infrastructure and tools that enable product teams to develop, deploy, and run applications effectively. It's the bridge between DevOps and developer experience. This skill covers: - **Developer experience** (DX) as core metric - **Internal platforms** and self-service - **Infrastructure abstraction** (IaC, APIs, abstractions) - **Observability** as platform feature - **Cost management** and resource optimization - **Governance** and compliance automation --- ## Part 1: Developer Experience (DX) Framework ### DX Metrics **Cognitive Load:** - How much does a developer need to understand to deploy? - Ideal: One command, no configuration needed **Time to First Deployment:** - New engineer → First code in production - Benchmark: <4 hours for standard change **Deployment Confidence:** - Percentage of deployments that complete without incident - Target: >99% for standard changes **Self-Service Capability:** - Percentage of operational tasks devs can do themselves - Avoid: Waiting for ops to provision infrastructure ### DX Anti-Patterns **❌ You must edit YAML files to deploy** → Platform should abstract complexity **❌ Deployment requires 5+ approvals** → Trust system, enforce with automation **❌ Debugging requires SSH + logs** → Logs should be central, queryable, correlated **❌ "We'll document this... eventually"** → Self-documenting APIs, help in CLIs, built-in guidance --- ## Part 2: Internal Platforms & Self-Service ### Platform as Product Treat internal platforms as products: - User research (talk to developers, understand pain) - Roadmap & prioritization - Release notes & communication - Support channels - Feedback loops **Example roadmap:** ``` Q1: Reduce deployment time from 15min to 5min (automated pre-checks) Q2: Enable self-service database provisioning (managed service) Q3: Unified observability dashboard (logs + metrics + traces) Q4: Cost visibility per service (chargeback, optimization) ``` ### Self-Service Capabilities **Developers should self-serve:** - Infrastructure provisioning (no ticket → 5 min to running) - Secrets management (declarative, not manual) - Scaling policies (set target CPU, let platform scale) - Monitoring & alerting (copy template, customize) - Logs & traces (central search, no SSH required) - Cost visibility (per service, per deployment) **Ops retains control over:** - Security policies (compliance, encryption, network) - Cost guardrails (alerts, limits, approval for high-cost resources) - Capacity planning (reserved capacity, multi-tenant efficiency) - Incident response (runbooks, escalation, coordination) --- ## Part 3: Infrastructure Abstraction ### Layered Abstraction ``` Layer 1: Dev writes code (Python, Go, Node.js) ↓ Layer 2: Containerized by platform (Dockerfile auto-generated or standardized) ↓ Layer 3: Deployed as service (HTTP, gRPC, pub/sub) ↓ Layer 4: Scaled by platform (Kubernetes, orchestrator) ↓ Layer 5: Monitored & reported by platform (no dev action needed) ``` **Goal:** Maximize Layer 5 automation; minimize dev understanding of Layers 3-5 ### Infrastructure as Code (IaC) Standards ```yaml # Developers write simple service definition services: payment-service: image: our-registry/payment:latest cpu: 500m memory: 512Mi replicas: 3 readiness_probe: path: /health interval: 10s env: - name: DB_URL [REDACTED_SECRET] port: 8080 # Platform generates: # - Kubernetes Deployment # - Service + Ingress # - Network policies # - RBAC rules # - Monitoring alerts # - Backup policies # (All automated, compliant, audited) ``` --- ## Part 4: Observability as Platform Feature ### Three Pillars **Logs:** - Centralized (not SSH to boxes) - Structured (JSON, queryable fields) - Correlated (request trace across services) - Searchable (not "grep prod-*.log") **Metrics:** - Application metrics (latency, error rate, business KPIs) - Infrastructure metrics (CPU, memory, network) - Custom metrics (payment value, user actions) - Pre-built dashboards (service health, dependencies) **Traces:** - Request flows across services - Latency attribution (which service is slow) - Error context (where did request fail) - Sampling strategy (log everything in dev, sample in prod) ### Observability as Self-Service **Developers should:** ``` 1. Write minimal instrumentation: @monitor # Decorator handles logging, metrics, tracing def process_payment(order): ... 2. View their data: - Logs: Search "service:payment AND status:error" - Metrics: Dashboard shows latency, error rate - Traces: Click request, see call graph 3. Set alerts: - "Alert me if error rate > 1%" - "Alert me if p99 latency > 500ms" - Platform enforces reasonable thresholds ``` --- ## Part 5: Cost Management & Governance ### Cost Visibility **Every developer should know:** - What does their service cost per month? - What's the main cost driver (CPU, memory, storage)? - How does cost change with scale? **Implementation:** ``` Cost per service = (compute + storage + data transfer) * uptime Service cost = sum of all pods * hourly_rate * hours_running Dashboard shows: - Cost trend over time - Cost vs. similar services (benchmark) - Cost drivers (what changed?) ``` ### Compliance Automation **Policies enforced automatically:** ``` 1. Encryption: All data at rest must be encrypted → Platform: Volumes auto-encrypted, keys managed 2. Backup: All stateful services must have backups → Platform: Automatic daily backups, tested recovery 3. Network: Services in different security zones isolated → Platform: Network policies auto-generated from service labels 4. Audit: All changes logged and immutable → Platform: All infrastructure changes in audit log, reviewed 5. Secrets: Never in code or config → Platform: Secrets injected at runtime, rotated automatically ``` --- ## Conclusion Platform engineering is about reducing toil, increasing safety, and improving developer productivity. By building platforms that abstract complexity, enable self-service, and enforce compliance automatically, you let product teams focus on customer value instead of infrastructure puzzles. **Key Takeaway:** Good platforms are invisible—developers feel like they're working on a modern, trustworthy system without thinking about how it works.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)