Software ecológico para la construcción

Capítulo 1. Introducción al Software Ecológico

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

No te gustaría verme cuando estoy enfadada.

Dr. Bruce Banner, científico verde

Podemos entender por qué los activistas están enfadados. Pocas industrias se han movido lo suficientemente rápido para apoyar la transición energética, y eso incluye al sector tecnológico.

Pero estamos empezando a cambiar.

¿Qué significa ser ecológico en TI?

Según la Green Software Foundation (GSF), la definición de software verde (o software sostenible) es el software que provoca emisiones mínimas de carbono cuando se ejecuta. Dicho de otro modo:

• El software ecológico está diseñado para requerir menos energía y hardware por unidad de trabajo. Esto se conoce como eficiencia del carbono, partiendo de la base de que tanto la generación de energía como la construcción de hardware tienden a producir emisiones de carbono.

• El software ecológico también intenta desplazar sus operaciones, y por tanto su consumo de energía, a momentos y lugares en los que la electricidad disponible procede de fuentes con bajas emisiones de carbono, como la eólica, la solar, la geotérmica, la hidráulica o la nuclear. Alternativamente, intenta hacer menos en los momentos en que la electricidad disponible en la red es intensiva en carbono. Por ejemplo, podría reducir su calidad de servicio en medio de una noche sin viento cuando la única energía disponible se esté generando a partir del carbón. Esto se denomina conciencia del carbono.

Ser eficiente energéticamente, eficiente con el hardware y consciente de las emisiones de carbono son los principios fundamentales de la informática verde (ver Figura 1-1).

Figura 1-1. Definición de software ecológico de la Fundación del Software Ecológico

Ahora que sabemos qué es el software ecológico, ¿cómo podemos crearlo?

Lo que pensamos

Este libro consta de 13 capítulos técnicos:

1. Introducción al software ecológico

2. Bloques de construcción

3. Código Eficiencia

4. Eficiencia operativa

5. Conciencia del carbono

6. Eficiencia del hardware

7. Red

8. Aprendizaje automático, IA y LLM más ecológicos

9. Medición

10. Monitoreo

11. Co-beneficios

12. La Matriz de Madurez del Software Verde

13. ¿Adónde vamos ahora?

Ahora te hablaremos de cada uno de los próximos capítulos y te daremos los puntos clave.

Capítulo 2: Bloques de construcción

Antes de entrar en materia, hay algo que todo el mundo en el sector tecnológico sabe que es esencial comprender sobre cualquier nuevo problema: la jerga.

En el Capítulo 2, "Bloques de construcción", explicamos qué significa realmente toda la palabrería sobre el clima, empezando por el carbono. A lo largo de este libro, utilizamos el carbono como abreviatura para describir todos los gases de efecto invernadero, que son todos los gases de la atmósfera que atrapan el calor. La mayoría son de origen natural, pero su sobreabundancia debida a las actividades humanas hace que tengamos que luchar contra el aumento de la temperatura global para evitar esos molestos desastres climáticos catastróficos.

A continuación, trataremos en algunos conocimientos que deberías tener en el bolsillo trasero, listos para convencer a amigos y colegas de la importancia de construir soluciones climáticas. Repasaremos la diferencia entre clima y tiempo atmosférico, cómo el calentamiento global contrasta con el cambio climático y cómo la comunidad internacional lo monitorea todo. También veremos cómo se aplican los protocolos de gases de efecto invernadero (es decir, las emisiones de alcance 1, 2 y 3) a los sistemas de software.

El siguiente componente básico que vamos a tratar es la electricidad. La mayoría de nosotros estudiamos electricidad en la escuela, y si aún recuerdas esa época, puedes saltarte esta sección. Para el resto de nosotros que necesitamos un repaso (como los autores), repasaremos los conceptos básicos de electricidad y energía y cómo se relacionan con el software. También repasaremos brevemente la producción de energía y compararemos y contrastaremos las fuentes de energía con alto y bajo contenido en carbono.

El último componente que vamos a repasar es el hardware. Probablemente te preguntes por qué tú -digamos un desarrollador web- necesitas aprender algo sobre hardware. TL;DR. Pero lo necesitas.

El hardware es esencial para todas las cosas del software, y todo el hardware tiene carbono asociado, incluso antes de que empiece a ejecutar tu aplicación. El carbono incorporado, a menudo denominado carbono incorporado, es el carbono emitido durante la creación y eventual destrucción de una pieza de equipo.

