Skip to main content
Welcome. This lesson continues the fundamentals of platform engineering by focusing on DevOps practices that are essential for building and operating a platform that scales. Agenda
  • The Three Ways of DevOps: flow, feedback, and experimentation
  • Key SRE principles: reduction of toil, incident management, SLOs/SLIs, observability
  • Building a collaborative platform culture
  • How infrastructure teams transform into platform product teams
A presentation slide titled "Agenda" with a blue gradient panel on the left and four colorful numbered markers down the middle. The right side lists agenda items about DevOps, SRE principles, collaborative platform culture, and transforming infrastructure teams into product teams.
Why platform engineering and DevOps belong together Platform engineering does not replace DevOps — it amplifies and operationalizes it across the company. A successful platform product embeds developer ergonomics, SRE targets, and automation so teams can safely move faster. Four key connections between platform engineering and DevOps:
  • Shared mission across teams — align on developer experience and reliability goals.
  • Break down silos — enable cross-functional collaboration (dev, ops, QA, security).
  • Scale through automation — treat repetitive work as code and automate it.
  • Drive self-service success — enable internal consumers to do more without asking.
At Sparkle Pony Ranch, the platform team combines complementary skills:
  • Swati: deep DevOps and CI/CD automation
  • Alan: infrastructure and IaC (infrastructure-as-code)
  • Phuong: developer workflows and cloud-native platform integration
An infographic titled "Platform Engineering Built on DevOps Foundations" showing four colored pillars—Shared Mission, Internal Enablement, Scale Through Automation, and Self‑Service Success—each with an icon and brief description. The slide is branded © KodeKloud.
Platform teams succeed when they treat the platform as a product: define key user journeys, instrument reliability targets, and continuously measure developer experience.
Three Ways of DevOps — foundation for platform design The “Three Ways” (from The Phoenix Project) are practical principles to embed in platform architecture: Flow, Feedback, and Continuous Experimentation.
  1. First Way — Flow
  • Goal: optimize frictionless workflows from code to production.
  • Approach: automate verification, CI/CD, and promote continuous delivery so commits move rapidly through build, test, and deployment.
Typical flow: developer commits → CI builds the artifact → a GitOps operator (e.g., Argo CD) applies manifests → production in minutes.
A slide titled "First Way – Flow" that visually shows a four-step CI/CD pipeline. The steps are: Developer commits code → GitHub Actions builds → ArgoCD deploys → Production in minutes, each shown in blue chevrons with simple icons.
Infrastructure automation follows the same pattern: changes to IaC (for example, Terraform) should trigger plan, tests/validation, peer review, and safe promotion to production-like environments with verification gates.
  1. Second Way — Feedback
  • Goal: provide rapid, continuous feedback at every stage of the delivery pipeline.
  • Approach: shorten the time from change to verification and notification so engineers quickly know success or failure and can iterate.
Fast feedback helps teams detect regressions early, rely on observability, and maintain production readiness.
An infographic titled "Second Way – Feedback" showing a three-step flow: 1) Code pushed, 2) Tests fail, and 3) Developer notified in 30 seconds.
  1. Third Way — Continuous Learning and Experimentation
  • Goal: create a culture of experimentation and learning from failures.
  • Approach: run blameless postmortems, capture root causes, and harden the platform to reduce repeat incidents.
Platform teams should convert incidents into product improvements so platform reliability and developer productivity both increase.
A slide titled "Third Way – Continuous Learning" showing three colored avatar icons labeled Swati, Alan, and Phuong and a tag "Sparkle Pony Ranch." In the center is a computer warning labeled "Outage occurs" with two steps: "1. Team investigates root cause" and "2. Platform is improved for all."
Key operating practices derived from the Three Ways
  • Defer irreversible decisions: only commit to provider-specific or heavyweight capabilities when they solve a real need.
  • Amplify feedback loops: instrument and automate checks so verification is fast and reliable.
  • Work in small batches: keep changes small and frequent to reduce risk and simplify rollbacks.
