Durante una discusión en el reciente evento Kubecon + Cloud Native Computing Foundation (CNCF) Europa 2025 en Londres, los miembros del panel discutieron una de las grandes críticas al desarrollo de software moderno: ¿por qué la implementación del código todavía está llena de problemas?
Cambiar a la izquierda, donde los desarrolladores asumen más responsabilidad por poner su código en producción parece haberse estancado en algunas organizaciones.
Kendall Roden, líder de productos tecnológicos en Diagrid, dijo que entre los grandes desafíos está el surgimiento de los sistemas distribuidos. Según Roden, esto significa que los desarrolladores ahora tienen mucho de lo que ella llamó “carga cognitiva adicional”. “Hay mucha responsabilidad nueva, como cómo hacer la resistencia cuando [the code] ya no funciona como un solo proceso ”, dijo.
En la experiencia de Roden, muchas organizaciones no tienen el equipo de la plataforma para ayudar a asumir estas responsabilidades. “Los desarrolladores son menos productivos; la experiencia DevOps se ha vuelto un poco hinchada y no hay una delineación clara de responsabilidad”, advirtió.
Si bien algunas organizaciones pueden adoptar la ingeniería de la plataforma para apoyar a los desarrolladores, sigue siendo un desafío para los desarrolladores poner el código en producción. Randy Bias, vicepresidente de estrategia y tecnología de código abierto en Mirantis, dijo que el objetivo de DevOps y prácticas como la ingeniería de la plataforma era romper los muros entre desarrolladores y operadores “para que todos pudieran operar como Google”.
El papel de la ingeniería de la plataforma es sentarse entre el personal de operaciones de TI y los desarrolladores de software, donde un equipo proporciona una plataforma, que generalmente se basa en Kubernetes. Esto, dijo, agrega una capa de abstracción y proporciona a los desarrolladores un camino hacia la producción.
Sin embargo, el sesgo agregó: “Si observa la empresa promedio, no tienen ninguna posibilidad en operar como Google. Los silos están tan aislados como siempre, y hay enormes barreras entre los desarrolladores y las personas de operaciones”. Señaló que los desarrolladores no quieren saber sobre la infraestructura de TI. “No les importa”, dijo Bias. “Quieren desarrollar sus aplicaciones y implementarlas mágicamente”.
La relación de Kubernetes con AI
Las cargas de trabajo de inteligencia artificial (IA) y aprendizaje automático (ML) representan algo completamente nuevo para el comité de Kubernetes, según Jago MacLeod, director de ingeniería de Google Cloud. “Esta nueva ronda de cargas de trabajo de IA y ML es realmente diferente a lo que las comunidades CNCF y Kubecon han construido hasta ahora”, dijo.
AI y ML son grandes cargas de trabajo de entrenamiento. En el mundo de Kubernetes, las cargas de trabajo se implementan en vainas, pero dado el tamaño de las cargas de trabajo AI y ML. MacLeod dijo que esto significa usar una cápsula por nodo. “Si algún de los nodos se detiene, debe obtener otro en su lugar y luego reiniciar [the workload] Desde un punto de control “, dijo.” Estos nuevos tipos de cargas de trabajo no son muy tolerantes a las fallas “.
Según MacLeod, otro desafío es el hecho de que los investigadores de IA que trabajan con modelos de la Fundación AI tienden a programar utilizando Python.
“Muchos provienen de la academia y escriben el código Python, que no es lo que llamaríamos código elegante en ingeniería de software, y no hay fuente [code] Control ”, dijo, y agregó que los investigadores de IA intentan distribuir estas cargas de trabajo de Python en decenas de miles de nodos.
“Es un modelo mental completamente diferente en comparación con nuestra forma preferida, con las operaciones de TI, y lo revisa en la fuente y luego eso se extiende de manera controlada; es un mundo muy diferente”, dijo MacLeod.
AI y ML presentan problemas muy diferentes a otras cargas de trabajo de Kubernetes. Roden dijo que en el espacio de IA, debe haber un cambio en la mentalidad entre los desarrolladores para mejorar su comprensión de cómo pueden trabajar con AI. “No necesariamente sé si la escala de uso del desarrollador empresarial promedio está realmente allí, porque es bastante complejo y requiere un conjunto de habilidades diferentes, un enfoque diferente y un conjunto diferente de infraestructura”, agregó.
El sesgo fue más allá, y agregó: “La gente no se da cuenta de que estas son cargas de trabajo HPC”, refiriéndose al hecho de que AI y ML comparten problemas similares a la supercomputación. Dijo que el problema de la resistencia de la IA y ML era el mismo tipo de problema que los centros de supercomputación han estado abordando durante décadas. “No tenemos que reinventar la rueda”, dijo Bias. “Solo tenemos que regresar y tomar ese conocimiento que ha estado en el nicho de HPC”.
Presión global
Más allá de escribir y administrar el código, entre las preguntas formuladas durante el panel de discusión, se observó cómo la tensión geopolítica estaba afectando el código abierto y la Fundación Linux. “Hay una tonelada de peligros y dificultades frente a nosotros”, dijo Bias.
En el evento CNCF en Hong Kong, dijo que los presentadores eran todos oradores mandarín que discutían proyectos que se desarrollaban en China. “Existe un peligro de fraccionamiento regional”, dijo Bias.
Pero si bien, desde una perspectiva geopolítica, el código abierto tiende a ser neutral y la comunidad trata de operar a través de las fronteras internacionales, la política puede influir en esta apertura.
“Hay realidades geopolíticas para una organización como la Fundación Linux porque opera principalmente dentro de los Estados Unidos”, dijo, refiriéndose a la decisión de la Fundación Linux en noviembre de 2024 para excluir una cohorte de mantenedores de kernos rusos de Linux.
El sesgo sugirió que, dado que se basa en los EE. UU., La Fundación Linux ya no está bien ubicada para supervisar la comunidad global de código abierto. En cambio, dijo que lo que se necesita es una Nación Unida para el código abierto que opera en una región geográficamente neutral.