Recapacitación para el futuro: por qué los desarrolladores y los profesionales de la infraestructura necesitan escapar de sus zonas de confort

Matthew Finio: ¿Cómo está cambiando la relación entre los desarrolladores y los profesionales de la infraestructura?

Miha Kralj: Toda la profesión del desarrollo cambió con el surgimiento del “todo definido por software”: redes definidas por software, almacenamiento definido por software, computación definida por software.

En el pasado, teníamos a la gente de infraestructura a la izquierda y a la gente de desarrollo de software a la derecha y apenas se hablaban entre sí. Uno estaba atendiendo todas las tuberías y activos subyacentes, y el otro estaba haciendo toda la programación y haciendo realidad los sueños.

Ahora, todo eso se está derrumbando. Ninguna de las partes está preparada para la era en la que vivimos ahora. Y ninguno entiende la seguridad, así que podemos incorporar eso también. Necesitan empezar a aprender unos de otros, y es difícil para ambas partes.

Es como el libro Who Moved My Cheese: ninguna de las partes se siente muy cómoda si procede del viejo mundo tradicional. Las generaciones más jóvenes que crecieron con Gmail y YouTube viven en ese nuevo mundo combinado. Pero las personas que venían del lado tradicional de la infraestructura o del lado del desarrollo luchan porque no aprendieron el otro lado en los primeros años de su carrera.

MF: Entonces, ¿tanto los desarrolladores como la gente de infraestructura deberían repensar sus descripciones de trabajo?

MK: Exactamente. Los desarrolladores ya no deben pensar que son solo desarrolladores de aplicaciones. La gente de infraestructura ya no debería pensar que son solo personas de operaciones. Aquí se aplican las construcciones modernas de equipos de los entornos de ingeniería de productos, donde todos pueden hacer el trabajo de otra persona si es necesario. Todavía hay especializaciones, pero un desarrollador, cuando sea necesario, debe poder saltar y escribir algún script de Terraform, que tradicionalmente sería una tarea muy centrada en la infraestructura.

Entonces, cuando le preguntas a alguien cuál es su trabajo, no debería decir "Soy un desarrollador de software" o "Soy una persona de infraestructura/operaciones". Todos ellos construyen un producto o ayudan a crear un servicio y éste nunca se lanzará sin que todos esos elementos estén reunidos correctamente. Todo el mundo necesita comprender la cadena completa, el ciclo de vida completo, todo desde abajo hasta arriba.

MF: Usted mencionó Terraform. ¿Cuáles son algunos otros conceptos de infraestructura que los desarrolladores necesitan aprender?

MK: Con frecuencia, los desarrolladores no entienden exactamente cómo funciona realmente la infraestructura subyacente y qué puede ser duradero, qué puede ser efímero.

Si, por ejemplo, realiza algún cambio en el host o contenedor o componente sin servidor que está ejecutando algo, ¿ese cambio persistirá cuando ese componente, esa máquina virtual salte a otro lugar? Por lo tanto, el concepto de sistemas que almacenan sus estados en otro lugar, los sistemas sin estado, es uno de los precursores que los desarrolladores pueden comenzar a comprender. ¿Cómo hacerlo infinitamente escalable? ¿Cómo se crean sistemas muy duraderos y elásticos? Todos esos conceptos arquitectónicos se implementan en el software, pero en realidad se basan en patrones de infraestructura.

Además, vale la pena comprender todos los patrones de seguridad sobre cómo crear el área de superficie mínima en el código que tenga la menor posibilidad de ataque. Y cómo comunicarse adecuadamente con algún servicio lejano. ¿Va a escribir un pequeño servicio de chat que envíe cien pequeñas preguntas de chat por cable cada segundo? ¿O quiere empaquetar todas las peticiones y enviarlas en paquetes más grandes con menos frecuencia?

Estas son decisiones muy importantes que todo desarrollador de software debe tomar, pero no entenderán por qué las están tomando si no entienden lo que está sucediendo tras bambalinas: cómo funcionan los sistemas reales. Esa comprensión del sistema de abajo hacia arriba es crucial. El desarrollador necesita escribir un código bueno y limpio que no obstruya el sistema, que no bloquee la base de datos, que no haga cosas malas.

Si retrocedemos 20 o 30 años, teníamos una profesión dedicada que optimizaba las consultas de bases de datos para el número mínimo de ciclos requeridos por la CPU, la cantidad mínima de bloqueo de los datos. Gran parte de ese conocimiento arcano se pierde. Pero sigue siendo muy importante comprender cómo crear un sistema de alto rendimiento y cómo crear un sistema optimizado en cuanto a costos. Todas esas lecciones no deben olvidarse.

Está pensando: "¡Oye, estamos en 2025, vejestorio, siéntese! El mundo moderno es totalmente diferente. ¡No tiene ni idea! Bueno, nosotros construimos este mundo moderno, y estamos aquí para ayudar a los nuevos desarrolladores y a los encargados de las nuevas infraestructuras a utilizarlo de la forma más eficiente posible.

MF: ¿Puede describir algunas formas en que los desarrolladores pueden usar la infraestructura como herramientas de código para mejorar su flujo de trabajo?

MK: Sí. Un buen ejemplo sería cómo un desarrollador puede crear un flujo de trabajo adecuado para que su propio código se pruebe automáticamente y luego se compile y empaquete cada vez que cree un fragmento de código y lo confirme en un repositorio. Los desarrolladores no deberían necesitar que una persona de infraestructura haga eso por ellos. Crear un buen script YAML en GitHub es una tarea de infraestructura como código que cada desarrollador puede optimizar para que ese proceso sea lo más eficiente posible.

