12 trucos de programación que utilizan los desarrolladores para reducir la factura de la nube

Nada levanta más el ánimo de un equipo de desarrollo que ver cómo una aplicación se vuelve viral. Es una sensación maravillosa, al menos hasta que llega la factura mensual de la nube.

Algunos desarrolladores creen que la gestión del coste de la informática es responsabilidad del equipo de desarrollo. Los codificadores escriben el software, lo lanzan por encima de la pared y dejan que otro se preocupe de pagarlo. Nada más lejos de la realidad.

Los desarrolladores inteligentes saben que sus decisiones de codificación marcan una gran diferencia en los resultados de la empresa. El código voluminoso es más lento y requiere más recursos en la nube para ejecutarse. Elegir mejores algoritmos y escribir un código más ajustado es algo más que la velocidad. El código bien escrito cuesta menos de ejecutar.

Los desarrolladores no siempre ven la conexión. Es fácil escribir código en su propia máquina, donde la RAM y el espacio de disco extra se pagaron cuando se compró la máquina. Si tienen dos terabytes de espacio en disco, puede que no se den cuenta de la cantidad que consume su código.

Si un nuevo algoritmo tarda el doble en ejecutarse, es posible que su escritorio ni siquiera parpadee y, además, ¿quién se da cuenta de unos milisegundos más? Pero es casi seguro que duplicar el cálculo se traducirá en una mayor factura en la nube.

La computación en nube moderna es excelente para convertir la utilización de los recursos en un cargo de línea. Los buenos desarrolladores de la nube entienden que tienen el poder de tomar decisiones más inteligentes al escribir su código. Puede ser tan sencillo como ejecutar un perfilador para identificar los puntos lentos, o evitar el almacenamiento de datos innecesarios para una menor huella de memoria.

 

He aquí 12 formas en las que los desarrolladores racionalizan el código para que sea más ágil, más rápido y barato de ejecutar.

 

Escribir código más rápido

La mayoría de los desarrolladores no dedican mucho tiempo a optimizar su código. Si se ejecuta en una fracción de segundo en su portátil, no se dan cuenta de si se está ejecutando un 20%, un 30% o incluso un 300% más lento con el tiempo. El programa sigue respondiendo en fracciones de segundo. Pero estas diferencias se acumulan cuando se producen millones de veces en el servidor. Un perfil cuidadoso puede señalar las partes lentas. Reescribirlas podría reducir el número de instancias que necesita una aplicación.

 

Menor huella de RAM

La cantidad de RAM que se utiliza es un parámetro importante para fijar el precio de las instancias en la nube. En muchos casos, duplicar la RAM también duplica el coste. Los programadores pueden reducir su huella de RAM evitando mantener los datos en la memoria.

Algunos algoritmos de streaming, como las clases Stream de Java, están diseñados para trabajar con grandes archivos de datos sin cargarlos todos en la memoria. El proyecto Apache DataSketches genera respuestas aproximadas para estadísticas complejas de Big Data sin ocupar toda la memoria.

Como beneficio secundario, un consumo cuidadoso de la RAM también puede acelerar los algoritmos. A veces, el sistema operativo empieza a descargar los datos en el disco utilizando la memoria virtual. Esto evita el bloqueo, pero puede ralentizar drásticamente los programas.

 

Utilizar imágenes y vídeos de menor resolución

Utilizar imágenes y vídeos de menor resolución puede ser rentable de varias maneras. En primer lugar, su almacenamiento será más barato. En segundo lugar, cualquier cargo por exfiltración de datos será menor. En tercer lugar, la aplicación parecerá más ágil a los usuarios.

Todas las imágenes estáticas deberían minimizarse desde el principio. La cantidad de minimización, por desgracia, no es sencilla porque en algún momento la calidad visual se degrada lo suficiente como para que sea evidente para los usuarios. Encontrar el equilibrio adecuado es una decisión de diseño que algunos programadores no están dispuestos a tomar.

Algunas aplicaciones que utilizan imágenes cargadas también pueden crear miniaturas más pequeñas y versiones de resolución reducida después de recibir la imagen. Para ello se han desarrollado kits de herramientas como ImageMagik y formatos como WebP.

 

Deshágase de los datos innecesarios

Muchos desarrolladores son ratas digitales que almacenan información por si acaso la necesitan algún día. Llenan tablas con infinitas columnas y luego nunca borran las filas. Los datos extra no cuestan nada si tienen el hardware y la unidad de disco tiene mucho espacio. Pero la nube cobra por todo.

¿Realmente necesitarán todos esos valores en el futuro? ¿Acaso el usuario quiere tantos datos? Deshacerse de algunos de esos datos antiguos permitirá ahorrar dinero en el almacenamiento de datos y en la exfiltración.

 

Limitar el almacenamiento en disco

Utilizar el disco local en las instancias en la nube no sólo es peligroso, sino que puede resultar caro. El espacio del disco local suele estar diseñado para ser lo suficientemente rápido como para mantener el sistema operativo funcionando de forma eficiente. Muchos desarrolladores crean su código en una máquina personal con uno o más terabytes de almacenamiento.

El almacenamiento en máquinas en la nube rara vez es tan barato o está disponible. Las nubes suelen facturar directamente el almacenamiento en función del tamaño, por lo que lo mejor es utilizar el menor almacenamiento posible. Considera formas de minimizar no sólo los archivos temporales que crea la aplicación, sino las bibliotecas del sistema y los paquetes de software necesarios.

 

