Bienvenidos a otro episodio de Microsoft Knowledge Nuggets en M365FM. Soy su anfitrión Mirko Peters. El tema de hoy es algo de lo que casi todos han oído hablar, pero pocos comprenden realmente, la ingeniería plataforma. Probablemente hayan oído hablar de DevOps, la idea de que los equipos de desarrollo y operaciones trabajen juntos sin problemas, pero en algún punto el camino a esa promesa se complicó. Los desarrolladores terminaron haciendo trabajo de operaciones y el sistema falló. Al final de este episodio entenderán que salió mal con DevOps, que es realmente una plataforma interna de desarrollo como las Rutas Doradas, ofrecen a los equipos un camino claro a seguir y por qué los equipos de ingeniería más inteligentes ya están construyendo una. El desastre que dejó DevOps. Volvamos al principio. DevOps fue una gran idea con un objetivo simple, derribar los muros entre los desarrolladores y las operaciones.

Nomás enviar código por encima de la pared esperando que todo se vea. Moverse a la izquierda, shift left, integrar pruebas, seguridad y operaciones antes en el proceso. Entrega más rápida, menos trapazos, mayor responsabilidad. En papel parecía perfecto. En la práctica algo salió mal. El cambio a la izquierda no solo desplazó responsabilidades, las acumuló. El desarrollador que antes escribía código y enviaba un ticket ahora es dueño de la infraestructura, seguridad, monitoreo, Kubernetes, canales C y CD, gestión de secretos y unos 15 servicios en la nube de los que nunca había oído hablar. Una sola persona maneja todo eso mientras sigue creando el producto real. Así es como se ve esto en la vida real. Un equipo quiere activar un nuevo entorno para probar una funcionalidad. Antes de DevOps enviaban un ticket y esperaban. Después de DevOps, ellos mismos se encargan, lo cual suena genial en teoría.

Pero ahora deben escribir módulos de Terraform, configurar un clúster de Kubernetes, establecer reglas de red, conectar el monitoreo, resolver la gestión de secretos y asegurarse de que se apliquen las políticas de seguridad. Lo que solía ser un ticket que alguien le tomaba una hora a hora requiere tres días de trabajo de un desarrollador. Tres días en los que no están escribiendo código para el plot. Están luchando con archivos YAML y depurando por qué el balanceador de carga no enruta el tráfico correctamente. La carga mental aquí es enorme. Cada equipo termina creando sus propios canales, scripts de despliegue y paneles de monitoreo. Y como todos están al límite, se toman atajos. Se omite la seguridad porque la fecha al límite es el viernes. Las facturas de la nube se duplican sin que nadie lo note porque nadie recordó apagar el entorno de pruebas. Y cuando algo falla, las dos A. El desarrollador que lo construyó es el único que puede arreglarlo.

Esto no es sostenible. Y aquí les explico por qué importa más que nunca. La complejidad de la nube sigue creciendo. Cada año hay más servicios, más herramientas y más decisiones que tomar. Ahora, las herramientas de IA permiten a los desarrolladores publicar código más rápido que nunca. 10, 20 o hasta 30 veces más código al día. Pero todo ese código aún necesita infraestructura, seguridad y monitoreo. Más códigos y un mejor sistema solo significa un caos más rápido. Si sientes que te ahogas en YAML y Terraform, no estás solo. Esto no es un fracaso personal. Es sistémico. El modelo rompió lo que realmente es la ingeniería de plataformas. Entonces, Correlson, se llama ingeniería de plataformas y esta es la forma más sencilla de entenderla. Esta disciplina crea una capa interna que absorbe la complejidad para los desarrolladores. Imagina que entras a un gran edificio de oficina. No tienes que preocuparte por quién tiene acceso a qué piso, qué gafete de seguridad funciona o dónde están las salidas de emergencia.

La recepción se encarga de todo eso por ti y tú solo entras y te pones a trabajar. Eso es exactamente lo que la ingeniería de plataformas hace por tu desarrollo. En lugar de que cada desarrollador deba ser experto en Kubernetes, Terraform, redes y seguridad, un equipo central de plataforma, crea una capa que gestiona toda esa complejidad. El desarrollador obtiene una interfaz sencilla. Hace clic en un botón, ejecuta un comando o llena un formulario. La plataforma se encarga del resto. Pero atención, esto no es lo mismo que DevOps. DevOps decía que cada equipo debía gestionar su propia infraestructura, pero la ingeniería de plataformas dice que eso es receta para el agotamiento. En su lugar, el equipo de plataforma ofrece caminos pavimentados, formas estándar, probadas y seguras de manejar tareas comunes. Ellos construyen y mantienen la carretera, mientras los equipos de productos simplemente conducen sobre él.