En 2019, Apple informó de que el 85% de las emisiones de carbono durante la vida útil de un iPhone se producen durante las fases de producción y eliminación del dispositivo. Se trata de una cifra que todos debemos tener en cuenta a la hora de diseñar, desarrollar e implementar software. Tenemos que hacer que esta inversión en carbono funcione mejor, por lo que la longevidad del dispositivo del usuario es importante.

Pero, ¿qué ocurre con otros dispositivos, como los servidores? ¿Qué debemos tener en cuenta al implementar una aplicación en un centro de datos local (on-prem) o en la nube? La buena noticia es que en los centros de datos gestionados profesionalmente, el hardware de los servidores se gestiona más estrictamente y trabaja mucho más que los dispositivos de los usuarios. Como usuarios de centros de datos, es de la electricidad de lo que debemos preocuparnos.

Capítulo 3: Eficacia del código

En el Capítulo 3, "Eficiencia del código", explicamos cómo la electricidad que necesita una aplicación para funcionar es aproximadamente una función de la cantidad de CPU/GPU que utiliza o que indirectamente hace que se utilice. Por tanto, reducir los requisitos de procesamiento de un software es clave para reducir su consumo de energía y las emisiones de carbono. Una forma de hacerlo es mejorando la eficiencia de su código.

Sin embargo, la pregunta que debemos hacernos es: ¿la eficiencia del código mueve realmente el dial verde o es una dolorosa distracción? De hecho, ¿es el concepto más controvertido del software verde?

La eficiencia del código es complicada

El problema de la eficiencia del código es que, aunque reducir el uso de la CPU/GPU puede tener potencialmente un enorme impacto en las emisiones de carbono y se conoce bien -las mismas técnicas se han utilizado durante muchas décadas en la informática de alto rendimiento (HPC)-, supone un gran esfuerzo para los ingenieros.

Puede que consigas centuplicar las emisiones de carbono cambiando, por ejemplo, de Python a un lenguaje mucho más eficiente como Rust, pero habrá que pagar un precio en productividad.

En realidad, los desarrolladores entregan mucho más rápido cuando utilizan lenguajes menos eficientes para la máquina, como Python. Como resultado, escribir código eficiente es poco atractivo para las empresas, que quieren dedicar el tiempo de sus desarrolladores a crear nuevas funciones, no a escribir código más ágil. Eso puede convertirlo en una venta imposible.

Por suerte, hay opciones de eficiencia del código que están alineadas con los objetivos empresariales de velocidad. Entre ellas están:

• Utilizar servicios gestionados

• Utilizar mejores herramientas, bibliotecas o plataformas

• Sólo ser más delgado y hacer menos

Utilizar servicios gestionados

Más adelante en este libro, hablaremos de las ventajas reales de eficiencia operativa que se derivan de los servicios gestionados en la nube y en línea. Tales servicios pueden compartir su plataforma y recursos entre millones de usuarios, y pueden lograr una utilización extremadamente alta del hardware y la energía. Sin embargo, sospechamos que su mayor ganancia potencial proviene de la eficiencia del código.

La premisa comercial de un servicio gestionado es sencilla: una empresa que tiene la escala y la demanda que lo justifican realiza la enorme inversión necesaria para que su funcionamiento y su código sean eficientes. Irritantemente, esa empresa luego gana mucho dinero con el servicio porque su funcionamiento es más barato. Sin embargo, tú obtienes eficiencia de código sin tener que invertir en ello.

Admitámoslo: es un trato atractivo.

Elegir las herramientas, bibliotecas y plataformas adecuadas

La alternativa local más eficiente a un servicio gestionado debería ser una biblioteca o producto de código abierto bien optimizado. El problema es que la mayoría no ha dado prioridad a la eficiencia energética hasta ahora. Como consumidores de código abierto, tenemos que empezar a exigirles que lo hagan.

Hacer menos

El código más eficaz es no tener código.

Si no te apetece reforzar el saldo bancario de un hiperescalador utilizando uno de sus servicios preoptimizados, una alternativa atractiva es hacer menos. Según Adrian Cockcroft, ex vicepresidente de Arquitectura Sostenible de AWS, "la mayor ganancia suele ser cambiar los requisitos o los SLA [acuerdos de nivel de servicio]". Reducir el tiempo de retención de los archivos de registro. Relaja los objetivos sobreespecificados".¹

