En 2022 planteamos en este blog una pregunta provocadora: ¿debería rebautizarse DevOps como platform engineering? Nuestro argumento era que “DevOps” había pasado de ser una forma de trabajar a ser un título de puesto difuso, y que el equipo que construye la base sobre la que corren las aplicaciones merecía un nombre más claro. Desde entonces, platform engineering se ha convertido en una disciplina propia, con white papers, conferencias y equipos dedicados. Este artículo actualizado explica qué es platform engineering, cómo se relaciona con DevOps y cuándo una startup realmente lo necesita.

Lo que planteamos en 2022

DevOps nació como una filosofía: desarrolladores y operaciones trabajando juntos, con responsabilidad compartida sobre lo que corre en producción. A medida que el mercado la adoptó, la palabra se convirtió en una lista de herramientas y en un título de puesto. Si dices “equipo de producto” o “equipo de aplicación”, la gente entiende qué hace ese equipo. Si dices “equipo de DevOps”, la respuesta depende de a quién le preguntes.

Propusimos asociar DevOps con el stack que entrega el producto, como el equipo que construye y opera la plataforma de la que dependen las aplicaciones. Eso conservaría los beneficios de la filosofía DevOps y le daría al equipo un mandato claro. Esa idea ya tiene nombre, y la industria lo usa en su mayoría.

Qué es platform engineering

Platform engineering es la práctica de construir y operar una plataforma interna que los equipos de producto usan para lanzar y operar su software sin tener que ser expertos en infraestructura.

El white paper de Platforms de la Cloud Native Computing Foundation define una plataforma para cloud native como “an integrated collection of capabilities defined and presented according to the needs of the platform’s users” (una colección integrada de capacidades definidas y presentadas según las necesidades de los usuarios de la plataforma). También cita una descripción muy difundida, de Evan Bottcher y Martin Fowler, que define una plataforma digital como “a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product” (una base de APIs de autoservicio, herramientas, servicios, conocimiento y soporte, organizada como un producto interno atractivo).

Dos palabras de esas definiciones hacen casi todo el trabajo.

Autoservicio. Un desarrollador debería poder crear un servicio nuevo, obtener un pipeline, aprovisionar una base de datos o ver sus logs sin abrir un ticket y esperar a alguien del equipo de infraestructura.

Producto. La plataforma tiene usuarios (tus desarrolladores), y el equipo de plataforma trata su experiencia como un equipo de producto trata a sus clientes. Si los desarrolladores la esquivan, la plataforma fracasó, por elegante que sea.

Herramientas y componentes de platform engineering

En la práctica, una plataforma para una empresa SaaS en AWS suele incluir:

Plantillas para servicios nuevos, con un pipeline funcional, logs y health checks desde el primer día
Módulos de infraestructura como código para recursos comunes como bases de datos, colas y buckets, con valores de seguridad razonables por defecto
Una ruta de deploy estándar, a menudo GitOps, hacia todos los ambientes
Observabilidad que funciona desde el inicio: dashboards, alertas y trazas para cualquier servicio de la plataforma
Guardrails: límites de IAM, políticas de red, etiquetas de costos y verificaciones de políticas que se ejecutan automáticamente
Documentación y una forma clara de pedir ayuda

Las herramientas de platform engineering detrás de todo esto son en su mayoría conocidas: Terraform o CloudFormation para los módulos, un sistema de CI/CD para el pipeline estándar y un stack de observabilidad para los valores por defecto. Las organizaciones más grandes suelen sumar un portal de desarrolladores como Backstage, un framework de código abierto para construir portales de desarrolladores que creó Spotify y que hoy es un proyecto en incubación de la CNCF. Las herramientas importan menos que el camino pavimentado que forman en conjunto.

Platform engineering vs. DevOps

Platform engineering no reemplaza a DevOps. Es una forma de llevar DevOps a la práctica cuando una organización crece.

DevOps describe el objetivo y la cultura: responsabilidad compartida sobre producción, retroalimentación rápida, automatización, cambios pequeños y frecuentes. Platform engineering es una respuesta organizacional a un problema que aparece cuando los equipos se multiplican. Cuando cada equipo de producto tiene que volverse experto en Kubernetes, Terraform, IAM y observabilidad para lanzar, la carga cognitiva frena a todos. Un equipo de plataforma absorbe esa complejidad una sola vez y se la ofrece al resto como un camino pavimentado.

La idea ya es mayoritaria. El programa de investigación DORA de Google informó en su reporte de 2025 sobre el desarrollo de software asistido por IA que el 90% de las organizaciones ha adoptado al menos una plataforma, y encontró una correlación directa entre una plataforma interna de alta calidad y la capacidad de una organización para sacarle valor a la IA. A medida que las herramientas de IA aumentan el volumen de cambios, una plataforma sólida es lo que mantiene seguros esos cambios.

Cuándo una startup necesita platform engineering

