As Kubernetes adoption matures, platform engineering teams face a crucial challenge: how to provide application developers with self-service infrastructure without drowning them in YAML complexity or exposing sensitive cloud credentials.
In this first episode, we explore Kratix — an open-source framework developed by Syntasso designed to build composable, multi-cluster Internal Developer Platforms (IDPs) natively on Kubernetes.
🏛️ The Problem: Cognitive Load & Ticket-Driven Ops#
Traditional platform management usually falls into one of two extremes:
- Ticket-Driven Operations: Developers open Jira tickets requesting S3 buckets, PostgreSQL databases, or Redis caches. Platform engineers manually run Terraform or Ansible. Result: High friction, slow lead time.
- Raw Kubernetes YAML Dumping: Platform teams give developers raw Helm charts, Crossplane CRDs, or complex Kustomize manifests. Result: High cognitive load, security misconfigurations, and developer frustration.
flowchart LR
subgraph TicketDriven [Ticket-Driven Ops]
Dev1["App Developer"] -->|Jira Ticket| PlatOps["Platform Engineer"]
PlatOps -->|Manual Terraform| Infra["Cloud Infrastructure"]
end
subgraph RawYAML [YAML Dump]
Dev2["App Developer"] -->|Fails to write 500 lines of CRD| K8s["Kubernetes Cluster"]
end
💡 The Kratix Solution: Platform-as-a-Product#
Kratix introduces a Platform-as-a-Product philosophy. Instead of exposing raw infrastructure controllers to developers, platform teams construct Promises.
A Promise is a clean, declarative API contract published by the platform team. It encapsulates:
- The custom API (CRD) presented to developers (e.g.,
kind: PostgresDatabase). - The automated workflows required to provision and configure the underlying infrastructure.
- The destination scheduling rules (where to deploy: EKS, GKE, or On-Prem).
flowchart TD
subgraph PlatformTeam [Platform Engineering Team]
P1["Define Promise API"]
P2["Configure Workflows & Containers"]
P3["Set Destination Scheduling Rules"]
end
subgraph KratixEngine [Kratix Framework]
P1 & P2 & P3 --> Kratix["Kratix Platform Control Plane"]
end
subgraph AppTeam [Application Developers]
Dev["Request Simple Resource: kind PostgresDatabase"] --> Kratix
end
Kratix -->|GitOps State Store| GitOps["ArgoCD / Flux"]
GitOps -->|Deploy Manifests| Clusters["Target Kubernetes Clusters"]
⚔️ Kratix vs Other Platform Tools#
| Dimension | Kratix | Raw Helm / Kustomize | Crossplane Alone | Backstage |
|---|---|---|---|---|
| Primary Focus | IDP Framework & Promises | Package Management | Infrastructure Control Plane | Developer Portal UI |
| User Interface | Kubernetes CRD / API | CLI / CD Pipelines | Kubernetes CRD | Web Portal / Catalog |
| Execution Logic | Arbitrary Container Pipelines | Helm Engine | Go Controllers | Software Templates |
| Multi-Cluster Scheduling | Built-in (Destinations) | Manual CD pipelines | Provider-dependent | N/A (UI layer) |
Kratix complements tools like Backstage (which provides the Web UI catalog) and Crossplane / Terraform (which execute the raw infrastructure provisioning inside Kratix Pipelines).
🎯 Key Takeaways#
- Kratix enables platform teams to build custom, composable Internal Developer Platforms on top of Kubernetes.
- Promises serve as clean contracts between platform builders and application consumers.
- In the next episode, we will dive deep into the Core Concepts of Kratix: Promises, Resources, Workflows, Pipelines, State Stores, and Destinations.