Limpiar los registros

Los archivos de registro son excelentes para identificar problemas y depurar el software durante el desarrollo. Pero una vez que el código está en producción, los desarrolladores no necesitan conservarlos todos. Toda la información extra atasca el disco local o el almacenamiento de objetos. Cuando diseñen el sistema de registro, configúrenlo para eliminar los registros con frecuencia. Muchos paquetes de registro, como Log4j, pueden configurarse para mantener un número mínimo de registros y eliminarlos de forma continua.

 

Ir sin servidor

Los planes de arquitectura sin servidor sólo facturan cuando el código se está ejecutando, lo que puede ahorrar mucho a los desarrolladores cuando las cargas son intermitentes. Incluso las aplicaciones que tienen un flujo constante de usuarios tienen más tiempo muerto de lo que podrían esperar.

Muchos planes de precios sin servidor recompensan una codificación cuidadosa y un rendimiento muy rápido con un consumo mínimo de RAM. La fórmula de facturación cuenta el tiempo de respuesta en milisegundos y cobra sólo por el tiempo que el procesador está ocupado. Los desarrolladores obtienen información inmediata, ya que pueden hacer un seguimiento del tiempo de respuesta directamente y ver cómo sus cambios de código lo afectan.

El enfoque sin servidor es ideal para proyectos más pequeños o experimentales y la factura puede ser a menudo tan baja como unos pocos céntimos al mes. Si una aplicación ejecuta algunas funciones sólo ocasionalmente, puede tener sentido ir sin servidor.

 

Archivar los datos antiguos

A medida que los datos envejecen, se accede a ellos con menos frecuencia. Pueden anticiparse a esto configurando la aplicación para que migre los datos antiguos a una ubicación más barata. Algunas nubes cobran mucho menos por el llamado "almacenamiento en frío", que puede tardar minutos o incluso horas en entregar los bits.

Otras nubes, como Wasabi o Backblaze, están especializadas en el almacenamiento de archivos para objetos de Amazon S3 y cobran mucho menos que las principales nubes. En algunos casos, ni siquiera cobran por la exfiltración de datos. Descargar los datos tan pronto como dejen de tener una gran demanda puede ser extremadamente rentable.

 

Simplificar los diseños CSS

Si han mirado las etiquetas HTML generadas por algunos frameworks, saben lo ridículo que pueden llegar a ser los diseños. No son más que etiquetas DIV anidadas dentro de etiquetas DIV hasta el final, lo que cuesta dinero generar y entregar. Un diseñador web que conozco se jacta de haber reducido su factura de ancho de banda en un 30% sólo por haber creado un diseño más sencillo con un uso más juicioso de CSS.

 

Construir sitios estáticos

Algunos frameworks como React requieren bastante potencia de cálculo, especialmente si utilizan funciones como la renderización del lado del servidor. Todo ese código eleva la factura mensual de la nube. La filosofía opuesta es crear un sitio estático, construido a partir de bloques invariables de HTML, CSS y JavaScript que se sirven desde una caché al pie de la letra. El uso de una red de distribución de contenidos puede acelerar aún más la entrega al acercar las cachés al usuario.

Varios frameworks adoptan esta filosofía estática. Jekyll, Hugo, Gridsome y Pelican son sólo algunas herramientas que empaquetan todo el contenido en un conjunto de archivos compactos e inmutables. Todavía pueden incorporar la personalización en las páginas con llamadas AJAX, pero el grueso del sitio genera poca carga en los servidores.

 

Externalizar el cálculo y el almacenamiento

A medida que los navegadores se vuelven más potentes, algunos marcos de trabajo simplifican el traslado de más cálculos directamente al cliente. Un buen código JavaScript o WebAssembly puede trasladar una mayor parte de la carga a la máquina del usuario y alejarla de los servidores en la nube.

Algunos desarrolladores están reduciendo su capa de nube a ser poco más que una base de datos con un poco de lógica de negocio para la autenticación. Un amigo ejecuta todo con HTML estático y una versión del lado del servidor de PostgreSQL con procedimientos incrustados que dan salida a JSON.

Los navegadores también tienen opciones más elaboradas para almacenar información localmente, como el estándar HTML Web Storage y la API de base de datos indexada del W3C. Ya no se trata sólo de cadenas cortas y cookies. Estos datos están disponibles más rápidamente porque no viajan por Internet, y da a los usuarios cierta comodidad al saber que sus datos no están almacenados en una base de datos centralizada y hackeable. ¿Por qué pagar por el almacenamiento y la exfiltración de datos cuando pueden vivir en la máquina del usuario de forma gratuita?

 

Nombrar a un ingeniero de costes

Algunos desarrolladores se especializan en el cuidado de las bases de datos. A otros les gusta crear bellas primeras impresiones con un front-end bien diseñado. Ahora que los costes de la nube son tan flexibles, algunos equipos están nombrando oficialmente "ingenieros de costes" para gestionar los costes y la eficiencia del código.

El primer objetivo de un ingeniero de costes es conseguir que el código de la aplicación funcione de forma más limpia, más rápida, más ligera y, por tanto, más barata. Hacer que esta tarea forme parte del trabajo de alguien envía un mensaje sobre la importancia de gestionar los costes del código como parte del papel y la responsabilidad del equipo de desarrollo.