El mejor momento para detectar el trabajo innecesario es al principio del proceso de diseño del producto, porque una vez que has prometido un SLA o una característica a alguien, es más difícil dar marcha atrás. A veces, los objetivos sobreespecificados (normativas que hay que cumplir, por ejemplo) son inevitables, pero a menudo, están impulsados internamente más que en respuesta a presiones externas o a auténticas necesidades de los usuarios. Si ése es el caso de tu organización, pide a tu jefe de producto que los deje de lado hasta que sepas que los necesitas.

¿Y si realmente no puedes comprarlo o dejarlo y tienes que construirlo?

Si realmente tienes que hacerlo tú mismo, existen múltiples opciones para los trabajos con mucha CPU que deben ejecutarse en momentos de gran intensidad de carbono:

• Sustituye el código personalizado ineficiente por servicios o bibliotecas eficientes.

• Sustituye los servicios o bibliotecas ineficaces por otros mejores.

• Reescribe el código para utilizar una plataforma, marco o lenguaje más ligero. Se sabe que pasar de Python a Rust multiplica por cien los requisitos de la CPU, por ejemplo, y Rust tiene ventajas de seguridad sobre las opciones más clásicas de eficiencia del código de C o C++.

• Busca nuevas alternativas de lenguaje como Cython o Mojo, que pretenden combinar la velocidad de C con una mejor usabilidad.

• Considera la posibilidad de enviar trabajo a los dispositivos cliente cuando la batería local tenga alguna esperanza de haberse cargado de forma renovable. (Sin embargo, esto tiene matices. Si implica transmitir una carga de datos extra, o anima al usuario a actualizar su dispositivo, o el trabajo es algo que tu centro de datos tiene el hardware para manejar con mayor eficacia, entonces enviarlo a un dispositivo puede ser peor. Como siempre, el diseño requiere reflexión y probablemente la participación de la gestión de productos).

• Asegúrate de que tus políticas de almacenamiento de datos son frugales. Las bases de datos deben optimizarse (hay que minimizar los datos almacenados y afinar las consultas).

• Evita el uso excesivo de capas. Por ejemplo, utilizar algunas mallas de servicio puede ser como minar Bitcoin en tus servidores.

Considera el contexto

Ofrecer software eficiente energéticamente es mucho trabajo, así que centra tu atención en las aplicaciones que importan porque tienen mucho uso y tienen que estar siempre encendidas.

"La escala importa", dice Paul Johnston, activista de la campaña climática . "Si estás construyendo un servicio en la nube a gran escala, exprime todo lo que puedas tu lenguaje de programación. Si estás construyendo una herramienta interna utilizada por cuatro personas y el perro de la oficina, a menos que vaya a utilizar 10 MWh de electricidad, es irrelevante".²

Verde por diseño

Los sistemas de software pueden diseñarse de forma que sean más conscientes de las emisiones de carbono, o más eficientes energéticamente, o más eficientes desde el punto de vista del hardware, y el impacto de un mejor diseño a menudo eclipsa el efecto de cómo están codificados. Sin embargo, nada de esto es gratis.

Ser ecológico significa pensar y revisar constantemente tu diseño, en lugar de dejarlo evolucionar. Así que es hora de desempolvar esa pizarra y sacar ese bolígrafo verde, que por suerte es probablemente el único al que le queda tinta.

Capítulo 4: Eficacia operativa

Tratamos la eficacia operativa en el Capítulo 4, "Eficacia operativa", que es posiblemente el capítulo más importante del libro.

Laeficiencia operativa consiste en conseguir el mismo rendimiento con menos máquinas y recursos. Esto puede reducir potencialmente las emisiones de carbono entre cinco y diez veces, y es relativamente sencillo porque, como veremos más adelante, ya existen servicios y herramientas de apoyo a la eficiencia operativa, sobre todo en la nube.

Sin embargo, no te sientas excluido si estás alojado on prem. Muchas de las técnicas, como la alta utilización de las máquinas, las buenas prácticas operativas y el multiarrendamiento, también pueden servirte.

Alta utilización de la máquina