El resultado principal de la ingeniería de plataformas es algo llamado Plataforma Interna de Desarrollo, o IDP por sus siglas en inglés. Piénsalo como un sistema de autoservicio que automatiza todo ese trabajo repetitivo. Aprovisionamiento de infraestructura, canales de CIC y CD, revisiones de seguridad y monitoreo, todo integrado y estandarizado. Quiero un ejemplo concreto. Cuando un desarrollador quiere desplegar un nuevo servicio hacia una plataforma, pasa días configurando infraestructura, escribiendo canales y ajustando el monitoreo. Con un IDP, solo hacen clic en desplegar en una interfaz o ejecutan un comando. La plataforma maneja todo. Aprovisionamiento, pruebas, monitoreo y despliegue, todo en minutos en vez de días. No sé qué significa esto para ti. Dejas de ser un experto en toda la infraestructura y te conviertes en especialista en tu producto real, tu trabajo vuelve a hacer crear funciones que le importan a tus clientes, en lugar de depurar por qué tu archivo de estado de plataforma está corrupto.

Ese es el punto central. La Plataforma Interna de Desarrollo, explicada en Plasma. Así que analicemos qué es realmente una plataforma interna de desarrollo. Es el motor que combina todo en un solo sistema. Tus pipelines de CIC y CD, plantillas de infraestructura, políticas de seguridad, monitoreo y registro, en lugar de seis herramientas separadas que tienes que conectar. Aquí hay una analogía. Piénselo como cocinar desde cero versus una máquina expendedora. Cocinar desde cero significa comprar ingredientes, picar verduras, medir especias, vigilar la estufa, vigilar la estufa. Muchas decisiones, muchos pasos, muchas formas de equivocarse. Una máquina expendedora te da un resultado con solo presionar un botón. Menos decisiones, resultado más rápido, calidad consistente, un IDP es esa máquina expendedora. El desarrollador no necesita saber cómo se provee la infraestructura ni dónde se guardan los secretos.

Solo presiona el botón. ¿Qué hay dentro de esa máquina expendedora? Los componentes principales son bastante estantes. Plantillas de CIC y CD para compilaciones consistentes, provisión de infraestructura para crear entornos, automáticamente gestión de secretos para que las credenciales no estén en archivos de configuración y registro con observabilidad integrada para solucionar problemas sin caos. Todo ello preconfigurado, probado y mantenido por el equipo de plataforma. Aquí un ejemplo concreto. Un desarrollador escribe crear nuevo servicio en la línea de comandos o hace clic en un botón en un portal. Detrás de escena, el IDP crea un nuevo repositorio con la estructura correcta, configura un pipeline de compilación que ejecuta pruebas automáticamente. Despliega el servicio en un entorno de desarrollo y añade endpoints de verificación de salud con registro. Todo sucede en minutos. El desarrollador nunca tocó un solo archivo de Terraform y configura un manifiesto de Kubernetes.

Solo escribió un comando y obtuvo un servicio en ejecución. ¿Por qué importa esto? La consistencia es la razón clave. Cuando cada equipo construye sus propios pipelines y escribe sus propios scripts de despliegue, terminas con configuraciones únicas e irrepetibles. 50 servicios diferentes, 50 formas diferentes de hacer las cosas. Cuando algo se rompe, nadie puede depurarlo excepto la persona que lo construyó. Y si esa persona dejó una empresa, buena suerte. Un IDP elimina eso haciendo que cada servicio siga los mismos patrones. Cada despliegue usa el mismo pipeline y cada equipo obtenga los mismos valores predeterminados. Cuando algo se rompe, los patrones son familiares y la solución está documentada. Eso es lo que significa para ti. Si tu organización tiene 50 equipos haciendo despliegues de 50 formas distintas, un IDP es la solución. No significa que los equipos pierdan otro. Significa que las partes aburridas, repetitivas y propensas a errores se estandarizan para que el trabajo interesante y creativo pueda variar.

