El platform engineering lleva un par de años instalado en todas las conferencias, lo que garantiza dos cosas: que algunas organizaciones lo necesitan de verdad y que muchas más lo van a montar sin necesitarlo. La pregunta útil no es si está de moda, sino si en tu caso las cuentas salen.
El síntoma que la justifica
Una plataforma interna resuelve un problema muy concreto: que cada equipo de producto esté resolviendo por su cuenta los mismos problemas de infraestructura, de formas distintas y con calidad desigual.
Se reconoce por señales específicas. Desplegar un servicio nuevo lleva semanas y consiste sobre todo en copiar configuración de otro equipo. Cada equipo tiene su propia forma de gestionar secretos. Nadie sabe con certeza qué versión de qué se ejecuta en producción. Y las personas más veteranas dedican la mitad de su tiempo a desatascar a las demás.
Si nada de esto te suena, no necesitas una plataforma. Necesitas, como mucho, mejores plantillas.
El umbral es aritmética, no ideología
Una plataforma interna es un producto, y un producto tiene coste de construcción y de mantenimiento indefinido. La cuenta es directa: cuántas horas al mes pierde hoy el conjunto de la organización en trabajo de infraestructura repetido, frente a cuántas horas cuesta construir y sostener la alternativa.
Con tres equipos de producto, ese cálculo casi nunca sale a favor: la duplicación existe pero es barata comparada con mantener una plataforma. A partir de seis u ocho equipos suele salir con holgura, porque el coste de la plataforma se reparte y el de la duplicación crece de forma no lineal.
En medio hay una zona gris donde la decisión correcta suele ser intermedia: estandarizar y documentar sin construir producto.
Producto, no proyecto
Aquí es donde fracasa la mayoría de las iniciativas. Se monta la plataforma como un proyecto con fecha de fin, se entrega, y al año siguiente nadie la mantiene mientras las necesidades han cambiado. El resultado es peor que no haberla hecho: ahora hay una capa obsoleta obligatoria entre los equipos y su infraestructura.
Tratarla como producto significa tres cosas concretas: alguien responsable de su evolución, usuarios internos a los que se pregunta qué necesitan, y métricas de adopción. Si los equipos la esquivan, la plataforma está fallando, aunque técnicamente funcione.
Camino dorado, no camino único
La plataforma debe ofrecer una vía por defecto tan cómoda que la mayoría la elija por comodidad, no por obligación. Y debe permitir salirse de ella cuando un caso lo justifique.
Las plataformas obligatorias generan resistencia y, sobre todo, generan trabajo oculto: equipos que montan sus propias soluciones por debajo del radar porque la vía oficial no cubre su caso. Eso es peor que la duplicación original, porque ahora es duplicación clandestina.
Cuándo es mala idea
- Cuando no hay nadie que la pueda mantener. Sin una persona dedicada como mínimo, es cuestión de meses que se quede atrás.
- Cuando el problema real es de organización. Si los equipos no despliegan porque hay un comité de aprobación, ninguna plataforma lo va a arreglar.
- Cuando se monta para justificar una tecnología. «Necesitamos Kubernetes» no es un requisito de negocio.
Por dónde empezar sin equipo dedicado
Si estás en la zona gris, hay un camino intermedio que da la mayor parte del valor por una fracción del coste: plantillas de servicio versionadas y mantenidas, un pipeline de referencia que los equipos copian, gestión de secretos centralizada y documentación de cómo se hace aquí cada cosa.
No es una plataforma, y no hace falta llamarlo así. Resuelve el 70% del problema y se puede sostener con horas repartidas, no con un equipo.
¿Estás valorando esta decisión? Contrástala con nosotros antes de invertir →
Sigue leyendo
- El coste oculto de no estandarizar el stack tecnológico
- Un pipeline de CI/CD en GitHub Actions listo para producción
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.