La principal forma operativa de reducir las emisiones por unidad de trabajo útil es reducir la inactividad. Tenemos que hacer funcionar los sistemas con una mayor utilización de procesadores, memoria, espacio en disco y redes. A esto también se le llama funcionar con alta densidad de servidores, y mejora tanto la eficiencia energética como la del hardware.

Un buen ejemplo de ello puede verse en el trabajo que Google ha realizado en los últimos 15 años para mejorar la utilización de su sistema interno. Utilizando la encapsulación de trabajos mediante la contenedorización, junto con el etiquetado detallado de tareas y una herramienta llamada programador de clústeres, Google empaqueta estrechamente sus diversas cargas de trabajo en servidores como piezas de un juego de Tetris. El resultado es que Google utiliza mucho menos hardware y energía (posiblemente menos de un tercio de lo que utilizaría de otro modo).

Nota

Puedes leer todo sobre el trabajo de Google en un fascinante artículo publicado hace una década. Los autores también dieron un gran nombre al programador de clústeres: Borg. La lectura del artículo de Google sobre Borg fue lo que cambió la vida de Anne y la lanzó a todo el viaje de la tecnología operacionalmente eficiente, así que estás avisado.

BTW: Borg acabó engendrando Kubernetes.

Multiarrendamiento

Todos los proveedores de nubes públicas invierten mucho en eficiencia operativa. En consecuencia, el mejor paso sostenible que puedes dar hoy puede ser trasladar tus sistemas a la nube y utilizar sus servicios.

Su alto nivel de multiarrendamiento, o uso compartido de máquinas entre varios usuarios, es lo que permite que los índices de utilización de las máquinas en la nube superen significativamente lo que se puede conseguir en prem. Potencialmente, consiguen >65% de utilización frente al 10-20% de media en prem (aunque si te limitas a "levantar y cambiar" a servidores dedicados en la nube, no obtendrás gran parte de este beneficio).

Los hiperescaladores lo consiguen empaquetando sus diversas cargas de trabajo en grandes servidores utilizando sus propios orquestadores y programadores inteligentes, si pueden (es decir, si no les has puesto trabas especificando servidores dedicados).

Ten en cuenta que si estás utilizando una arquitectura de microservicios bien diseñada, incluso las tasas de utilización on-prem pueden aumentar significativamente utilizando un programador de clústeres de consumo: por ejemplo, , el programador de Kubernetes o Nomad de HashiCorp.

Los programadores de clústeres de que optimizan la utilización de las máquinas de requieren trabajos encapsulados (normalmente trabajos envueltos en una VM, un contenedor o una función sin servidor), que se ejecutan sobre una capa de orquestación que puede iniciarlos o detenerlos, o moverlos de una máquina a otra.

Para empaquetar bien, también es vital que los orquestadores y programadores sepan lo suficiente para tomar decisiones inteligentes sobre la colocación de los trabajos. Cuanto más sepa un programador sobre los trabajos que está programando, mejor podrá utilizar los recursos. En las nubes, puedes comunicar las características de tus cargas de trabajo eligiendo los tipos de instancia adecuados, y debes evitar sobreespecificar tus requisitos de recursos o disponibilidad (por ejemplo, pidiendo una instancia dedicada cuando funcionaría una burstable).

Las soluciones sin servidor altamente multiusuario, como las funciones Lambda en AWS, las funciones Azure o Google Serverless, también pueden ser útiles para minimizar la huella de hardware. Las soluciones sin servidor también proporcionan otras capacidades de eficiencia operativa, como el autoescalado (hacer que los recursos de hardware se conecten sólo cuando son necesarios) y la asignación automática de derechos.

Hacer este tipo de cosas operativas inteligentes en tu propio sistema on-prem es posible, pero conlleva un coste monetario en términos de esfuerzo de ingeniería para conseguir el mismo resultado. Para los proveedores de la nube, éste es su negocio principal y merece la pena dedicarle tiempo y dinero. ¿Es lo mismo para ti?

Buenas prácticas operativas

Ejemplos más sencillos de eficiencia operativa incluyen no sobreaprovisionar los sistemas (por ejemplo, reducir manualmente el tamaño de las máquinas más grandes de lo necesario), o utilizar el autoescalado para evitar aprovisionarlas antes de que sean necesarias.

Más sencillo aún, cierra aplicaciones y servicios que ya no hacen nada. La experta en sostenibilidad Holly Cummins, ingeniera de Red Hat, se refiere a ellas como "cargas de trabajo zombi". No dejes que ronden por ahí "por si acaso".