Ese es un compromiso que vale la pena hacer. Caminos dorados, el camino en una jaula. Hablemos de los caminos dorados. Probablemente hayas escuchado el nombre, pero la idea es simple. Un camino dorado es un flujo de trabajo recomendado y preconstruido que hace que lo correcto sea lo más fácil de hacer. Tu equipo plataforma te dice, así es como sugerimos que hagas esto. Lo hemos probado, funciona y te respaldaremos si algo sale mal. Nota la palabra recomendar. Las rutas doradas no son obligatorias. Desarrolladores pueden salir de la ruta si lo necesitan, pero la ruta es la opción predeterminada rápida y simple. Ya está en funcionamiento con soporte y documentado. No tienes que resolverlo todo de cero. Piénsalo como vías de tren en lugar de barandillas. Las barandillas te atrapan cuando chocas. Reaccionan, evitan que caigas por un precipicio, pero no te ayudan a conducir. Las vías de tren te guían suavemente por la ruta para que no tengas que decidir dónde girar.

Las rutas doradas son las vías. Te hacen avanzar, no solo te atrapan cuando fallas. Aquí es donde muchos equipos se equivocan. Crean rutas doradas para el equipo de plataforma, no para los desarrolladores. Optimizan para la pureza arquitectónica el cumplimiento de seguridad o alguna regla interna que nadie fuera del equipo entiende. El resultado se ve genial en una pizarra, pero se siente terrible a luz. Los desarrolladores encuentran soluciones alternativas en silencio. La adopción cae y el equipo de plataforma se pregunta por qué nadie aprecia tanto suelo. La solución es sencilla, pero es difícil de aplicar. Necesita salir de emergencia. Si la ruta no se ajusta al caso de uso de un desarrollador, necesitan una salida. Una forma de anular un valor predeterminado, traer su propia tubería o salir de la plataforma por completo. Y aquí está la parte importante. Cuando salen de la ruta no es un fracaso, es retroalimentación.

Cada vez que un desarrollador abandona la ruta dorada, te dice algo real. O a la ruta le falta una función que debería tener o el caso de uso realmente no pertenece ahí. Ambas señales son valiosas. Una buena ruta dorada en la práctica se ve así. Un equipo quiere implementar un nuevo servicio de abac. Usan la ruta. Les da un repositorio de plantilla con la estructura correcta, una tubería CICD estándar ya aprobada, registro y monitoreo integrado, si una reversión con un clic, si algo sale mal. Todo toma minutos en lugar de días. Y como el equipo de plataforma mantiene la ruta, si algo se rompe, ellos lo arreglan. Desarrollador no tiene que convertirse en un experto en depuración de tubería. Lo que esto significa para ti, menos sorpresa. Entregas más rápido porque la ruta está aprobada. Entregas de forma más segura porque la seguridad y monitoreo están integrados. Entregas con confianza porque volverá atrás es cuestión de un clic.

La ruta existe para ayudarte, no para frenarte. Úsala. Reduciendo la carga conmigo. Y es donde se ve la verdadera recompensa. Cuando una plataforma se encarga del trabajo pesado, los desarrolladores pueden enfocarse realmente en el código. No necesitan saber qué versión de Kubernetes está ejecutando. No tienen que actualizar los módulos de Terraform cada vez que un proveedor de nube cambia a una API. Realmente escribe funciones. Los ingenieros de plataforma absorben esa complejidad. Ellos deciden qué deben ver los desarrolladores y qué debe permanecer. Es una decisión de diseño real, no solo técnica. Se trata de determinar qué detalles importan a quien usa la plataforma y cuáles solo añaden ruido. Que hay un ejemplo concreto. Un desarrollador que despliega un nuevo servicio no se preocupa por el tamaño de los nodos del crúster, los tipos de distancia o los umbrales de autoescalado. Le importa si su servicio funciona y qué tan rápido responde.

Sí que la plataforma preconfigura todo eso según el nivel de la aplicación. Servicio pequeño. Aquí está la configuración adecuada. Servicio de alto tráfico. Aquí hay una configuración distinta. El desarrollador no toma esas decisiones porque no necesita hacerlo. ¿Por qué importa esto? Porque el agotamiento disminuye cuando los desarrolladores no están haciendo malabares con 15 asuntos a la vez. Algunos equipos de plataforma maduros han reducido la carga cognitiva a casi la mitad. Entre un 40 y un 50% menos de carga mental. Es un cambio enorme. Es la diferencia entre salir del trabajo con energía y quedarse mirando una terminal a las 10 PM preguntándose por qué fue yo el pipeline. Aquí hay una advertencia. No creen ilusiones. Algunos equipos de plataforma creen una trama. Ocultan configuraciones sin dar a los desarrolladores ninguna forma de entender qué ocurre bajo el capó. Eso no es abstracción, es engaño y resulta contraproducente en cuanto algo sale mal.