Entonces, por ejemplo, un desarrollador no necesita tener un paquete completo, una validación completa y pruebas completas si solo está sentado en la rama de desarrollo. Ese desarrollador dirá: "Oye, estoy en la rama de desarrollo, puedo ignorar todas esas 20 tareas que están destinadas solo a la rama de producción".

Pero si estás en producción, necesitas hacer un montón de automatización, poner en marcha la máquina que va a hacer la verificación de seguridad completa y la validación del código, etc. Todas esas pequeñas decisiones que van a influir en la rapidez con la que se realiza la compilación y en la rapidez con la que se ven los resultados luego de enviar el código: cada desarrollador debería poder cambiar la infraestructura a medida que escribe el código y adaptarla a su propio flujo de trabajo.

Es como si a esos mismos desarrolladores les gustara afinar su propio entorno de desarrollo integrado. Prefieren sus propias fuentes, colores, atajos de teclado y todo eso. También deben poder configurar sus propios flujos de trabajo, es decir, lo que sucede luego de confirmar con el código. Ese es todo el conocimiento que sale de IaC, la infraestructura como código.

MF: ¿Qué cosas específicas deben entender los profesionales de infraestructura sobre el desarrollo de aplicaciones hoy en día?

MK: Infraestructura como código (IaC) significa literalmente que las personas de infraestructura se están convirtiendo en programadores. La infraestructura se define con scripts, con datos, con código, lo que significa que el script o código de infraestructura debe pasar por el mismo ciclo de vida de desarrollo de software que cualquier código que escriben los desarrolladores:

• Es necesario que esté debidamente documentado.
• Debe almacenarse correctamente en un repositorio.
• Necesita ser versionado correctamente.

Debe tratarse exactamente de la misma manera. La gente de infraestructura tradicional no entendía esto ni era capaz de hacerlo. La gente de infraestructura puede configurar cosas, hacer clic con un clic del mouse y tal vez puedan escribir algunos scripts Bash o algo así.

Pero ahora se espera que los responsables de infraestructuras sean codificadores reales de infraestructura. Necesitan entender Git. Necesitan entender cómo hacer el escaneo de seguridad de su infraestructura como activos de código. Sus activos deben versionarse correctamente y van a ser revisados por pares, y necesitan entender qué es la solicitud de extracción. Todos estos son términos y actividades estándar que todo desarrollador de software conoce por defecto.

Los profesionales de infraestructuras necesitan convertirse en un paquete completo. Y los ingenieros full stack son difíciles de formar y de encontrar. Hay escasez de gente que entienda todo desde el principio, cómo fluyen los paquetes y cómo funciona la red y el núcleo del sistema operativo, hasta el final. Por ejemplo, ¿cómo escribo realmente múltiples dependencias de software? ¿Cómo utilizo paquetes de código abierto o internos? ¿Cómo escribo código asíncrono? Todas ellas son cuestiones de puro desarrollo de software. Dos enormes dominios colapsados en uno. La gestión del cambio y la recualificación del talento no están ahí.

MF: Si la recapacitación y la mejora de habilidades son un desafío, ¿cómo deben los profesionales de infraestructura mantenerse al día con las tendencias y tecnologías de desarrollo?

MK: Bueno, ya no hay personas específicas para la infraestructura ni personas específicas para los desarrolladores, todo eso se fusionó en un solo dominio. Todos están aprendiendo esas nuevas tendencias: cambios en el ciclo de vida del desarrollo de software y, especialmente, ahora los cambios con la IA.

A medida que avanzamos en un tipo de desarrollo nativo de IA, tanto las personas de infraestructura como los desarrolladores de aplicaciones deben aprenderlo. Todo el mundo sufre el efecto FOMO y piensa que ya está atrasado. Acaban de aprender a hacer ingeniería rápida y ahora se les dice que necesitan aprender a escribir agentes en Semantic Kernel o lo que sea.

Las personas necesitan ayudarse mutuamente, necesitan encontrar el equilibrio adecuado. ¿Cuánto tiempo debe dedicarse a mantenerse actualizado y saber que todavía tiene la vanguardia? Antes era del 5 %, ahora es del 10 %. La IA generativa ayuda. Pero esta relación entre cuánto tiempo se necesita para aprender y cuánto tiempo se aplica y se crea algo que proporciona valor empresarial o valor de TI se inclina cada vez más hacia el aprendizaje.

MF: Y antes de terminar, ¿cuáles son algunas cosas clave que los desarrolladores y profesionales de infraestructura deben tener en cuenta sobre las aplicaciones modernas?

MK: Ya no hay tareas divididas. Las aplicaciones modernas tienen una infraestructura casi integrada. Por ejemplo, un desarrollador moderno va a escribir un código y solicitar hacer un contenedor. No hay una persona de infraestructura que haga un contenedor para ellos. Algunos trabajos requieren un trabajo más centrado en la infraestructura, pero también en el desarrollo. Y algunos trabajos requieren más desarrollo de software, pero también conocimiento y acceso a la infraestructura.

Entonces, lo que los profesionales de la infraestructura deben considerar es convertirse en desarrolladores de software. Y lo mismo para los desarrolladores de software, deben convertirse en profesionales de la infraestructura.

Esos roles no están separados, se están fusionando. Es como hace una década o más, cuando todas las tiendas de desarrollo de software profesional tenían desarrolladores y probadores. Ya nadie habla de testers porque esos dos roles se fusionaron. Ese mismo tipo de colapso y fusión de roles, esta vez entre desarrolladores y gente de infraestructura, está ocurriendo ahora.