Guías

Platform Engineering 2026: Por qué las IDP son el nuevo CI/CD

Platform Engineering 2026 se convierte en mainstream. Backstage, Port.io, Humanitec. Qué ofrece una IDP moderna y cómo construirla.

Por Tobias Massow 11 abril 2026 11 min de lectura

Platform Engineering 2026: Por qué las IDP son el nuevo CI/CD

⏱ 8 Min. de lectura

En 2026, la ingeniería de plataformas ya no es un asunto marginal. Gartner ha situado este tema en la fase de Iluminación del Hype Cycle 2024, y los informes Puppet State of DevOps de los últimos tres años muestran un patrón constante: los equipos que cuentan con una plataforma interna para desarrolladores bien establecida realizan despliegues con mayor frecuencia, más rapidez y con menos fallos que aquellos que no disponen de ella. La cuestión ya no es si la ingeniería de plataformas sustituirá a DevOps, sino cómo las empresas pueden llevar a cabo este cambio sin repetir los errores de la primera ola.

Por qué DevOps no ha cumplido con las expectativas

El enfoque de DevOps, tal como se ha debatido desde 2009, se basaba en una premisa sencilla: los desarrolladores y el equipo de operaciones comparten la responsabilidad. Objetivos comunes, turnos conjuntos de guardia y pipelines de despliegue compartidos. Sin embargo, en la práctica, esto ha dado lugar a una realidad muy diferente en muchas organizaciones: ahora se espera que los desarrolladores dominen un amplio abanico de competencias, desde YAML de Kubernetes y Terraform hasta el diseño de pipelines CI y la configuración de herramientas de observabilidad. La carga cognitiva, como describen Matthew Skelton y Manuel Pais en su libro «Team Topologies», se disparó.

Este patrón se hizo evidente a partir de 2021. En encuestas, los desarrolladores expresaban su malestar por la gran cantidad de herramientas, las múltiples áreas de responsabilidad y la escasa disponibilidad de tiempo para el desarrollo de nuevas funcionalidades. El informe «Puppet State of DevOps» de 2022 fue el primero en cuantificar claramente este efecto: en empresas con un nivel bajo de madurez en plataformas tecnológicas, los equipos de desarrollo dedicaban hasta el 40 % de su tiempo a tareas relacionadas con la infraestructura y las herramientas, en lugar de centrarse en el código de las características. Fue precisamente en ese punto cuando surgió Platform Engineering como solución.

La idea fundamental no es nueva, pero sí lo son la terminología y la forma de enfocarla desde el prisma del producto. En lugar de reactivar una división central de operaciones encargada de gestionar tickets y dictar las herramientas a utilizar, un equipo de Platform Engineering construye una plataforma autoservicio con abstracciones claras. De esta manera, los desarrolladores disponen de rutas predeterminadas que cubren el 80 % de los casos habituales, permitiéndoles concentrarse en el 20 % restante, donde realmente se requiere experiencia especializada en el dominio específico.

Qué ofrece una plataforma moderna para desarrolladores internos

Una IDP en 2026 es mucho más que una herramienta de CI/CD con interfaz gráfica. Agrupa al menos cinco capacidades clave: plantillas de Infrastructure-as-Code para todos los tipos de servicios habituales, observabilidad integrada con Prometheus y OpenTelemetry, gestión de secretos a través de HashiCorp Vault o equivalentes nativos en la nube, Policy-as-Code mediante Open Policy Agent para establecer guardrails de cumplimiento y seguridad, y un catálogo de servicios que vincula cada activo desplegado con su responsable, sus dependencias y los dashboards de observabilidad.

Backstage proporciona la base de la interfaz de usuario y los complementos que la mayoría de las organizaciones toman como punto de partida. Solo la función del catálogo de servicios ya es motivo suficiente para comenzar con Backstage: para todos los servicios desplegados, muestra el propietario actual, la última fecha de implementación, el marco de tiempo de ejecución utilizado, los dashboards de observabilidad y la documentación. En una empresa de 500 empleados, si nadie sabe quién mantiene un servicio específico, se empieza a perder la confianza; precisamente eso es lo que busca abordar el Platform Engineering.