Si no puedes molestarte en automatizar el arranque y la parada de un servidor, es señal de que ya no es valioso. Las cargas de trabajo zombis y sin mantenimiento son perjudiciales para el medio ambiente, además de un riesgo para la seguridad. Apágalas.

Herramientas y técnicas operativas ecológicas

Incluso si ejecutas tus cargas de trabajo en una nube (es decir, operada por otra persona), sigue habiendo configuraciones de eficiencia operativa dentro detu control:

• Las instancias puntuales en AWS o Azure (instancias preferentes en GCP) son una parte vital de cómo las nubes públicas logran su alta utilización. Dan a los orquestadores y programadores discreción sobre cuándo se ejecutan los trabajos, lo que ayuda a empaquetarlos en las máquinas. A corto plazo, utilizar instancias puntuales en todos los lugares que puedas hará que tus sistemas sean más eficientes desde el punto de vista del hardware, más eficientes desde el punto de vista de la electricidad y mucho más baratos. A largo plazo, contribuirá a que tus sistemas sean más conscientes de las emisiones de carbono, porque las instancias puntuales permitirán al proveedor de la nube desplazar las cargas de trabajo a horarios en los que la electricidad de la red local sea menos intensiva en carbono (como describe Google en su reciente documento sobre operaciones de centros de datos conscientes de las emisiones de carbono).

• El sobreaprovisionamiento reduce la eficiencia del hardware y la energía. Las máquinas se pueden redimensionar utilizando, por ejemplo, el Explorador de Costes de AWS o el análisis de costes de Azure, y una simple auditoría puede identificar a menudo los servicios zombis, que hay que desconectar.

• Una redundancia excesiva también puede disminuir la eficiencia del hardware. A menudo, las organizaciones exigen duplicación entre regiones para una conmutación por error en caliente, cuando bastaría con una conmutación por error en frío más GitOps.

• El autoescalado minimiza el número de máquinas necesarias para hacer funcionar un sistema de forma resistente. Puede vincularse al uso de la CPU o a los niveles de tráfico de red, e incluso puede configurarse de forma predictiva. Recuerda autoescalar tanto hacia abajo como hacia arriba, ¡o sólo será útil la primera vez! AWS ofrece un excelente manual sobre la autoescalabilidad basada en microservicios. Sin embargo, aumentar la complejidad de la arquitectura exagerando el número de microservicios puede provocar un aprovisionamiento excesivo. Aquí hay un equilibrio. Intenta mantener la sencillez. Lee Building Microservices, de Sam Newman, para conocer las buenas prácticas.

• Los tipos de instancia dedicados o siempre activos no son ecológicos. Elegir tipos de instancia que den al host más flexibilidad y, sobre todo, más información sobre tu carga de trabajo, aumentará la utilización de la máquina y reducirá las emisiones de carbono y los costes. Por ejemplo, las instancias T3 de AWS, la serie B de Azure y los tipos de máquina de núcleo compartido de Google ofrecen interesantes capacidades de bursting, que son potencialmente una alternativa más fácil al autoescalado.

Cabe señalar que las arquitecturas que reconocen las tareas de baja prioridad y/o retrasables son más fáciles de manejar con una utilización elevada de la máquina. En el futuro, las mismas arquitecturas serán mejores en la conciencia del carbono. Entre ellas se incluyen las arquitecturas sin servidor, de microservicios y otras arquitecturas asíncronas (basadas en eventos).

Según el evangelista de la tecnología verde Paul Johnston, de , "estar siempre encendido es insostenible". Esto puede ser la sentencia de muerte para algunos monolitos heredados de gran peso.

Herramientas de información

El coste del alojamiento siempre ha sido en cierto modo una medida indirecta de las emisiones de carbono. Es probable que se correlacione aún más en el futuro, a medida que la nube se convierta en un producto cada vez más básico, la electricidad siga siendo un coste subyacente clave y la electricidad sucia se encarezca mediante precios dinámicos. También existen ahora herramientas de información sobre la huella de carbono más específicas. Son rudimentarias, pero mejor que nada, y si se utilizan, mejorarán. Así que utilízalas.

Capítulo 5: Conciencia del carbono

