Platform Engineering es la disciplina de diseñar y construir plataformas internas de autoservicio que permiten a los desarrolladores desplegar, operar y observar sus aplicaciones sin depender de tickets o equipos de infraestructura. Es la evolución natural de DevOps cuando las organizaciones escalan.
Qué es Platform Engineering
Platform Engineering nació para resolver un problema concreto: a medida que las empresas adoptaron DevOps y dieron más responsabilidades a los developers ("you build it, you run it"), la carga cognitiva se volvió insostenible. Los desarrolladores pasaban más tiempo configurando pipelines, clusters y permisos que escribiendo código de producto.
Platform Engineering propone una solución: un equipo dedicado (platform team) construye una Internal Developer Platform (IDP) que abstrae la complejidad de la infraestructura detrás de interfaces simples y autoservicio.
El Problema que Resuelve
Sin platform engineering, un developer que quiere desplegar un nuevo servicio necesita:
- Configurar un repositorio con CI/CD
- Crear recursos cloud (bases de datos, colas, storage)
- Configurar Kubernetes manifests (deployment, service, ingress)
- Gestionar secretos y variables de entorno
- Configurar monitoreo y alertas
- Gestionar certificados TLS
- Configurar DNS
- Solicitar permisos IAM
Con una IDP bien construida, el developer:
- Ejecuta un comando o usa un portal web
- La plataforma configura todo lo demás automáticamente
El resultado: despliegues que pasaban de días a minutos.
Platform Engineering vs DevOps vs SRE
Estas tres disciplinas se complementan, pero tienen enfoques distintos:
| Aspecto | DevOps | SRE | Platform Engineering |
|---|---|---|---|
| Enfoque | Cultura y prácticas | Confiabilidad del servicio | Productividad del developer |
| Pregunta clave | "Cómo colaboran Dev y Ops?" | "Cuán confiable es el sistema?" | "Cómo hago que Dev sea autosuficiente?" |
| Producto | Prácticas y automatización | SLOs, error budgets, on-call | Internal Developer Platform |
| Métricas | DORA metrics | SLIs/SLOs/SLAs, MTTR | Developer satisfaction, lead time |
| Equipo | Cultura transversal | Equipo SRE dedicado | Platform team dedicado |
| Origen | Comunidad (2009) | Google (2003) | Evolución de DevOps (2020+) |
Platform Engineering no reemplaza a DevOps ni a SRE. DevOps define la cultura. SRE define las prácticas de confiabilidad. Platform Engineering construye las herramientas que hacen viable implementar ambos a escala.
Para profundizar en la relación entre SRE y DevOps, consulta nuestra guía de SRE vs DevOps.
Arquitectura de una Internal Developer Platform
Una IDP bien diseñada tiene varias capas:
┌─────────────────────────────────────────────────────────────┐
│ Developer Interface │
│ (Portal Web / CLI / IDE Plugins / API) │
├─────────────────────────────────────────────────────────────┤
│ Orchestration Layer │
│ (Workflows, Templates, Policies) │
├─────────┬──────────┬──────────┬──────────┬─────────────────┤
│ CI/CD │ Infra │ Secrets │ Observe │ Security │
│ GitHub │ Terraform│ Vault │ Prom+ │ Policy-as-Code │
│ Actions │ Crossplan│ AWS SM │ Grafana │ OPA/Kyverno │
├─────────┴──────────┴──────────┴──────────┴─────────────────┤
│ Infrastructure Layer │
│ (Kubernetes / AWS / Azure / GCP) │
└─────────────────────────────────────────────────────────────┘
Capa 1: Developer Interface
El punto de contacto con los developers. Puede ser:
- Portal web: Backstage (Spotify), Port, Cortex, Humanitec
- CLI: Herramientas de línea de comandos custom
- Catálogo de servicios: Inventario de todos los servicios, owners y documentación
- Templates: Scaffolding para crear nuevos servicios con un clic
Capa 2: Orchestration
La lógica que conecta la interfaz del developer con la infraestructura real:
- Workflows: Secuencias de pasos automatizados (crear repo, configurar CI/CD, desplegar infra)
- Templates: Blueprints reutilizables para diferentes tipos de servicio
- Policies: Reglas que garantizan compliance, seguridad y estándares
Capa 3: Integrations
Las herramientas que la plataforma orquesta:
- CI/CD: GitHub Actions, GitLab CI, ArgoCD
- IaC: Terraform, Crossplane, Pulumi
- Secrets: HashiCorp Vault, AWS Secrets Manager
- Observabilidad: Prometheus, Grafana, Loki, OpenTelemetry
- Seguridad: OPA, Kyverno, Trivy, Snyk
Capa 4: Infrastructure
La infraestructura real donde corren los servicios:
- Clusters Kubernetes (EKS, AKS, GKE)
- Servicios cloud managed (RDS, ElastiCache, S3)
- Networking (VPCs, load balancers, DNS)
Backstage: El Estándar Open Source
Backstage, creado por Spotify y donado a la CNCF, se ha convertido en el framework de referencia para construir IDPs. Es un portal de desarrollador extensible con plugins.
Componentes de Backstage
| Componente | Función |
|---|---|
| Software Catalog | Registro de todos los servicios, APIs, docs y owners |
| Software Templates | Scaffolding para crear nuevos servicios |
| TechDocs | Documentación técnica integrada (docs-as-code) |
| Plugins | Extensiones para CI/CD, cloud, monitoreo, etc. |
| Search | Búsqueda unificada en todos los recursos |
Ejemplo: Template para Nuevo Servicio
# backstage-template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: nodejs-service
title: Node.js Microservice
description: Crea un microservicio Node.js con CI/CD, K8s y monitoreo
spec:
owner: platform-team
type: service
parameters:
- title: Service Info
required: [name, owner]
properties:
name:
title: Service Name
type: string
pattern: '^[a-z0-9-]+$'
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
description:
title: Description
type: string
- title: Infrastructure
properties:
database:
title: Database
type: string
enum: [none, postgresql, mongodb, dynamodb]
default: none
cache:
title: Cache
type: string
enum: [none, redis, memcached]
default: none
steps:
- id: create-repo
name: Create Repository
action: publish:github
input:
repoUrl: 'github.com?repo=${{ parameters.name }}&owner=my-org'
defaultBranch: main
- id: create-infra
name: Provision Infrastructure
action: terraform:apply
input:
template: microservice-base
variables:
service_name: ${{ parameters.name }}
database: ${{ parameters.database }}
cache: ${{ parameters.cache }}
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: ${{ steps['create-repo'].output.repoContentsUrl }}
catalogInfoPath: '/catalog-info.yaml'
output:
links:
- title: Repository
url: ${{ steps['create-repo'].output.remoteUrl }}
- title: Open in Backstage
icon: catalog
entityRef: ${{ steps['register'].output.entityRef }}
Con este template, un developer crea un servicio completo (repo + CI/CD + infraestructura + monitoreo + registro en catálogo) en menos de 5 minutos.
Herramientas del Ecosistema
Portales de Developer
| Herramienta | Tipo | Fortaleza |
|---|---|---|
| Backstage | Open Source (CNCF) | Extensibilidad, comunidad, plugins |
| Port | SaaS | Scorecards, Actions, no-code |
| Cortex | SaaS | Developer scorecards, standards |
| Humanitec | SaaS | Orchestration-first, dynamic configs |
| OpsLevel | SaaS | Service maturity, microservice catalog |
Infrastructure Orchestration
| Herramienta | Enfoque |
|---|---|
| Crossplane | Kubernetes-native IaC, CRDs para recursos cloud |
| Terraform + Atlantis | IaC con PR-based workflows |
| Pulumi | IaC con lenguajes de programación |
| AWS Service Catalog | Templates de infra aprobados por la org |
GitOps y Deployment
| Herramienta | Función |
|---|---|
| ArgoCD | GitOps para Kubernetes deployments |
| Flux | GitOps alternativo a ArgoCD |
| Spinnaker | Deployment pipelines multi-cloud |
| Helm | Package manager para Kubernetes |
Cómo Implementar Platform Engineering
Paso 1: Entender a tus Usuarios
Antes de construir nada, investiga:
- Cuánto tiempo pierden los developers en tareas de infraestructura
- Cuáles son los procesos más dolorosos (onboarding, deploys, debugging)
- Qué nivel de autonomía quieren los developers
- Cuál es la carga cognitiva actual
Herramientas: encuestas, entrevistas, shadowing, métricas de lead time.
Paso 2: Definir el MVP de la Plataforma
No intentes construir todo de golpe. Identifica los "paved paths" más valiosos:
MVP típico:
1. Template para crear nuevo servicio (repo + CI/CD + deploy)
2. Self-service para ambientes efímeros (PR environments)
3. Catálogo de servicios (quién es dueño de qué)
4. Dashboards de observabilidad por servicio
Paso 3: Build vs Buy
| Componente | Build (custom) | Buy (SaaS) | Use (Open Source) |
|---|---|---|---|
| Portal | Solo si tienes +5 platform engineers | Port, Cortex, OpsLevel | Backstage |
| CI/CD | No recomendado | CircleCI, GitHub Actions | Jenkins, Tekton |
| IaC | No recomendado | Spacelift, env0 | Terraform, Crossplane |
| Observabilidad | No recomendado | Datadog, New Relic | Prometheus + Grafana |
Paso 4: Platform as a Product
La plataforma debe tratarse como un producto interno:
- Product owner: Alguien que prioriza features basándose en impacto al developer
- User research: Feedback continuo de los developers
- Roadmap: Plan público de qué viene en la plataforma
- Docs: Documentación clara y actualizada
- SLOs: La plataforma tiene sus propios objetivos de confiabilidad
- Opt-in, no mandate: Los developers eligen usar la plataforma porque es mejor, no porque los obliguen
Paso 5: Medir el Impacto
Métricas clave para evaluar si la plataforma funciona:
| Métrica | Qué Mide | Target |
|---|---|---|
| Time to first deploy | Cuánto tarda un developer nuevo en desplegar | < 1 día |
| Deployment frequency | Cuántas veces se despliega por semana | Diario |
| Developer satisfaction (NPS) | Qué tan contentos están los users | > 40 |
| Self-service ratio | % de tareas que no requieren tickets | > 80% |
| Lead time for changes | Commit a producción | < 1 día |
| Onboarding time | Nuevo dev productivo | < 1 semana |
Ejemplo Real: IDP Mínima con Herramientas Open Source
Para un equipo de 20-50 developers, esta es una IDP funcional:
Stack:
Portal: Backstage (catalog + templates + TechDocs)
CI/CD: GitHub Actions (build + test + deploy)
GitOps: ArgoCD (sync K8s manifests from Git)
IaC: Terraform + Terragrunt (infra provisioning)
Secrets: AWS Secrets Manager + External Secrets Operator
Observability: Prometheus + Grafana + Loki
Security: Trivy (image scanning) + Kyverno (policies)
DNS/TLS: External-DNS + cert-manager
Flujo para nuevo servicio:
1. Developer abre Backstage → elige template "Node.js Service"
2. Backstage crea repo en GitHub con Dockerfile, CI/CD, K8s manifests
3. Developer hace push de código
4. GitHub Actions: build → test → push image → update K8s manifest
5. ArgoCD detecta cambio en manifest → despliega en cluster
6. Prometheus scrape métricas → Grafana dashboard automático
7. Alertas configuradas automáticamente via alerting rules template
Estructura de un Servicio Generado
mi-nuevo-servicio/
├── src/ # Código de la app
├── Dockerfile # Multi-stage, pre-configurado
├── .github/
│ └── workflows/
│ └── ci-cd.yaml # Pipeline completo
├── k8s/
│ ├── deployment.yaml # Con resource limits, probes
│ ├── service.yaml # ClusterIP service
│ ├── ingress.yaml # Con TLS automático
│ └── hpa.yaml # Autoescalado
├── monitoring/
│ ├── dashboard.json # Grafana dashboard
│ └── alerts.yaml # PrometheusRule
├── catalog-info.yaml # Registro en Backstage
└── docs/
└── index.md # TechDocs automáticos
Errores Comunes
1. Construir sin Usuarios
El error mas frecuente: el platform team construye lo que cree que los developers necesitan, sin preguntarles. La plataforma termina siendo un proyecto interno que nadie usa.
Solución: Tratar la plataforma como un producto. User research, feedback loops, métricas de adopción.
2. Mandatar en vez de Facilitar
Obligar a los developers a usar la plataforma genera resistencia. Si la plataforma es buena, la adopción es natural.
Solución: Hacer que el camino feliz (golden path) sea tan fácil que nadie quiera hacer las cosas de otra forma.
3. Demasiada Abstracción
Abstraer tanto que los developers no entienden qué pasa debajo. Cuando algo falla, no pueden debuggear.
Solución: Abstracciones con escape hatches. El developer puede ver y customizar lo que la plataforma genera.
4. No Invertir en Documentación
Una plataforma sin documentación es una plataforma que genera tickets de soporte.
Solución: TechDocs integrados, runbooks para problemas comunes, FAQs actualizados.
Tendencias 2026
Platform Engineering + IA
La IA está transformando las IDPs:
- Code generation: Templates que generan código basado en prompts
- Troubleshooting asistido: IA que analiza logs y sugiere soluciones
- Cost optimization: Recomendaciones automáticas de right-sizing
- Security remediation: Detección y fix automático de vulnerabilidades
Platform as Code
Definir la plataforma completa como código versionado:
- Configuración de Backstage como código
- Policies como código (OPA/Rego)
- Infrastructure como código (Terraform/Crossplane)
- Observabilidad como código (dashboards, alerts en Git)
Multi-Cloud Platforms
Plataformas que abstraen el cloud provider, permitiendo desplegar en AWS, Azure o GCP con la misma interfaz. Crossplane y Kratix son herramientas clave en esta tendencia.
Conclusión
Platform Engineering no es un hype: es la respuesta pragmática al problema de escalar DevOps en organizaciones con decenas o cientos de developers. El objetivo es simple: que los developers puedan enfocarse en escribir código de producto, no en configurar infraestructura.
Si tu equipo tiene menos de 10 developers, probablemente no necesitas un platform team dedicado. Un buen setup de CI/CD con templates reutilizables es suficiente. Pero si tienes 20+, y tus developers pierden horas en tareas de infraestructura, es momento de invertir en una IDP.
Empieza simple: un catálogo de servicios en Backstage, templates para nuevos servicios, y pipelines estandarizados. Mide el impacto, itera, y crece la plataforma basándote en las necesidades reales de tus usuarios.
Para complementar, consulta nuestra guía de métricas y KPIs DevOps para medir el impacto de tu plataforma, y cómo CI/CD con GitHub Actions se integra en tu IDP.
Top comments (0)