El desafío radica en que, tal como viene de fábrica, Backstage solo constituye el marco básico. La plataforma real surge de los complementos y de la configuración adecuada. Spotify mismo invirtió varios años y un equipo de entre 15 y 20 ingenieros antes de que Backstage alcanzara el estado de producción interna. Quienes subestiman esta realidad pueden terminar con un prototipo que no sirve a nadie. Por esa misma razón, el mercado comercial de plataformas gestionadas para desarrolladores internos (IDPs) y de herramientas para construirlas experimentó un crecimiento significativo en 2025 y 2026.

Topologías de equipos: El marco organizativo

Sin la estructura adecuada de equipos, el Platform Engineering se convierte en una mera rebranding cosmético. El marco de Topologías de Equipos de Skelton y Pais define cuatro tipos de equipos: alineados con flujos de trabajo, de plataforma, habilitadores y de subsistemas complejos. Un equipo de plataforma no es un proveedor omnisciente de servicios, sino un equipo especializado cuyo cometido es reducir la carga cognitiva de los equipos alineados con flujos de trabajo. Esto lo logra mediante productos de plataforma, no a través del procesamiento de tickets.

La clave del éxito radica en tres principios. En primer lugar: la plataforma tiene clientes internos, no usuarios finales. La retroalimentación, las solicitudes de nuevas características y las métricas de usabilidad se gestionan como si fueran parte de un producto externo. En segundo lugar: los caminos dorados no son obligatorios, sino la ruta estándar. Un equipo de desarrollo que, por razones válidas, necesite una arquitectura diferente puede implementarla, siempre y cuando sea consciente de las consecuencias. En tercer lugar: la plataforma se mide por la experiencia del desarrollador, no por el tiempo de actividad de la infraestructura. El tiempo de actividad es una condición necesaria, pero no el objetivo final.

Los errores típicos de la primera ola

Las organizaciones que iniciaron Platform Engineering en 2022 y 2023 han repetido tres patrones que hoy en día son evitables. En primer lugar, muchos equipos construyeron la plataforma desde cero, sin planificar la migración de los servicios existentes. El resultado: una excelente IDP para nuevos servicios, pero 200 servicios antiguos con el mismo proceso antiguo de gestión de tickets.

En segundo lugar, muchos equipos de plataforma no lograron mantener una mentalidad de autoservicio. Bajo presión, volvieron al modo operativo tradicional: el equipo de desarrollo presenta un ticket, y el equipo de plataforma se encarga del despliegue. Esto es más rápido a corto plazo, pero socava la comprensión del producto. Una plataforma a la que los clientes no tienen acceso directo no es una plataforma.

En tercer lugar, la experiencia del desarrollador rara vez se midió de forma sistemática. Sin métricas basadas en el marco SPACE ni en enfoques similares, se pierde el bucle de retroalimentación, y la plataforma termina optimizándose según lo que el equipo considera subjetivamente importante, en lugar de centrarse en aquello que realmente frena a los equipos alineados con los flujos de trabajo.

Construir vs. comprar: la decisión económica

La cuestión de construir o comprar se decidirá en 2026 en función de tres factores: el tamaño del equipo, la regulación y la importancia estratégica de la plataforma. Para las empresas con menos de 100 desarrolladores, crear una solución propia con Backstage resulta poco rentable en casi todos los casos. Según estimaciones conservadoras, el coste total de propiedad de una IDP autohospedada oscila entre 1,2 y 2,5 millones de euros durante un periodo de tres años, si se tienen en cuenta de forma realista la creación de plugins, la operación, el mantenimiento y la formación. Por su parte, una oferta gestionada como Port.io o Humanitec se sitúa entre 150.000 y 450.000 euros en el mismo período, dependiendo del número de desarrolladores y del alcance de las funcionalidades.