En el Capítulo 5, "Concienciación sobre el carbono ", trataremos los marcadores de un diseño sólido desde la perspectiva de la concienciación sobre el carbono :

• Poco o nada está "siempre encendido".

• Los trabajos que no son críticos en el tiempo (por ejemplo, los trabajos de aprendizaje automático o por lotes) se dividen y se calcula de forma asíncrona para que puedan ejecutarse en momentos en los que la intensidad de carbono de la electricidad en la red local sea baja (por ejemplo, cuando brille el sol y no haya ya una gran demanda en la red). Esta técnica suele describirse como desplazamiento de la demanda y, como ya hemos dicho, los tipos de instancia Spot o preemptible son especialmente aptos para ella.

• La oferta de tus servicios cambia en función de la intensidad de carbono de la red local. Esto se denomina modelado de la demanda. Por ejemplo, en momentos de generación de electricidad baja en carbono, se ofrece toda la funcionalidad, pero en momentos de energía alta en carbono, tu servicio se degrada con elegancia. Muchas aplicaciones hacen algo análogo para hacer frente a las fluctuaciones de disponibilidad del ancho de banda, por ejemplo, reduciendo temporalmente la calidad de la imagen.

• Las tareas realmente críticas en el tiempo y siempre activas, que inevitablemente necesitarán recurrir a electricidad de alta intensidad de carbono, se escriben de forma eficiente para utilizar la menor cantidad posible.

• Los trabajos no se ejecutan con más urgencia de la que necesitan, así que si pueden esperar a tener electricidad más limpia, lo harán.

• Siempre que es posible, los cálculos se envían a a los dispositivos de los usuarios finales y al perímetro para minimizar el tráfico de la red , reducir la necesidad de ejecutar procesos bajo demanda en los centros de datos y aprovechar al máximo la energía almacenada en las baterías de los dispositivos. Esto también tiene otras ventajas: Las aplicaciones P2P, fuera de línea, ayudan a eliminar la necesidad de servicios centralizados con un alto porcentaje de tiempo de actividad y aumentan la resistencia de las aplicaciones a los problemas de la red y la disminución de la latencia.

• Se utilizan el precálculo algorítmico y el precaching: Las tareas de cálculo intensivas en CPU o GPU se realizan y guardan antes de que se necesiten. A veces esto puede parecer ineficiente (los cálculos pueden desecharse o sustituirse antes de ser utilizados), pero además de acelerar los tiempos de respuesta, el precálculo inteligente puede aumentar la eficiencia del hardware y ayudar a desplazar el trabajo a horas en las que la electricidad consuma menos carbono.

Estos marcadores a menudo se basan en una arquitectura de microservicios o de sistemas distribuidos, pero eso no es necesario al 100%.

Capítulo 6: Eficiencia del hardware

En el Capítulo 6, "Eficiencia del hardware", observamos que para el software que se ejecuta en dispositivos de usuario en lugar de servidores, el carbono emitido durante la producción de esos dispositivos supera masivamente al emitido como resultado de su uso (ver Figura 1-2).

Figura 1-2. Efectos directos de las emisiones de_CO2 por dispositivo de usuario final de TIC (basado en datos de la Universidad de Zúrich)

Nota

No, ninguno de nosotros sabe tampoco lo que es un televisor FTP. Suponemos que es un televisor inteligente. Las emisiones de gases de efecto invernadero de este aparato parecen más problemáticas de lo que habríamos imaginado.

Por tanto, en el futuro, los dispositivos de los usuarios en un mundo de carbono cero tendrán que durar mucho más. Esto vendrá impulsado en parte por el diseño físico y la fabricación, pero también por evitar la obsolescencia inducida por el software, causada por sistemas operativos y aplicaciones que dejan de proporcionar parches de seguridad o dependen de nuevo hardware o funciones.

A medida que pasa el tiempo, la ley de Moore (que postula que el número de transistores de un microchip se duplica cada dos años) y otras formas de progreso hacen que los dispositivos obtengan siempre nuevas funciones, que los desarrolladores quieren explotar en sus nuevos lanzamientos de aplicaciones. Los teléfonos móviles, por ejemplo, se han vuelto más rápidos, han evolucionado para tener GPU dedicadas y chips de aprendizaje automático, y han adquirido más memoria. Las apps se aprovechan de estos avances, y eso está bien. Sin embargo, es vital que esas aplicaciones también sigan funcionando en teléfonos antiguos sin las nuevas funciones, para que no contribuyan a una obsolescencia evitable impulsada por el software.