A presentation slide titled "Three Key Principles Applied to Platform Engineering" with three colored boxes: "Make Decisions Late," "Amplify Feedback Loops," and "Work in Small Batches." Each box has a short note: enable flexible architectures for pivoting; shorten time from change to validation; and use incremental changes to reduce risk.
Concrete role examples (Sparkle Pony Ranch)
  • Alan: builds declarative, reusable Terraform modules to provision cloud infrastructure.
  • Swati: automates CI/CD tests and reliability checks, integrating quick feedback into pipelines.
  • Phuong: delivers small feature increments to developer-facing tools (for example, a developer portal like Backstage) through frequent, well-scoped pull requests.
A presentation slide titled "Three Key Principles Applied to Platform Engineering" showing three colorful avatar icons labeled Swati, Alan, and Phuong with short role descriptions (Swati: automates testing and monitoring; Alan: creates reusable Terraform templates for AWS and Azure; Phuong: works in small batches with clear pull requests). A "Sparkle Pony Ranch" tag and KodeKloud copyright appear on the slide.
Outcomes: faster validation, smaller blast radius These practices create a platform that is reliable, evolves quickly, and enables developers to ship with confidence: smaller changes, faster reviews, easier rollbacks, and reduced blast radius. Short feedback cycles let teams validate in minutes rather than days.
A presentation slide titled "Minutes, Not Days – Accelerated Learning" showing a left column of user avatars and names (Sparkle Pony Ranch, Swati, Alan, Phuong) and a right-side illustration of a computer screen with "Feedback" and "Pull Request" buttons.
Flexible architecture and parameterized templates Parameterized IaC templates let you delay irreversible decisions and simplify migration planning. For example, reusable Terraform modules capture services, configurations, and constraints in code so you can reason about architecture and map requirements to another provider later. Note that provider-specific APIs will require adaptation during a cloud migration.
A presentation slide titled "Flexible Architecture – Delaying Irreversible Decisions" showing a user avatar labeled "Alan" linked to "Parameterized Templates." Below are three blue icons illustrating a flow: "Built for AWS" → "Requirements change" → "Seamless migration to Azure."
Site Reliability Engineering (SRE) fundamentals Embed SRE practices directly into the platform so reliability becomes measurable and actionable: Sparkle Pony Ranch sets SLOs for CI/CD throughput and platform availability; when an SLO is breached, the team treats incidents as product gaps and iterates.
A presentation slide titled "Site Reliability Engineering – Built Into the Platform" showing an SLO target of 99.5% and a note that the GitOps operator syncs within 60 seconds. It also lists key SRE practices (SLOs, error budgets, observability, blameless culture) and observability pillars (metrics, logs, traces).
SLOs are tools, not targets to game. Use them to guide trade-offs between velocity and stability, and adjust error budgets responsibly to protect users and developer productivity.
Culture and organizational practices Tools are necessary, but culture determines success. Platform engineering benefits from:
  • Shared ownership — developers, operators, QA, DBAs, and architects collaborate on platform outcomes.
  • Developer rotation through platform on-call — increases empathy for running services in production.
  • Peer reviews and automation — senior engineers maintain quality through design reviews and automated checks.
  • Adoption through collaboration — demonstrate value and enable teams rather than enforce usage.
A presentation slide titled "Culture Beats Tools – Building Platform Teams" with three colored icons and a segmented bar. It highlights three practices: Shared Ownership, Developer Rotation, and Peer Reviews.
Summary — practical checklist
  • Design for flow: automate CI/CD and GitOps for repeatable deployments.
  • Build fast feedback loops: tests, observability, and notifications that surface failures quickly.
  • Embrace continuous experimentation: blameless postmortems and platform hardening after incidents.
  • Use parameterized templates: delay irreversible choices and keep migration options open.
  • Embed SRE: define SLOs/SLIs, manage error budgets, and instrument metrics/logs/traces.
  • Foster shared ownership and developer empathy through rotations and collaboration.
These foundations let a platform product team (like Sparkle Pony Ranch — Swati, Alan, and Phuong) scale DevOps practices across an organization and deliver better developer velocity with predictable reliability.
A presentation slide titled "DevOps Practices – The Foundation of Effective Platforms" showing a "Sparkle Pony Ranch" team with avatar icons for Swati, Alan, and Phuong on the left. On the right are three key points: "Building a platform, not just infrastructure," "Embedding DevOps principles by design," and "Scaling DevOps practices across the engineering org."
Links and references Keep the Three Ways — Flow, Feedback, and Continuous Experimentation — at the center of platform design to increase developer velocity and organizational reliability.

Watch Video