El principal beneficio de desarrollar internamente radica en el control absoluto sobre la hoja de ruta de la plataforma y en la posibilidad de cumplir requisitos específicos de cumplimiento normativo. Quienes trabajan en sectores altamente regulados, donde no está permitido almacenar datos en soluciones SaaS externas, tienen pocas alternativas a una IDP autoadministrada. En estos casos, la inversión sí resulta justificada, ya que las sanciones por incumplimiento pueden superar con creces los costes de la plataforma. Para el resto de compañías, la recomendación es optar primero por una IDP gestionada y reservar el desarrollo propio para más adelante, cuando el alcance lo haga realmente necesario.

Un aspecto económico muchas veces pasado por alto son la formación y la adopción. Una plataforma que nadie utiliza es más cara que no tener ninguna plataforma. Las organizaciones exitosas destinan entre el 15 % y el 25 % del presupuesto de la plataforma específicamente a actividades de promoción entre desarrolladores, sesiones de incorporación y documentación. Esto puede parecer elevado, pero es la única inversión que acelera de manera tangible la adopción.

Rutas de migración para entornos existentes

El caso de Greenfield es poco frecuente. La mayoría de las organizaciones cuentan con entre 50 y 500 servicios ya en funcionamiento, además de un ecosistema heterogéneo de herramientas que incluye Jenkins, GitLab CI, ArgoCD, módulos de Terraform y la gestión manual de gráficos Helm. La iniciativa de ingeniería de plataformas debe abordar este panorama; de lo contrario, la IDP quedará reducida a un proyecto aislado.

La ruta de migración pragmática comienza con una auditoría del catálogo de servicios. ¿Qué servicios están actualmente en ejecución? ¿Quién los administra? ¿Qué runtimes utilizan? ¿Cómo se integran con las soluciones de observabilidad? ¿A qué nivel de cumplimiento normativo pertenecen? Esta inventariación suele llevar entre seis y diez semanas en organizaciones de tamaño medio, pero proporciona la base de datos necesaria para todas las decisiones posteriores. Sin ella, el desarrollo de plataformas se realiza a ciegas.

En el segundo paso, el equipo de plataforma identifica entre tres y cinco arquetipos de servicio que cubren entre el 70 y el 80 por ciento de las cargas de trabajo existentes. Para cada arquetipo se crea un camino óptimo: una plantilla claramente definida y mantenida por el equipo de plataforma, que va desde la plantilla del repositorio hasta la pipeline de despliegue. Los nuevos servicios deben implementarse exclusivamente siguiendo uno de estos caminos. Los servicios ya existentes se migran durante un periodo controlado, generalmente vinculado a tareas de refactorización o actualizaciones de framework.

El tercer paso consiste en descontinuar la infraestructura heredada. Es precisamente aquí donde suelen producirse la mayoría de los errores. Muchos equipos de plataforma permiten que las herramientas antiguas sigan operando en paralelo durante demasiado tiempo, debido al complejo proceso de migración de cada servicio individual. El resultado: dos plataformas simultáneas, doble carga operativa y ausencia de responsabilidades claras. Lo que funciona es establecer plazos estrictos y ofrecer asistencia durante la migración, sin conceder excepciones permanentes.

Lo nuevo de 2026: Plataformas aumentadas con IA

La tendencia del último año ha sido que los equipos de plataformas integran asistentes de IA directamente en el flujo de trabajo de la plataforma. No como copilotos para la generación de código, sino como una capa de interacción entre el desarrollador y la plataforma. Un ejemplo: en lugar de rellenar manualmente un plantilla de scaffolding, el desarrollador describe en lenguaje natural lo que necesita. La plataforma propone el template, la configuración y las políticas necesarias, genera las solicitudes de extracción (pull requests) y documenta la decisión.

Humanitec lanzó en 2025 Portal Agent, un primer producto encaminado en esta dirección. Por su parte, Port.io ha integrado funciones de IA para consultas al catálogo de servicios. Backstage, desde principios de 2026, ofrece plugins experimentales de MCP que conectan modelos lingüísticos grandes externos (LLM) con el catálogo de servicios y la documentación técnica. Aunque es difícil medir con precisión el aumento real de la productividad, la adopción está creciendo rápidamente. Los desarrolladores aceptan los asistentes de IA en la plataforma porque reducen la carga cognitiva asociada a la navegación por grandes plataformas de desarrollo interno (IDP).