Los desarrolladores choquen con un muro que no pueden ver a través y de pronto la plataforma aparece una caja negra en su contra. Termino para esto es abstracción con fugas. Oculta es la complejidad pero eventualmente se complejía hace filtro. Una base de datos se vuelve lenta. Un despliegue falla. Una política de seguridad bloquea algo inesperado. Y el desarrollador no tiene un modelo mental de lo que sucede porque la plataforma nunca se lo proporcionó. La transparencia importa. Muestre a los desarrolladores lo que necesitan saber cuando lo necesiten saber. No oculten todo y esperen lo mejor. Lo que esto significa para ti, menos cambio de contexto y más estado de flujo. No comienzas la mañana preguntándote si el cluster de Kubernetes necesita una actualización. Comienzas trabajando en la función que vence la próxima semana. Tu trabajo vuelve a ser tu trabajo real. Tratar la plataforma como un producto.

Hoy hablamos de algo que cambia cómo funcionan realmente las herramientas internas. La mayoría piensa que un equipo de plataforma es solo un equipo de infraestructura. No lo es. Un equipo de plataforma es un equipo de producto y los desarrolladores que usan la plataforma son sus clientes. No personas que envían tickets. Eso lo cambia todo. Un equipo de producto habla con sus clientes. Descubre qué es lo que realmente duele. Brief. Funcionalidades según la necesidad real. Mide la adopción. No construye algo. Y se va a... Sigue iterando. Entonces, ¿cómo se ve un equipo de producto en la práctica? No operan como un servicio de soporte técnico. Un desarrollador envía un ticket. Y el equipo de plataforma lo hace manualmente. Su mensaje ni de plataformas es solo operaciones centralizadas con otro nombre. No escala. No reduce la carga cognitiva. Solo mueve el cuello de botella de un equipo a otro.

Es lo que hacen en su lugar. Miden las cosas correctas. Tiempo hasta el primer despliegue. Velocidad de integración para nuevos miembros. Puntajes de satisfacción del desarrollador. Estas son las métricas que te dicen si la plataforma realmente ayuda o solo añade otra capa de complejidad. Spotify es un buen ejemplo. Su equipo de plataforma funciona como una verdadera organización de producto. Tienen hojas de ruta. Tienen OKRs. Hablan con los desarrolladores sobre lo que funciona y lo que no. Tratan la plataforma como algo que debe ganarse su adopción cada día. Y esa es la idea principal. Una plataforma que nadie usa es solo un proyecto acumulando polvo en un rincón. La adopción es la validación definitiva. Si los desarrolladores eligen tu plataforma en lugar de crear sus propias herramientas, lo has logrado. Si le evitan ninguna cantidad de excelencia técnica, puede arreglar eso. ¿Qué significa esto para ti?

Significa que si estás construyendo una plataforma, no empieces con diagramas de arquitectura. No empieces con clústeres de Kubernetes o módulos de Terraform. Empieza con entrevistas a usuarios. Habla con los desarrolladores que usarán tu plataforma. Descubre que realmente duele. Construye una cosa que resuelva un problema real. Luego itera. Así es como construyes algo que la gente realmente quiere usar. ¿Por qué ahora mismo? La habla de la IA. Entonces, ¿por qué hablamos de esto justo ahora? Porque no hace 5 años. La respuesta es de IA. Las herramientas de codificación por IA como GitHub Copilot permiten a los desarrolladores enviar código a un ritmo que nunca habíamos visto. 10, 20 veces más código por día de lo que era posible hace solo un par de años. Eso suena increíble. ¿Y lo ves? Aquí está la trampa. Todo ese código todavía necesita infraestructura. Todavía necesita seguridad. Todavía necesita ser desplegado, probado y operado.

Más códigos sin un mejor sistema no te hacen más rápido. Solo acelera el caos. Si tus desarrolladores ya se están ahogando en Jamel y Terraform, la IA no soluciona eso. Solo significa que se ahogan más rápido mientras producen más código que necesita ser respaldado. En este momento, alrededor del 55% de las organizaciones ya han adoptado la ingeniería de plataformas de alguna forma. Gartner predice que esa cifra llegará al 80% para finales de 2026. Esa no es una tendencia lenta. Es un cambio que está ocurriendo ahora mismo. Las empresas se están dando cuenta de que no pueden escalar sus equipos de ingeniería sin una capa de plataforma. El viejo enfoque de que cada equipo haga todo por sí mismo simplemente no funciona cuando entregas código a velocidad de IA. Esto es lo que mucha gente pasa por alto. La IA no solo crea la necesidad de plataformas. También ayuda a construir. Los equipos de plataforma utilizan la IA para generar módulos de Terraform, escribir documentación y depurar procesos.

