Reciclaje profesional para el futuro: por qué los desarrolladores y los profesionales de las infraestructuras necesitan escapar de sus zonas de confort

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

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.

Antes teníamos a los encargados de infraestructuras a la izquierda y a los de desarrollo de software a la derecha, y apenas se hablaban. Uno se encargaba de toda la fontanería y los activos subyacentes, y el otro de la codificación y de hacer realidad los sueños.

Ahora, todo eso se está derrumbando. Ninguna de las partes está preparada para la época en la que vivimos. 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 los encargados de la infraestructura deberían replantearse sus descripciones de trabajo?

MK: Exacto. Los desarrolladores ya no deben pensar que son solo desarrolladores de aplicaciones. Los profesionales de infraestructuras ya no deberían pensar que son solo gente de operaciones. Aquí se aplican las construcciones modernas de trabajo en equipo de los entornos de ingeniería de productos, donde todos pueden hacer el trabajo de otra persona si es necesario. Sigue habiendo especializaciones, pero un desarrollador, cuando es necesario, tiene que ser capaz de lanzarse a escribir algún script de Terraform, lo que tradicionalmente sería una tarea muy centrada en la infraestructura.

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

MF: Ha mencionado Terraform. ¿Qué otros conceptos de infraestructura deben aprender los desarrolladores?

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, el contenedor o el 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 empezar a entender. ¿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 bajo el capó: 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 nos remontamos a 20 o 30  años atrás, teníamos una profesión dedicada a optimizar 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. Muchos de esos conocimientos arcanos se pierden. Pero sigue siendo muy importante entender cómo crear un sistema de alto rendimiento y cómo crear un sistema optimizado en costes. 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 utilizar 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, a continuación, se compile y empaquete cada vez que cree un fragmento de código y lo envíe a un repositorio. Los desarrolladores no deberían necesitar que el encargado de la infraestructura lo hiciera por ellos. Hacer un buen script YAML en GitHub es una tarea de infraestructura como código que todo desarrollador puede optimizar para que ese proceso sea lo más eficiente posible.

Así, por ejemplo, un desarrollador no necesita tener un empaquetado completo, una validación completa y pruebas completas si solo se encuentra 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á en producción, necesita 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 afectar a la rapidez con la que se realiza la compilación y a la rapidez con la que se ven los resultados después de confirmar el código, cada desarrollador debería ser capaz de cambiar la infraestructura como scripts de código y adaptarla a su propio flujo de trabajo.

Es como cuando a esos mismos desarrolladores les gusta afinar su propio entorno de desarrollo integrado. Prefieren sus propias fuentes, colores, atajos de teclado y todo eso. También deberían poder configurar sus propios flujos de trabajo: qué sucede después de comprometerse con el código. Todo eso es conocimiento que surge de IaC, infraestructura como código.

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

MK: La 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 escriban los desarrolladores:

• Debe documentarse adecuadamente.
• Debe almacenarse correctamente en un repositorio.
• Es necesario tener la versión correcta.

Debe tratarse exactamente de la misma manera. Los profesionales de las infraestructuras tradicionales no lo entendían o no eran capaces de hacerlo. Los encargados de la infraestructura pueden configurar cosas, hacer clic a través de un ratón, 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 full stack. 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 el reciclaje y la mejora de las competencias suponen un reto tan grande, ¿cómo deberían los profesionales de las infraestructuras mantenerse al día de las tendencias y tecnologías de desarrollo?

MK: Bueno, ya no hay profesionales dedicados a la infraestructura y profesionales dedicados al desarrollo, todo se ha fusionado 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 la IA, tanto los encargados de las infraestructuras 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 prompt engineering y ahora se les dice que tienen que aprender a escribir agentes en Semantic Kernel o qué sé yo.

Las personas necesitan ayudarse unas a otras, necesitan encontrar el equilibrio adecuado. ¿Cuánto tiempo hay que dedicar a mantenerse al día y saber que se sigue a la vanguardia? Antes era el 5 %, ahora es el 10 %. La IA generativa ayuda. Pero esta relación entre la cantidad de tiempo que necesita aprender y la cantidad de tiempo que aplica y hace algo que proporciona valor de negocio o de TI se está inclinando cada vez más hacia el aprendizaje.

MF: Y antes de terminar, ¿cuáles son las principales cosas que los desarrolladores y los profesionales de la 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 la creación de un contenedor. No hay ningún profesional de infraestructuras que haga un contenedor para ellos. Algunos trabajos requieren más trabajo centrado en la infraestructura, pero también en el desarrollo. Y algunos trabajos requieren más desarrollo de software, pero también conocimientos y acceso a la infraestructura.

Por lo tanto, lo que los profesionales de infraestructuras deben tener en cuenta es convertirse en desarrolladores de software. Y lo mismo ocurre con los desarrolladores de software, que 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 profesionales de desarrollo de software tenían desarrolladores y testers. 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 encargados de la infraestructura, está ocurriendo ahora.