Datos clave de un vistazo

Definición de Platform Engineering: Una plataforma interna se construye y opera como un producto. Los equipos alineados con los flujos de trabajo son los clientes, que cuentan con acceso autoservicio.

Marco de referencia: Backstage (Spotify, código abierto desde 2020; en fase de incubación en CNCF desde 2022). Catálogo de servicios, documentación técnica y ecosistema de plugins.

Proveedores comerciales: Humanitec, Port.io, Qovery, Mia-Platform. Todos ofrecen Identity and Access Management gestionados o herramientas para crearlos, con una barrera de entrada más baja que desarrollar Backstage de cero.

Modelo organizativo: Team Topologies (Skelton, Pais, 2019). Cuatro tipos de equipos, responsabilidades claras; el equipo de plataforma reduce la carga cognitiva.

Métricas: Métricas DORA (Frecuencia de implementaciones, Tiempo de entrega, Tasa de fallos de cambio y Tiempo medio hasta la reparación), así como el marco SPACE para la experiencia del desarrollador. Sin medición no hay retroalimentación.

Duración típica de la implementación: De 6 a 12 meses hasta tener una IDP productiva, siempre que se mantenga un enfoque estrictamente orientado al producto. Con un compromiso a medias, el proceso puede prolongarse considerablemente.

Preguntas frecuentes

¿En qué se diferencia el Platform Engineering del DevOps clásico?

El DevOps es, ante todo, un principio cultural: la responsabilidad compartida entre desarrollo y operaciones. El Platform Engineering materializa este principio mediante una plataforma interna concebida como un producto. Los equipos alineados por flujos mantienen su responsabilidad sobre el código, pero cuentan con una plataforma que les proporciona infraestructura, despliegues y observabilidad como servicio autónomo. El Platform Engineering no sustituye al DevOps, sino que lo hace escalable.

¿Vale la pena Backstage para las empresas medianas?

Rara vez como solución desarrollada internamente. La inversión en el desarrollo de complementos, el hosting y el mantenimiento suele resultar poco rentable para equipos de menos de 100 desarrolladores. Las plataformas gestionadas de internal developer platforms (IDP), como Port.io o Humanitec, ofrecen el mismo conjunto de funcionalidades con un esfuerzo operativo significativamente menor. Quienes tengan menos de 50 desarrolladores deberían comenzar con una solución gestionada y migrar más adelante, cuando la complejidad lo justifique.

¿Qué métricas indican que el Platform Engineering está funcionando?

Las métricas DORA son el primer punto de referencia: la frecuencia de despliegues aumenta, el tiempo de entrega disminuye, la tasa de fallos en los cambios baja y el tiempo medio hasta la reparación (MTTR) se acorta. Además, los equipos deberían recopilar métricas SPACE relacionadas con la experiencia del desarrollador. Una buena plataforma se reconoce porque los equipos ya no se quejan de ella, sino que presentan solicitudes de nuevas características.

¿De qué tamaño debería ser un equipo de Platform Engineering?

Depende del alcance de la plataforma. Como regla general, se recomienda contar con un equipo de Platform Engineering de entre 4 y 8 ingenieros por cada 100 desarrolladores organizados en flujos. Equipos más pequeños pueden gestionar una plataforma más ágil, pero no deben cometer el error de abordar el Platform Engineering con apenas media jornada dedicada a esta tarea. Eso no funciona.

¿Qué papel desempeñan los asistentes de IA en el Platform Engineering para 2026?

Un papel cada vez más importante. Herramientas similares a Copilot ya están integradas en Backstage y en IDPs comerciales, especialmente para la generación de plantillas y la resolución de problemas. Sin embargo, el verdadero valor añadido no radica únicamente en la generación automática de código, sino en acelerar la interacción con la plataforma: un desarrollador describe en lenguaje natural lo que necesita, y la plataforma le ofrece la selección de plantillas adecuada, documentándola al mismo tiempo. Para 2026, esto ya estará implementado en las primeras IDPs gestionadas y disponible en Backstage como complemento experimental.