[10/06/2022] 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 costo 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.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Los desarrolladores no siempre ven la conexión. Es fácil escribir código en su propia máquina, donde la memoria RAM y el espacio extra en el disco se pagaron cuando se compró la máquina. Si tiene dos terabytes de espacio en el disco, puede que no se dé cuenta de cuánto 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 extra? 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 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 simple como ejecutar un perfilador para identificar puntos lentos, o evitar el almacenamiento de datos innecesarios para una menor huella de memoria.
Aquí hay 12 maneras de racionalizar su código para que sea más delgado, más rápido y más 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 su aplicación.
Reduzca su huella de RAM
La cantidad de RAM que se utiliza es un parámetro importante para la fijación de precios de las instancias en la nube. En muchos casos, duplicar la RAM también duplica el costo. 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 sus algoritmos. A veces, el sistema operativo empieza a descargar los datos en el disco utilizando la memoria virtual. Esto evita que se cuelgue, pero puede ralentizar mucho sus programas.
Utilizar imágenes y videos de menor resolución
Utilizar imágenes y vídeos de menor resolución puede ser rentable de múltiples maneras. En primer lugar, almacenarlas 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 ser evidente para los usuarios. Encontrar el equilibrio adecuado es una decisión de diseño que algunos programadores no están preparados para 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.
Descargue 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 tiene el hardware y la unidad de disco tiene mucho espacio. Pero la nube cobra por todo. ¿Realmente se necesitarán todos esos valores en el futuro? ¿Acaso el usuario quiere tantos datos? Deshacerse de algunos de esos datos antiguos le 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 solo 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 el mejor enfoque es utilizar el menor almacenamiento posible. Considere formas de minimizar no solo los archivos temporales que crea su aplicación, sino también las bibliotecas del sistema y los paquetes de software necesarios.
Limpie sus 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, no es necesario conservarlos todos. Toda la información extra atasca el disco local o el almacenamiento de objetos. Cuando diseñe el sistema de registro, configúrelo para que elimine 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 solo facturan cuando su código se está ejecutando, lo que puede ahorrarle mucho cuando las cargas son intermitentes. Incluso las aplicaciones que tienen un flujo constante de usuarios tienen más tiempo muerto de lo que cabría 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 solo por el tiempo que el procesador está ocupado. Como desarrollador, obtiene una respuesta inmediata porque puede rastrear el 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 su aplicación ejecuta algunas funciones solo ocasionalmente, puede tener sentido ir sin servidor.
Archivar los datos antiguos
A medida que los datos envejecen, se accede a ellos con menos frecuencia. Puede anticiparse a esto configurando su 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 se especializan en el almacenamiento de archivos para objetos de Amazon S3 y cobran mucho menos que las nubes principales. En algunos casos, ni siquiera cobran por la exfiltración de datos. Descargar los datos tan pronto como ya no tengan una gran demanda puede ser extremadamente rentable.
Simplifique sus diseños CSS
Si ha mirado las etiquetas HTML generadas por algunos frameworks, sabrá lo ridículas que pueden llegar a ser las composiciones. No son más que etiquetas DIV anidadas en 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% solo por crear un diseño más simple 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 solo algunas herramientas que empaquetan todo el contenido en un conjunto de archivos compactos e inmutables. Todavía se puede construir la personalización en las páginas con llamadas AJAX, pero el grueso del sitio genera poca carga en los servidores.
Externalizar la computación 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 más carga a la máquina del usuario y alejarla de sus 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 solo 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 costos
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 costos de la nube son tan flexibles, algunos equipos están nombrando oficialmente "ingenieros de costos" para gestionar los costos y la eficiencia del código. El primer objetivo de un ingeniero de costos 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 costos del código como parte del papel y la responsabilidad del equipo de desarrollo.
Basado en el artículo de Peter Wayner (InfoWorld) y editado por CIO Perú