El desarrollo de la nube genera datos basura que deben ser eliminados

  • Software y Apps

A medida que los programadores trabajan en nuevos proyectos experimentales de software para la nube se van generando fragmentos de código residuales que ocupan espacio y recursos sin aportar nada. Por ello, se está instalando una corriente de opinión entre la industria que aboga por una mayor limpieza en el desarrollo de servicios y aplicaciones para la nube.

Como sucede en el mundo real, en el campo del desarrollo de software se generan residuos, que en este caso adoptan la forma de fragmentos de código y servicios que están parcial o totalmente operativos, consumiendo recursos de las plataformas donde se encuentran. Este problema se ha trasladado a los entornos de la nube, donde los microservicios se han convertido en la norma, y la comunidad de desarrolladores lanza constantemente proyectos de servicios que en muchos casos quedan en desuso.

Esto está haciendo que los entornos de la nube sufran con más intensidad ese problema de acumulación de “basura”, como explica en un reciente artículo publicado por Adrian Bridgewater, colaborador senior de Forbes. Aquí destaca que se está fomentando una corriente de opinión entre la comunidad de desarrolladores que aboga por una mayor limpieza de los entornos de desarrollo para la nube.

Alude a las opiniones expresadas por la destacada programadora Nočnica Fee, perteneciente a la firma de desarrolladores New Relic, dedicada al desarrollo de aplicaciones para la nube. En su opinión, a medida que se avanza en el desarrollo y la experimentación de nuevos microservicios, en forma de prototipos, el problema de acumulación de “código desechable” se hace más patente, y los programadores deberían poner más énfasis en la eliminación de código y servicios que ya no se utilizan.

Como explicó Fee, “la disposición es una mala palabra en la industria y la fabricación. El objetivo de todos los productos nuevos, al parecer, es reducir la cantidad de artículos de un solo uso. En el desarrollo de software y la operación de sistemas (DevOps), sin embargo, parece ser lo contrario. Los microservicios más pequeños creados para llenar nichos pequeños y el prototipado fácil significan que una gran parte del código que implementamos está destinado a ser desechado después de un espacio de tiempo relativamente corto”.

Bridgewater explica que cuando se pasa de una aplicación monolítica a microservicios el problema suele ser menor, y lo verdaderamente problemático surge cuando se deja en desuso un microservicio al completo. En este caso, Fee señal que el problema se convierte en serio, porque se crean agujeros de seguridad, se complica innecesariamente el mapa de servicios de computación en la nube, agregando nodos que nadie necesita, usa o comprende.

Y afirma que “básicamente se reduce a una cuestión de agilidad en cuanto a si un equipo de software puede o no pasar de un servicio que ya no tiene sentido para las necesidades para las que se implementó originalmente. Pero, independientemente, es vital identificar los servicios que ya no se utilizan y eliminarlos de nuestros sistemas. De lo contrario, introducen agujeros de seguridad, versiones deficientes y todos los demás problemas de los viejos tiempos de las arquitecturas monolíticas”.

Para combatir el problema, hay que comprender que actualmente los equipos de desarrollo de software y microservicios para la nube suelen ser pequeños y no se preocupan de controlar toda la arquitectura. Y, por ello, las organizaciones dedicadas al desarrollo de software en la nube deberían destinar recursos técnicos y humanos para monitorizar y controlar lo que sucede a mayor escala, incluido el problema del “código basura”.

Explica que uno de los problemas es que los desarrolladores se centran en los problemas que generan costos, pero esta basura digital no genera un costo apreciable a simple vista, por lo que no se le da la debida importancia. Por ello, los expertos afirman que se debe implementar otra forma de observabilidad de la computación en la nube, que se considere aspectos más allá de los costes directos, y que no se vea afectado por el componente emocional de los desarrolladores, que se resisten a que su código desaparezca, aunque ya no sea útil.