La misma tecnología que crea la urgencia también proporciona las herramientas para resolverla. Ahora, una advertencia. La IA amplifica lo que ya tienes. Si tus fundamentos son sólidos, como una buena arquitectura y una plataforma bien diseñada, la IA te hace de dos a tres veces más productivo. Pero si tus bases son débiles, la IA solo te ayuda a cometer errores más grandes más rápido. Malas configuraciones, brechas de seguridad, infraestructura rota, todo enviado a producción antes de que alguien lo note. La IA no arregla las malas bases, las deja al descubierto. Aquí hay un ejemplo real. Una empresa con una buena plataforma interna para desarrolladores puede permitir que un ingeniero despede herramientas de IA de formación. La plataforma proporciona esa labor. Aplica políticas de seguridad. Se encarga de la infraestructura. Así, un gerente de producto puede crear un prototipo basado en IA sin necesidad de entender Kubernetes o redes en la nube.

Eso es poderoso. Es el tipo de cosas que separa a los equipos preparados para la era de la IA de los equipos que se quedarán atrás de la IA. ¿Qué significa esto para ti? La ventana para construir una plataforma está cerrada. No porque la tecnología vaya a desaparecer, sino porque la brecha entre los equipos con plataformas y los que no las tienen se están piando rápidamente. Cada mes que esperas, los equipos que ya tienen plataformas se alejan más. Te llega más rápido, se agotan menos y se adaptan a nuevas herramientas con mayor rapidez. Su equipo sin plataformas se están quedando cada vez más atrás. La elección es tuya. Comienza con un camino ideal. Entonces, ¿por dónde empezar realmente? Si estás pensando que necesitas construir una plataforma interna para desarrolladores desde cero, detente. Esa es la forma más rápida de matar tu proyecto antes de que siquiera comienes. El error más grande que cometen los equipos es intentar construir todo a la vez.

Pasan meses diseñando la plataforma perfecta, incluyendo cada característica que se les ocurra. Luego la lanzan y no escuchan nada. Nadie la usa. ¿Por qué? Porque resuelve problemas que nadie planteó y solo empezar requiere leer un manual pequeño. La cuestión es, no hagas eso. Cambia, empieza poco a poco. Habla realmente con los desarrolladores, no con los arquitectos, ni los gerentes, ni con tus propias suposiciones. Busca a las personas que escriben funciones todos los días. Pregúnteles lo debe. Encuentra el flujo de trabajo que más tarda, que más frustra a la gente o que se omite más de lo que debería. Luego construye un único camino de lado de principio a fin. Quizás sea crear y desplegar un nuevo microservicio. Quizás sea configurar un entorno de desarrollo desde cero. Quizás sea enviar una corrección a producción sin romper nada. Elige el que más moleste y construye un camino que haga desaparecer ese dolor.

Constrúyelo. Pruébalo. Con usuarios reales. Recompila comentarios e itera. Luego agrega otro camino y otro más después de ese. No intenta resolver todos los problemas. Resuelve un problema muy bien y deja que el impulso te lleve hacia adelante. Como sabes que está funcionando, mide las cosas correctas. El tiempo desde la idea hasta el primer despliegue. La cantidad de pasos manuales eliminados y las tasas de adopción voluntaria. Si los desarrolladores eligen tu camino, en lugar de construir el suyo, vas ganando. Si lo evitan, escuche, cambia de dirección. Aquí está la trampa, evita. No hagas que la plataforma sea obligatoria. Obliga a los desarrolladores a seguir tu camino y se resentirán. Encontrarán formas de evitar. Crearán sus propios scripts y te los ocultarán. En cambio, haz que el camino sea fácil. Haz que sea más rápido que el alternativo. Haz que sea la opción obvia, pero nunca la única.

El primer camino es siempre el más difícil. Te enseña todo sobre el pensamiento del producto. Aprendes a hablar con los usuarios, a priorizar. Y que construir algo que la gente realmente quiere es mucho más difícil que construir algo que solo funciona. Pero una vez que lo has hecho una vez, el segundo camino se vuelve más fácil y el tercero aún más. No estás construyendo una plataforma de una sola vez. La estás construyendo un camino a la vez. Entonces, ese es este. La ingeniería de plataformas se trata de pavimentar el camino para que los desarrolladores puedan concentrarse en conducir en lugar de arreglar bachas. Si estás cansado de luchar contra la infraestructura, comienza encontrando un camino dorado en tu equipo solo uno. Comparte esto con alguien que necesite escucharlo y suscríbete para más análisis como este.