La mayoría de las startups en etapa temprana no necesita un equipo de plataforma, y armar uno demasiado pronto es una forma común de gastar tiempo de ingeniería en lo que no corresponde. Algunas señales indican que te estás acercando:

Tienes varios equipos de producto, no uno, y cada uno resuelve los mismos problemas de infraestructura de manera distinta.
Arrancar un servicio nuevo toma días o semanas porque cada pipeline, ambiente y alerta se construye a mano.
El conocimiento de infraestructura vive en una o dos cabezas. Cuando están ocupadas o ausentes, los demás equipos esperan.
Los incidentes siguen viniendo de la inconsistencia: un servicio sin health checks, otro sin alertas, un tercero desplegado con un script que nadie recuerda haber escrito.
Se acerca el cumplimiento normativo. Los controles de SOC 2 o HIPAA son mucho más fáciles de evidenciar cuando todos los servicios siguen los mismos patrones.
Vas a pasar a varias cuentas de AWS o a Kubernetes, y la cantidad de piezas en movimiento está a punto de dispararse.

Si ninguna aplica, bastan unas pocas convenciones bien elegidas y un buen pipeline. Si varias aplican, necesitas a alguien que piense en la plataforma como un producto.

Cómo conseguir una plataforma sin armar un equipo de plataforma

Un equipo de plataforma dedicado suele significar varios ingenieros senior, un compromiso grande para una empresa con tres o cuatro equipos de producto. Hay opciones más ligeras:

Empieza por el camino pavimentado, no por un portal. Una plantilla de servicio, un pipeline estándar y módulos de Terraform compartidos entregan la mayor parte del valor. Un portal de desarrolladores puede venir después, si es que viene.
Estandariza primero lo que más duele. Si los incidentes vienen de la falta de observabilidad, empieza por ahí. Si incorporar un servicio es el cuello de botella, empieza por las plantillas.
Trata la plataforma como código en tus repositorios, de modo que quien la mantenga, interno o externo, trabaje desde la misma fuente de verdad.
Incorpora un equipo que ya hace esto. Un equipo externo puede construir los cimientos y operarlos mientras tus ingenieros los aprenden, y luego traspasarlos a medida que contratas.

Para una visión más amplia de la decisión entre contratar y externalizar, lee cuándo contratar un equipo de DevOps de tiempo completo.

Preguntas frecuentes

¿Platform engineering es lo mismo que DevOps?

No, pero están estrechamente relacionados. DevOps es el objetivo y la cultura: responsabilidad compartida sobre producción, automatización y retroalimentación rápida. Platform engineering es una forma de llevar DevOps a la práctica a medida que una organización crece, haciendo que un equipo construya una plataforma interna de autoservicio que los equipos de producto usen como camino pavimentado.

¿Qué habilidades necesitas para ser platform engineer?

Los platform engineers necesitan las habilidades centrales de DevOps, como infraestructura como código, CI/CD, servicios en la nube, contenedores y observabilidad, además de nociones básicas de seguridad como IAM y políticas de red. Igual de importante es el pensamiento de producto: tratar a los desarrolladores como usuarios, descubrir qué los frena y construir herramientas de autoservicio que ellos elijan usar. Una plataforma que los desarrolladores esquivan fracasó, por buena que sea la ingeniería.

¿Cuándo necesita una startup platform engineering?

Normalmente no en la etapa más temprana. Las señales son varios equipos de producto que resuelven los mismos problemas de infraestructura de manera distinta, servicios nuevos que tardan días en configurarse, conocimiento de infraestructura en manos de una o dos personas, incidentes causados por la inconsistencia, y trabajo de cumplimiento normativo o de múltiples cuentas en camino. Si varias de esas aplican, alguien debería hacerse cargo de la plataforma como producto.

Dónde encaja Webera: el plan Platform

Webera es una suscripción de DevOps para equipos SaaS en AWS, con ingenieros senior que trabajan junto a nueve agentes de IA. Nuestro plan Platform, a US$14,999 al mes, está pensado para la etapa que describe este artículo: un equipo que trabaja dentro de tus sprints, operación multicuenta y de Kubernetes, y transferencia de conocimiento a tus ingenieros, además de todo lo que incluye Elite (un ingeniero asignado, un gerente de éxito del cliente y un concierge de cumplimiento normativo para SOC 2, HIPAA y PCI). Warden, el agente responsable de los estándares, verifica que cada repositorio esté documentado y que cada alerta tenga un runbook, que es buena parte de lo que hace que una plataforma sea usable por personas que no la construyeron.

Si todavía no estás en esa etapa, Pro (US$4,999 al mes) y Elite (US$9,999 al mes) cubren las solicitudes, el monitoreo y la respuesta a incidentes de un solo equipo de producto. Cada plan tiene un mínimo de tres meses y después continúa mes a mes, y todo el código es tuyo. Compara los planes en nuestra página de precios.

Platform engineering vs. DevOps: ¿hay que cambiarle el nombre a DevOps?