Para no animar a los usuarios a desechar la tecnología que funciona, es imprescindible que los desarrolladores creen nuevo software que sea compatible con los dispositivos existentes. Los sistemas operativos de los teléfonos proporcionan cierta información y herramientas para ayudar en esto, pero normalmente requiere la acción de los desarrolladores.

En este momento, la gran empresa que mejor sabe evitar que el software acabe con los dispositivos podría ser Apple. El nuevo iOS 15 es compatible con teléfonos de hasta seis años de antigüedad. Sin embargo, todos los proveedores deben mejorar. La esperanza de vida de los dispositivos debe ser mucho mayor, incluso de seis años. Fairphone, un proveedor de teléfonos más especializado, ya proporciona parches de seguridad del SO durante ocho años y se ha propuesto llegar a los diez, lo que demuestra que se puede hacer.

Todos los teléfonos actuales son superados en longevidad por la mayoría de las videoconsolas. Por ejemplo, la Xbox One se diseñó para durar 10 años, y ese compromiso parece mantenerse. El modelo de negocio de las videoconsolas no incluye tanta desechabilidad planificada para el producto como el modelo de negocio de los teléfonos. Esto demuestra que los aparatos pueden durar más si los fabricantes así lo deciden. Creemos que al menos 10 años debería ser la esperanza de vida de todos los dispositivos nuevos a partir de ahora.

Capítulo 7: Trabajo en red

En el Capítulo 7, "Redes", hablamos del impacto de las redes y de Internet en las emisiones de carbono y comentamos cómo productos como los servicios de videoconferencia, que tienen que gestionar un ancho de banda fluctuante, proporcionan útiles ejemplos del mundo real de desplazamiento y modelado de la demanda.

Las herramientas y equipos de red, como los cables de fibra óptica, los routers y los conmutadores, siempre han tenido como objetivo fundamental minimizar los vatios por bit transmitido. Comparado con el resto de la industria, el trabajo en red ya está bastante optimizado para el uso de la energía, y sólo representa una pequeña parte de la factura eléctrica y de las emisiones de carbono de un centro de datos moderno.

Sin embargo, todavía hay mucho margen de mejora en la forma en que la mayoría de las aplicaciones utilizan esas redes. Para ellas, es poco probable que los vatios/bit fueran un objetivo de diseño.

El incipiente campo del software ecológico puede aprender mucho de las telecomunicaciones.

Capítulo 8: Aprendizaje automático, IA y LLM más ecológicos

En el Capítulo 8, "Aprendizaje automático, IA y LLM más ecológicos", abordamos el nuevo mundo de la IA y el aprendizaje automático (AM), que está generando un enorme aumento del trabajo intensivo de CPU y provocando una expansión masiva de la capacidad de los centros de datos. Como resultado, necesitamos estrategias para una IA ecológica.

Hablamos de técnicas como el entrenamiento de modelos ML más rápido y eficaz reduciendo el tamaño del modelo, utilizando el aprendizaje federado, la poda, la compresión, la destilación y la cuantización.

El ML también se beneficia de los rápidos avances en hardware y chips dedicados, y deberíamos intentar utilizar el hardware más adecuado para el trabajo de entrenamiento que tenemos entre manos.

Y lo que es más importante, los modelos ML son un gran ejemplo de trabajos que no son sensibles a la latencia. No necesitan ser entrenados con electricidad de alta intensidad de carbono.

Capítulo 9: Medición

Según , Chris Adams, de la Green Web Foundation, "El problema no ha sido sólo que los desarrolladores no quieran ser eficientes en el uso del carbono, sino que se han topado con la falta de datos, sobre todo de los grandes proveedores de nubes, para ver qué es realmente eficaz. Así que el modelado suele acabar basándose en suposiciones".³

A corto plazo, hacer la mejor suposición es mejor que nada. Las medidas genéricas, como pasar en la medida de lo posible a entornos multiusuario y hacer que el código de tiempo crítico consuma menos CPU, son eficaces. A largo plazo, sin embargo, los desarrolladores necesitan las herramientas adecuadas de observabilidad y monitoreo para iterar sobre el uso de la energía.

Capítulo 10: Monitoreo

Todavía es muy pronto para el monitoreo de las emisiones de los sistemas de software, pero llegarán más herramientas, y cuando lo hagan, es vital que aprendamos de todo el progreso que la industria tecnológica ha hecho en el monitoreo eficaz de los sistemas durante la última década y lo apliquemos a ser ecológicos.

En el capítulo 10, hablamos de la ingeniería de fiabilidad del emplazamiento (SRE) y de cómo podría aplicarse al presupuesto de tus emisiones de carbono.

Capítulo 11: Beneficios colaterales

En el Capítulo 11, "Beneficios colaterales", hablamos de los beneficios colaterales de adoptar un enfoque de software ecológico, que incluyen ahorro de costes, mayor seguridad y mejor resistencia.

Mientras esperamos mejores herramientas de información, el coste es una medida indirecta útil de las emisiones de carbono. Por tanto, existe un solapamiento entre el seguimiento del carbono y la nueva práctica de las operaciones financieras en la nube, o FinOps, que es una forma de que los equipos gestionen sus costes de alojamiento en la que todo el mundo (a través de equipos interfuncionales de TI, finanzas, producto, etc.) se hace cargo de sus gastos, con el apoyo de un grupo central de buenas prácticas.

No obstante, sigue habiendo un beneficio significativo en el uso de herramientas de huella de carbono sobre las de FinOps para medir los costes del carbono. En algún momento -esperemos que sea lo antes posible- esas herramientas tendrán en cuenta la carga de carbono de la electricidad realmente utilizada para alimentar tus servidores. Por el momento, a menudo pagas lo mismo por alojar en regiones donde la electricidad es baja en carbono, como Francia (nuclear) o Escandinavia (hidráulica, eólica), que en regiones con energía alta en carbono, como Alemania. Sin embargo, tus emisiones de carbono serán menores en los primeros lugares y mayores en los segundos. Una herramienta de huella de carbono lo reflejará. Una de FinOps, no.

Capítulo 12: La matriz de madurez del software ecológico

En el Capítulo 12, "La Matriz de Madurez del Software Ecológico", hablamos del proyecto Matriz de Madurez del Software Ecológico (GSMM) de la Fundación del Software Ecológico. La mayoría de nosotros tenemos que pasar del nivel 1 de la matriz (apenas iniciados en sistemas eficientes y adaptables a la demanda) al nivel 5 (sistemas que pueden funcionar 24 horas al día, 7 días a la semana, con electricidad libre de carbono).

El GSMM afirma que deberíamos empezar por mejorar la eficiencia operativa y dejar la eficiencia del código para el final, cuando, con suerte, podremos comprarla en la estantería. De hecho, el GSMM coincide notablemente con nuestras propias sugerencias.

Capítulo 13: ¿Adónde vamos ahora?

En el último capítulo, te propondremos un reto. Queremos que reduzcas a la mitad tus facturas de alojamiento (y, por tanto, de carbono) en los próximos 6-12 meses, y te daremos algunas sugerencias sobre cómo podrías hacerlo. Es un objetivo nada trivial, pero alcanzable y un primer paso necesario para ascender en la Matriz de Madurez del Software Ecológico.

Por último, te diremos lo que los tres hemos aprendido sobre el software ecológico al escribir este libro: no es un nicho. Es lo que todo software va a tener que ser a partir de ahora.

Por tanto, el software ecológico debe satisfacer todas nuestras necesidades. Tiene que ser productivo para los desarrolladores , y resistente y fiable y seguro y eficaz y escalable y barato. Al principio de este capítulo dijimos que el software ecológico era un software eficiente y consciente de las emisiones de carbono, pero eso es sólo una parte de la historia. El software ecológico tiene que satisfacer todas nuestras demás necesidades , además de ser eficiente y consciente de las emisiones de carbono. Pero esto es factible. Ya está ocurriendo.

La historia del software ecológico no es todo pesimismo seguido de fatalidad. A nuestro juicio, ser ecológico es lo más interesante y desafiante que está ocurriendo en la tecnología ahora mismo. Lo cambiará todo y afecta a todo el mundo. Es importante y tiene solución.

Así que, buena suerte y diviértete cambiando el mundo.

¹ Adrian Cockcroft, comunicación personal.

² Paul Johnston, comunicación personal.

³ Chris Adams, comunicación personal.