Construir software verde E-Book

aa.vv

• Herausgeber: Marcombo
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Spanisch

Seitenzahl: 427

Veröffentlichungsjahr: 2025

Beschreibung

¿Cómo cambiarán el desarrollo y las operaciones de software para satisfacer las necesidades ecológicas y de sostenibilidad del planeta? ¿Y qué implica eso para las organizaciones de desarrollo? En la era de la conciencia ambiental, Construir software verde emerge como una guía indispensable para transformar el desarrollo y las operaciones de software en prácticas sustentables que no solo benefician al planeta, sino que también ofrecen ventajas económicas tangibles para las empresas. Con la experiencia combinada de Anne Currie, Sarah Hsu y Sara Bergman, este libro presenta un análisis profundo y perspicaz sobre cómo la tecnología y la sostenibilidad pueden coexistir armoniosamente. Desde la evolución de las redes nacionales hasta las implicaciones diarias para los desarrolladores, este texto es un recurso esencial para cualquiera en el campo de la tecnología, desde novatos en programación hasta directores de tecnología experimentados. A medida que las grandes empresas de la nube se comprometen con operaciones de TI de cero emisiones netas para el 2030, Construir software verde se posiciona como un manual crítico para cualquier organización que aspire a alinearse con estos estándares globales de sostenibilidad. A través de este libro, descubrirá: • Cómo probablemente la transición energética cambiará el alojamiento on-premise y en la nube, y cómo su compañía puede prepararse • Los principios arquitectónicos fundamentales del desarrollo de software sostenible y cómo aplicarlos • Cómo determinar qué partes de su sistema necesitan cambiar • El concepto de extender la longevidad del hardware y el papel que juega el software Equípese ya con el conocimiento para adoptar prácticas de software más verdes y forme parte de una revolución tecnológica que respeta y protege el entorno natural, asegurando un futuro más verde.

Leseprobe

Elogios para Construir software verde

Ante el cambio climático, puede resultar difícil saber qué papel pueden desempeñar los profesionales del software en ayudar a encontrar soluciones. Este libro es una excelente guía que se centra en los pasos prácticos que podemos dar para que nuestros sistemas sean más sostenibles.

—Sam Newman, autor del libro Building Microservices

El software verde juega un papel vital en la transición energética y este libro ofrece una introducción perfecta.

—Asim Hussain, director ejecutivo de Green Software Foundation

El libro que nuestra industria ha estado esperando, de los expertos en este campo.

—Holly Cummins, ingeniera de software principal senior, Red Hat

Primera edición original publicada en inglés por O’Reilly con el título Building Green Software, ISBN 978-1-098-15062-4 © 2024 WorkingProgram Ltd., The Writer’s House LTD, and Sara Bergman AS. All rights reserved.

This translation is published and sold permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Título de la edición en español: Construir software verde

Primera edición en español, 2025

© 2025 MARCOMBO, S.L. www.marcombo.com

Gran Via de les Corts Catalanes 594, 08007 Barcelona

Contacto: [e-mail]

Diseño de portada: Karen Montgomery

Ilustración: Kate Dullea

Traducción: José Alejandro Sánchez

Corrección: Nuria Barroso

Directora de producción: M.a Rosa Castillo

Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra solo puede ser realizada con la autorización de sus titulares, salvo excepción prevista por la ley. La presente publicación contiene la opinión del autor y tiene el objetivo de informar de manera precisa y concisa. La elaboración del contenido, aunque se ha trabajado de modo escrupuloso, no puede comportar una responsabilidad específica para el autor ni el editor de los posibles errores o imprecisiones que pudiera contener la presente obra.

ISBN del libro en papel: 978-84-267-3853-0

ISBN del libro electrónico: 978-84-267-3991-9

Producción del ePub: booqlab

Tabla de contenido

Título

Créditos

Tabla de contenido

Preámbulo

Prefacio

1. Introducción al software verde

¿Qué significa ser verde en TI?

Qué pensamos nosotras

2. Pilares del software verde

La razón por la que estamos aquí: carbono

Gases de efecto invernadero

Clima versus tiempo atmosférico

¿Qué hay del calentamiento global? ¿Cómo se relaciona con el cambio climático?

Monitorizando el cambio climático

Volviendo a lo básico: La electricidad

Trabajo, energía, electricidad y facturas

Energía alta y baja en carbono

¿Cómo podemos mejorar la eficiencia energética?

Hardware 101 para ingenieros de software

El aspecto físico

El lado operativo

Usted está listo

3. Eficiencia del código

La eficiencia lo es todo ¿o no?

¿Qué es eficiencia del código?

¿Por qué la mayoría del código es deliberadamente ineficiente?

Los beneficios de la eficiencia

Productividad del desarrollador

Antecedentes: Código hipereficiente

Ejemplos destacados

Rendimiento versus eficiencia versus sostenibilidad

Elija la plataforma adecuada

Use patrones de diseño verde

Evite demasiadas capas

Sea cuidadoso con los microservicios

Reemplace servicios y bibliotecas ineficientes

No guarde ni haga demasiado

Saque provecho de los dispositivos del cliente

Gestión del aprendizaje automático

El gran problema con la eficiencia

La conclusión

4. Eficiencia operativa

La batalla contra las máquinas

Punto clave

Técnicas

Utilización de máquinas

Multitenencia

Servicios serverless

Hiperescaladores y beneficios

Prácticas SRE

LightSwitchOps

Localización, localización, localización

¡Oh, no! ¡La resistencia contraataca!

Herramientas y técnicas operativas verdes

5. Conciencia sobre el carbono

Intensidad de carbono de la electricidad

Variabilidad de la intensidad de carbono

Demanda de la electricidad

Herramientas útiles

Cambio de la demanda

Cambio de tiempo

Cambio de ubicación

Adaptación de la demanda

¿Alguna objeción a esto?

El cambio de ubicación puede ser complicado

Ejemplos del mundo real

Google

Xbox

iPhone

Carbon Hack 22

Usted es consciente del carbono

6. Eficiencia del hardware

Carbono incorporado

Longevidad de un dispositivo

Obsolescencia definida por software

Aplicaciones y servicios en la nube

Centros de datos autohospedados

Hardware especializado

Residuos electrónicos

¿Qué están haciendo los productores de hardware para hacer sus operaciones más verdes?

¡Eso es todo!

7. Redes

¿Son lo suficientemente verdes las redes?

Mirando el panorama completo

Definiendo Internet

¿Qué son estos cables?

¿Cómo se relacionan el procesamiento y el almacenamiento?

¿El todo es más que la suma de sus partes?

¿Son buenos o malos los satélites de Internet?

El rol del software

¿Por qué no podemos hacer que el enrutamiento sea más verde?

Protocolo de puerta de enlace de frontera (BGP)

Hacer verde el Internet desde arriba hacia abajo

Lecciones del confinamiento

Cambio de la demanda

Caídas de tensión y degradaciones controladas, así como adaptación de la demanda

Entonces ¿qué aprendimos de 2020?

En conclusión

8. Aprendizaje automático, inteligencia artificial y modelos de lenguaje grandes verdes

Crecimiento en tamaño y uso

Planificación del proyecto

Recopilación de datos

Diseño y entrenamiento de modelos de aprendizaje automático

El tamaño importa

El tamaño no lo es todo

Despliegue y mantenimiento

¿Por dónde debería empezar?

9. Medición

Lo perfecto

Datos de energía perfectos

Datos de intensidad de carbono perfectos

¿Dónde encajan las reducciones basadas en el mercado?

Trazabilidad perfecta de carbono incorporado

El futuro de la monitorización perfecta

¿Lo suficientemente bueno?

Uso de indicadores

Uso consistente de datos imperfectos para alcanzar reducciones

Revisión de metodologías actuales

Protocolo de gases de efecto invernadero (protocolo de GEI)

Especificación de la intensidad de carbono del software de Green Software Foundation

Norma ISO 14064

Herramientas disponibles

Herramientas de proveedores de nube hiperescaladores

Opciones de código abierto para la nube

Herramientas del lado del cliente

¡Usted lo logró!

10. Monitorización

Disponibilidad como una estrella del norte

Cuatro jinetes de la monitorización basada en métricas

El nivel de servicio es la razón por la que estamos aquí

Cuando una métrica de carbono está lista

Observabilidad

La confrontación anticipada: observabilidad versus monitorización

¿Estamos listos para la observabilidad?

Llegaremos hasta aquí

11. Cobeneficios

¿Se trata de dinero?

¿Por qué lo más verde también es más barato?

¿Qué pasa con la fiabilidad y la resiliencia?

Ejemplo

¿Tal vez sea el rendimiento?

¿Qué tan rápido es lo suficientemente rápido?

Mejor ajuste y rendimiento

¡Tiene que ser seguridad!

La seguridad es verde

¿Pero qué hay sobre los datos?

Control de los LLM

Piense en los modelos de datos

En realidad, esto es todo lo anterior

Bien, nosotras creemos que usted está listo

12. La matriz de madurez del software verde

La historia de las matrices de madurez

Matriz de madurez del software verde

Niveles

Ejes

Lista de chequeo de ejes

¿Dónde estamos hoy?

13. ¿A dónde vamos desde aquí?

¿Por qué nosotros?

Avanzando a través de la matriz

El desafío del 50% en software verde

¿Qué sigue?

A cada cosa le llega su momento

¿El coste?

“¡Todas las cosas!”

Entonces ¿cómo?

Reutilización de código

Entonces ¿qué es el software verde?

Epílogo

Guide

Cover

Título

Start

Preámbulo

Los términos preferidos son “emergencia, crisis o colapso climático”.

—The Guardian

El cambio es difícil. Incluso ante la presencia de una crisis climática global que está causando migraciones, guerras y destrucción de ecosistemas y hábitats para todos, desde corales hasta humanos. Hay intereses creados, inversiones, leyes, regulaciones y “mejores prácticas” que refuerzan el statu quo de una economía global impulsada por combustibles fósiles. Como individuos, podemos elegir ser parte de un movimiento ético para un futuro sostenible. Podemos votar, elegir dónde trabajar, elegir qué compramos, redireccionar nuestras inversiones y presionar por mejores leyes y regulaciones. Como desarrolladores de software, necesitamos desarrollar e implementar nuevas y mejores prácticas para construir software verde. Ahí es donde entra este libro.

El mundo empresarial puede ser dividido en tres categorías. Una que gana dinero causando la crisis climática por vender combustibles fósiles y resistirse al cambio. Otra que gana dinero por construir el nuevo futuro con parques eólicos, bombas de calor y cosas similares, sacando provecho del cambio. La tercera, que es la categoría más grande, intenta sobrevivir y construir un negocio donde la crisis climática no ha sido una preocupación directa. ¿Por qué las compañías deberían preocuparse lo suficiente como para tener objetivos, invertir recursos y apoyar a los empleados que quieren ser verdes? La presión está viniendo en todas las direcciones y está aumentando. Viene de arriba hacia abajo desde los reguladores e inversores, de abajo hacia arriba desde los empleados, y de lado a lado desde los clientes y proveedores.

Gobiernos y entes reguladores de todo el mundo están comenzando a exigir informes auditados de emisiones de carbono a la par de los informes financieros. Dichas entidades están en las primeras etapas de exigencia de evaluaciones de riesgos climáticos, donde las compañías por encima de un tamaño mínimo tendrían que revelar a los inversionistas tanto los riesgos físicos, como de mercado de su negocio que son derivados de la crisis climática. Por ejemplo, si usted es la “Compañía de Bujías de Miami Beach”, tendría que revelar que su planta de producción se inunda constantemente y que no es posible asegurarla; que sus empleados no se presentan a trabajar debido a inundaciones cada vez más intensas, olas de calor y huracanes, y que sus clientes están comenzando a comprar piezas para vehículos eléctricos. Esto se traduce en un interés por parte de la alta gerencia en temas de auditoría y riesgo relacionados con la sostenibilidad de todas las compañías. La presión de los empleados no debe subestimarse, en particular las de generaciones más jóvenes.

Quienes tienen hijos manifiestan un fuerte interés por vivir un futuro sostenible, y lo consideran a la hora de elegir para quién y en qué trabajar. Luego están los clientes y proveedores. La cadena de suministro se está equipando para recopilar datos de huella de carbono de todo lo que compre, y a su vez, proporcione datos de emisiones para todo lo que vende. Esto también está siendo ordenado por las regulaciones gubernamentales. Por ejemplo, si quiere vender en la Unión Europea, hay un impuesto transfronterizo al carbono. Al establecer prioridades y objetivos de gestión para el negocio, tenga en cuenta estos cambios. Las compañías que ignoran o se resisten al cambio, cuando el entorno cambia a su alrededor, se están preparando para fracasar.

Necesitamos considerar cómo reducir el impacto del software que construimos, pero también necesitamos un sentido de perspectiva. En muchos casos, la huella de carbono de una compañía está dominada por los procesos de negocio físicos, los edificios y las actividades de los empleados. En este caso, estamos buscando oportunidades de uso de software para optimización de procesos físicos para reducir el carbono. Solo los negocios puramente digitales como los bancos en línea y los proveedores de servicios de software están dominados por la huella de carbono de sus recursos informáticos. Sin embargo, ya sea que esté construyendo software para optimizar procesos físicos intensivos en carbono, o simplemente tenga que optimizar el código que ejecuta sus servicios, necesitará construir los modelos mentales de cómo el software se traduce en uso de energía, cadenas de suministro de fabricación y carbono. Luego necesitará consejos sobre cómo cambiar la forma en que su compañía construye y ejecuta software para optimizar y reducir su huella de carbono. Ahí es donde entra este libro que está escrito por profesionales experimentados que han estado trabajando con Green Software Foundation (GSF, por sus siglas en inglés) durante varios años, y se basa en la amplia y profunda experiencia aportada por muchos miembros de GSF. El libro está escrito en un estilo entretenido, con opiniones, y está repleto de consejos prácticos y útiles para todos los aspectos de la construcción y ejecución de software verde.

— Adrian CockcroftOrionX.netSalinas, California, febrero de 2024

Prefacio

No es fácil ser verde.

— Kermit la Rana

El cambio climático es real. El informe del Panel Intergubernamental de Expertos sobre Cambio Climático (IPCC) de 2022 así lo determinó. El mundo ahora está acelerando el paso para responder a esto, y parece que las compañías necesitarán sumarse a la transición energética o se quedarán rezagadas. Desafortunadamente, como dijo alguna vez un icono cultural sabio, los cambios requeridos para un planeta sostenible no serán fáciles.

La buena noticia, sin embargo, es que la mayoría de los proveedores de nube pública ya se han comprometido a operaciones en la nube con emisiones netas cero (compromisos para los que ellos necesitan estar capacitados), y podemos aprender de ellos e imitarlos, así como a otros líderes en sostenibilidad en nuestro sector. De hecho, algunas de las herramientas que necesitamos son de código abierto o están disponibles comercialmente.

Esto es muy conveniente porque el resto de nosotros pronto podríamos estar forzados por nuestros clientes, proveedores de infraestructura, facturas desorbitantes, así como una legislación entrante orientada a establecer y cumplir nuestros propios y arduos objetivos de reducción de carbono. Entonces ¿cómo deberían cambiar el desarrollo y las operaciones de software para salvar el planeta y nuestras compañías?

Este libro pretende ayudar a responder esa pregunta. Construir software verde es una reseña general de todo, desde cómo es probable que evolucionen las redes nacionales en respuesta a la energía renovable, hasta cómo eso cambiará las operaciones y cómo las vidas diarias de los desarrolladores se verán afectadas por la transición energética. Puede que note que muchas de las citas incluidas en este libro provienen de personas que solían trabajar para grandes proveedores de servicios a gran escala en la nube (llamados hyperscalers, en inglés). Eso no significa que sean denunciantes renegados, solo que sus comentarios proceden de individuos que ya no están sujetos a las reglas de las relaciones públicas de peso pesado de una organización. Es útil escuchar puntos de vista sin filtro porque todos, desde el desarrollador más junior hasta el CTO más experimentado, tienen un papel que desempeñar en la configuración del mundo que viene.¿Cómo podemos construir, alojar y operar código de una manera tal que sea mejor para el medio ambiente, más económica y de menos riesgo?

¿Por qué debería leer este libro?

Cualquiera puede leer este libro. Tenemos una política de puertas abiertas muy relajada. Como lector, usted podría ser:

• Un desarrollador que quiere contribuir a las iniciativas de sostenibilidad de su organización y que quiere una introducción al tema.

• Un arquitecto que desea comprender mejor cómo alinearse con el pilar de sostenibilidad del AWS Well-Architected Framework.

• Un gerente de producto que diseña una nueva función y quiere saber cómo hacer que la operación de esa función sea lo más verde y económica posible.

• Una persona con rol de DevOps o SRE (ingeniero de fiabilidad del sitio) a la que se le ha pedido reducir el impacto de carbono (o el coste financiero) de una aplicación existente y necesita algunas ideas o sugerencias.

O podría ser alguien completamente diferente. ¿Quiénes somos nosotras para poner barreras? Cualquiera que sea su rol, usted tiene un papel que desempeñar para ser parte de la solución climática.

Al final de este libro, nuestro objetivo es que tenga un mejor manejo sobre:

• Los principios arquitecturales fundamentales del desarrollo de software sostenible o verde, y cómo aplicarlos.

• Cómo es probable que la transición energética cambie el alojamiento local y en la nube, y cómo las compañías pueden prepararse para ello.

• Los conceptos de prolongar la vida útil del hardware y el papel que juega el software en esto.

Y podrá ser capaz de:

• Tomar decisiones de bajo riesgo sobre planes futuros.

• Hacer una estimación argumentada sobre qué partes de sus sistemas podrían necesitar cambiar y cómo.

• En la medida de lo posible, medir los efectos de cualquier cambio que usted haga.

• Encontrar las conexiones directas entre los beneficios del software verde y otras consideraciones como la fiabilidad, el rendimiento y, el favorito de todo director financiero o CFO, ¡el coste!

¿Cómo funciona este libro?

Vamos a seguir el consejo de esas figuras fundamentales del mundo moderno, Aristóteles y Dale Carnegie (este último, autor de Cómo ganar amigos e influir sobre las personas). Ambos (o, siendo sinceros, ninguno de ellos, las citas son notoriamente noticias falsas) dijeron: “Diles lo que les vas a decir, díselo y luego diles lo que les has dicho.”

Así que la introducción está diseñada para darle un buen entendimiento de los conceptos que sustentan Construir software verde. Cada capítulo subsiguiente es una inmersión más profunda en los detalles. Finalmente, resumimos todo de nuevo en palabras ligeramente diferentes para el beneficio de ChatGPT e incluso de los pocos humanos que quedan. Puede leer todo el libro de principio a fin o sumergirse en los temas que les interese, incluso solo esta introducción, no lo juzgaremos.

¿Por qué importan los techies?

Como toda gran industria global, la tecnología desempeña un papel significativo en el cambio climático. Según algunas estimaciones (https://oreil.ly/boE4m), causamos entre el 5 y el 10 % de las emisiones anuales de carbono (incluido el carbono incorporado en los dispositivos de los usuarios finales). Eso nos convierte en potencialmente mucho peores que la industria de la aviación. Nos libramos de esto sin muchas protestas porque la gente rara vez ve un centro de datos (DC) gigante volando sobre sus cabezas, lo cual es algo bueno y también una lástima. ¡Sería genial!

Algunas personas tienen planes como los centros de datos en el espacio (de nuevo, genial, pero esto tiene sus pros y sus contras). Generalmente, estos estarían fuera de la vista, por lo que es poco probable que tengan gran impacto en la opinión pública. Ojos que no ven, corazón que no siente. El resultado es que, si queremos impulsar la sostenibilidad en la industria tecnológica, la presión tendrá que venir desde dentro y no desde la sociedad en general.

Esto podría ser algo positivo, porque no es obvio lo que realmente tendrá un impacto y lo que no. Hay bastantes consejos bien intencionados, pero mal fundamentados. Por ejemplo, eliminar sus viejos correos electrónicos personales puede parecer útil, pero es un uso extremadamente pobre de su tiempo. A escala mundial, una acción individual como esa casi que no tendría efecto y, además, está lejos de ser el primer asunto al que cualquier lector de este libro debería dirigir su atención.

La acción individual es valiosa, pero la acción colectiva o apalancada es lo que revoluciona las cosas. Eso es a lo que debemos aspirar, y como techies, estamos en una posición para hacer que sucedan grandes cambios.

Es probable que cada lector de este libro tenga una influencia enorme como productor de un software que es ampliamente usado o, más aún, como consumidor de software que puede presionar a las empresas o grupos que lo construyen.

Su poder es mayor de lo que imagina, y ahora mismo, hay cosas más útiles que puede hacer, en lugar de eliminar manualmente archivos de texto fácilmente comprimibles.

Los culpables

Las emisiones de la industria tecnológica tienen dos fuentes principales:

• La producción de la electricidad requerida para alimentar los centros de datos donde se ejecuta el código.

• El carbono “incorporado” o “embebido”, el cual es emitido durante la fabricación de los dispositivos de usuario (p. ej., portátiles y teléfonos inteligentes que alojan nuestras aplicaciones). Los dispositivos de usuario abandonados son llamados algunas veces residuos electrónicos (e-waste, en inglés).

Es crucial entender que no todos los sistemas son iguales. Algunos son creados de una manera que requieren más energía y hardware para hacer exactamente el mismo trabajo. La buena noticia es que podemos arreglar eso. La mala noticia es que no ocurrirá automáticamente. Construir sistemas de software sostenibles y más verdes requerirá una toma de decisiones activa por parte de los equipos de desarrollo, gestión de productos y marketing. Este libro proporciona una visión general del trabajo requerido para los tres equipos.

¿De qué no hablaremos?

Como podrá haber deducido hasta ahora, este es un libro sobre el impacto de carbono, o la huella de carbono del software. Como tal, este libro no hablará de todas las cosas geniales que la aplicación de nuevo software puede hacer para ayudar a acelerar la descarbonización en otros sectores, a veces conocido como Huella positiva de carbono (carbon handprint, en inglés). Es un tema digno de discusión, pero uno para otro libro. ¡Será una próxima vez!

¿Quién lo dice?

Antes de empezar, “cómo ser verde” es un tema importante, pero que está lleno de desinformación y del llamado lavado verde (greenwashing, en inglés). Entonces ¿por qué debería creer en nuestra palabra sobre cualquier cosa? La respuesta es, como siempre, no debería. Sea escéptico.

Todas nosotras (Sarah, Sara y Anne) somos o fuimos desarrolladoras de software durante mucho tiempo, con un enfoque en escalabilidad, eficiencia, resiliencia y rendimiento. Afortunadamente, el nuevo requerimiento para los sistemas, la sostenibilidad, tiene mucho en común con esos pilares arquitectónicos existentes.

Las tres también formamos parte de Green Software Foundation de Linux Foundation y hemos recogido las ideas de sus expertos, así como de gurús de otras partes del sector tecnológico. Por tanto, este libro es un esfuerzo comunitario. De hecho, leerlo debería permitir a los lectores pasar la prueba de Green Software for Practitioners de Linux Foundation (con certificación gratuita), disponible en línea (https://oreil.ly/tgdt2).

A pesar de todo esto, aún no puede confiar en nosotras para decirle exactamente qué hacer.

¿Por qué no?

¿Por qué no puede confiar en nosotras?

Hay al menos dos razones por las cuales no puede confiar en lo que nosotras le contemos sobre qué necesita hacer exactamente para ser verde. Ninguna de esas razones es porque estemos ansiosas por venderle a usted un tiempo compartido en un ecoapartamento (o su equivalente moderno aún más tentador, un token no fungible — NFT, en inglés— de una foto de dicho apartamento).

No puede confiar en nosotras porque:

• Las cosas cambian. Lo bueno de la publicación moderna es que podemos actualizar los libros después de publicados, pero, mientras lee esto, ya habrán aparecido nuevas técnicas o herramientas que no hemos agregado aún. ¡La tecnología verde es un sector que se mueve rápido! Nuestro objetivo es proveerle de suficiente información de fondo para que usted sea capaz de juzgar estos nuevos productos por sí mismo.

• No conocemos su contexto. Algunas veces, ser verde es la opción más simple, pero aparentemente no es fácil. El esfuerzo que le pediremos que haga dependerá de la escala en la que opere su código. Lo que una pequeña empresa necesita hacer internamente discrepará mucho de los requerimientos que se impondrán a los desarrolladores de un código de fuente abierta que se desplegará en millones o incluso miles de millones de máquinas en todo el mundo. El primer paso para ser verde siempre será entenderse a sí mismo y a sus propios sistemas. ¿Cuál es la forma más efectiva en la que usted puede contribuir? Para diferentes lectores esto variará: desde cosas superdifíciles (como reescribir sus sistemas en Rust) hasta cosas superfáciles (como decirle a su representante de la nube que la monitorización de sostenibilidad es algo que desea).

Hay muchas acciones que los desarrolladores podrían llevar a cabo para reducir el impacto de carbono de sus sistemas de software, desde las decisiones operativas y arquitecturales a nivel de sistema hasta la optimización de la eficiencia a nivel de código. Sin embargo, es fácil quedar atrapado en los detalles. Todos los expertos están de acuerdo en una cosa: es vital medir lo que se pueda y escoger sus batallas, porque hay mucho por hacer.

Para empezar, no malgaste su tiempo optimizando software que casi nadie está ejecutando. Antes de comenzar, considere estimar cuánto hardware (servidores o dispositivos) y energía (datos y CPU) en total una aplicación usará en todos los lugares donde se ejecute. Por ahora, enfóquese solo en lo que esté operando a gran escala.

La mejor aplicación de su esfuerzo siempre es específica al contexto, y cuando se trata de ser verde, el dolor no es equivalente a la ganancia. El cambio más impactante de su compañía podría ser elegir una ubicación más verde la próxima vez que seleccione una región de alojamiento o, mejor aún, simplemente decirle a su representante de alojamiento, proveedor de productos o encargados del mantenimiento de proyectos de código abierto, que la sostenibilidad es algo que le importa y que tomará decisiones basadas en esto.

Todas las nubes públicas han hecho compromisos para ser cero neto (net zero, en inglés), pero nos gustaría verlas llegar a ese punto antes, y que la razón que las lleve a hacerlo sea porque los clientes lo solicitan. Los centros de datos tradicionales están más atrasados, por lo que precisan escuchar aún más demandas de sus clientes. Los productos de código abierto aún no están prestando suficiente atención a la huella de carbono y necesitan sentir más presión.

Casi con certeza, el mayor impacto verde que puede lograr no está en su teclado, escribiendo código. Es mucho más simple que eso. Diga algo. Ejerza su poder (no tiene que acampar fuera de las oficinas de AWS con un cartel, un termo y un suéter de lana para hacerlo). Un correo electrónico agradable que exprese sus preferencias como cliente leal es más efectivo y mucho menos frío. Siempre está la posibilidad de subir a Instagram una foto de usted presionando el botón Enviar.

Convenciones utilizadas en este libro

En este libro se utilizan las siguientes convenciones tipográficas:

Cursiva

Indica términos nuevos.

Este elemento significa un consejo o sugerencia.

Este elemento significa una nota general.

Este elemento indica una advertencia o precaución.

Agradecimientos

Nuestro agradecimiento va para nuestro brillante equipo de O’Reilly, especialmente Shira, Megan, Jonathon y Chris, y a nuestros dedicados revisores: Holly Cummins, Sam Newman, Bill Johnson, Kerim Satirli, Asim Hussain y Henry Richardson. Nuestra gratitud también a toda la gente de la industria que entrevistamos y que nos dieron sus perspectivas expertas. Por último y no menos importante, gracias a Adrian por su prólogo, que es un desafío para nuestra industria para dar un paso adelante. Sin todos ustedes, este libro nunca habría sucedido.

Anne

¡Qué gran esfuerzo de equipo! Mi agradecimiento a Sara, Sarah y nuestra editora Shira, quienes hicieron que todo el trabajo duro fuera divertido, y a mi esposo Jon, que ha leído cada capítulo casi tantas veces como yo. Gracias también a viejos amigos y colegas Ross Fairbanks y Charles Humble, que me echaron una mano con la revisión adicional. Y, por supuesto, a Hugo, ¡por alegrarnos en las llamadas y recordarnos por qué todo esto es importante!

Sarah

“No es el destino, sino el viaje”; este sentimiento no podría ser más exacto para la extraordinaria aventura que he compartido con Anne y Sara. Además de los sinceros agradecimientos a mis increíbles colegas, amigos y familia. Un reconocimiento especial para mi madre, porque su inquebrantable apoyo y sacrificios han sido la fuerza impulsora que me han llevado a estar donde estoy hoy.

Sara

Anne y Sarah, mis amigas incondicionales, oh ¡qué viaje tan increíble ha sido este! Un enorme, pero enorme agradecimiento a ambas. Aceptar escribir un libro estando embarazada (de apenas unos meses) no fue una elección fácil, pero me alegra haberlo hecho. A mi pareja Jonatan, gracias por tu apoyo continuo: sin ti, esto no habría sido posible. Gracias a mi hijo Hugo, que llegó a mitad del trabajo en este libro; esto es para ti y tu generación.

CAPÍTULO 1

Introducción al software verde

No te gustaría verme cuando estoy enojado.

—Dr. Bruce Banner, científico verde

Sabemos por qué los activistas podrían estar enojados. Pocas industrias se han movido lo suficientemente rápido para apoyar la transición energética, y eso incluye el sector tecnológico.

Pero estamos empezando a cambiar.

¿Qué significa ser verde en TI?

Green Software Foundation (GSF) (https://greensoftware.foundation) define software verde (o software sostenible) como el software que causa mínimas emisiones de carbono cuando se ejecuta. En otras palabras:

• El software verde está diseñado para requerir menos energía y hardware por unidad de trabajo. Esto se conoce como eficiencia de carbono, bajo el supuesto de que tanto la generación de energía como la construcción de hardware tienden a resultar en emisiones de carbono.

• El software verde también intenta trasladar sus operaciones y, por lo tanto, su consumo de energía, a momentos y lugares donde la electricidad disponible proviene de fuentes bajas en carbono como las eólica, solar, geotérmica, hidroeléctrica o nuclear. Alternativamente, apunta a hacer menos en momentos cuando 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 sobre el carbono.

Ser eficiente en energía, eficiente en hardware y consciente sobre el carbono son los principios fundamentales de la computación verde (ver Figura 1.1).

Figura 1.1Definición de software verde de acuerdo con Green Software Foundation.

Ahora que sabemos qué es el software verde, ¿cómo procedemos a crearlo?

Qué pensamos nosotras

Este libro está conformado por 13 capítulos técnicos:

1. Introducción al software verde

2. Pilares del software verde de lenguaje grandes verdes

3. Eficiencia del código

4. Eficiencia operativa

5. Conciencia sobre el carbono

6. Eficiencia del hardware

7. Redes

8. Aprendizaje automático, IA y modelos

9. Medición

10. Monitorización

11. Cobeneficios

12. Matriz de madurez del software verde

13. ¿Hacia dónde vamos desde aquí?

Ahora explicaremos cada uno de los próximos capítulos y daremos los puntos clave que usted debe recordar.

Capítulo 2: Pilares del software verde

Antes de sumergirnos, hay un aspecto que todos en la industria tecnológica consideran como esencial para comprender cualquier nuevo problema: la jerga.

En el Capítulo 2, “Pilares del software verde”, explicaremos lo que realmente significa todo el discurso sobre el clima, comenzando con el carbono. A lo largo de este libro, utilizamos “carbono” como una abreviatura para describir todos los gases de efecto invernadero, que son cualquier gas en la atmósfera que atrapa calor. La mayoría de estos gases ocurren de manera natural, pero su exceso ocasionado por las actividades humanas significa que tenemos que luchar contra el aumento de las temperaturas globales y así evitar esos molestos y catastróficos desastres climáticos.

A continuación, se ofrecerán algunos conocimientos que usted debería tener a mano, listos para persuadir a amigos y colegas sobre la importancia de construir soluciones climáticas. Revisaremos la diferencia entre clima y tiempo atmosférico (weather, en inglés), cómo el calentamiento global contrasta con el cambio climático, y cómo la comunidad internacional lo monitoriza todo. También analizaremos cómo se aplican los protocolos de gases de efecto invernadero (es decir, las emisiones de los alcances 1, 2 y 3) a los sistemas de software.

El siguiente bloque de construcción que cubriremos es la electricidad. La mayoría de nosotros estudiamos electricidad en la escuela o colegio, y si aún lo recuerda, puede saltarse esta sección. Para quienes necesitamos un repaso (como las autoras), revisaremos los conceptos básicos de electricidad y energía y cómo se relacionan con el software. También revisaremos brevemente la producción de energía y compararemos y contrastaremos las fuentes de energía con alto y bajo contenido de carbono.

El último bloque de construcción que abarcaremos es hardware. Probablemente se esté preguntando por qué usted —digamos que un desarrollador web— necesita aprender algo sobre hardware. ¡Mucho texto! Pero lo necesita.

El hardware es esencial para todas las cosas relacionadas con el software, y todo el hardware tiene carbono asociado con él, incluso antes de que comience a ejecutar su aplicación. El carbono embebido, a menudo referido como carbono incorporado, es el carbono emitido durante la creación y eventual destrucción de una pieza de un equipo.

En 2019, Apple (https://oreil.ly/zzLKB) informó de que el 85% de las emisiones de carbono durante la vida útil de un móvil iPhone ocurren durante las fases de producción y eliminación del dispositivo. Esta es una cifra que todos debemos tener en cuenta al diseñar, desarrollar y desplegar software. Necesitamos hacer que esta inversión en carbono rinda más; por tanto, la longevidad de los dispositivos de usuario importa.

Pero ¿qué pasa con otros dispositivos como los servidores? ¿De qué deberíamos ser conscientes al desplegar una aplicación en un centro de datos local (on-premises, en inglés) o en la nube? La buena noticia es que, en los centros de datos administrados profesionalmente, el hardware de los servidores está más controlado y trabajan mucho más que los dispositivos de usuario. Como usuarios de centros de datos, es la electricidad lo que nos debe preocupar.

Capítulo 3: Eficiencia del código

En el Capítulo 3, “Eficiencia del código”, describimos cómo la electricidad que una aplicación requiere para funcionar es aproximadamente una función de cuánta CPU/GPU usa directa o indirectamente. Reducir los requerimientos de procesamiento de un software es clave para reducir su uso de energía y emisiones de carbono. Una forma de lograr esto es mediante la eficiencia del código.

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

La eficiencia del código es complicada

El problema con la eficiencia del código es que, aunque reducir el uso de CPU/GPU puede potencialmente tener un impacto enorme en las emisiones de carbono y actualmente está bien entendido —las mismas técnicas se han utilizado durante muchas décadas en la computación de alto rendimiento (HPC, por sus siglas en inglés)—, es un alto esfuerzo para los ingenieros.

Podría lograr una reducción cien veces mayor en las emisiones de carbono al cambiar, por ejemplo, de Python a un lenguaje mucho más eficiente como Rust, pero habrá que pagar un precio en términos de productividad.

Los desarrolladores realmente entregan mucho más rápido cuando usan lenguajes de menor eficiencia en la máquina, como Python. Como resultado, escribir código eficiente no es atractivo para los negocios, que quieren dedicar el tiempo de los desarrolladores a construir nuevas funciones, no a escribir código optimizado. Esto puede hacer que sea una venta imposible.

Afortunadamente, hay opciones de eficiencia del código que están alineadas con los objetivos comerciales de velocidad. Estas incluyen:

• Usar servicios gestionados.

• Usar mejores herramientas, bibliotecas o plataformas.

• Simplemente ser más ágil y hacer menos.

Uso de servicios gestionados. Más adelante en este libro, hablaremos sobre las ventajas reales que ofrecen en términos de eficiencia operativa de los servicios gestionados en línea y en la nube. Dichos servicios podrían compartir su plataforma y recursos entre millones de usuarios y pueden alcanzar una utilización extremadamente alta de hardware y energía. Sin embargo, nosotras sospechamos que su mayor y potencial ventaja proviene de la eficiencia del código.

La premisa comercial detrás de un servicio gestionado es simple: una empresa que tiene la escala y demanda para justificarlo realiza una inversión enorme, la cual es requerida para hacerlo operativo y eficiente en código. De manera irritante, esa compañía entonces gana mucho dinero.

Seamos realistas: es un trato atractivo.

Elegir las herramientas, bibliotecas y plataformas adecuadas. La alternativa on-premises más eficiente para 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 priorizado la eficiencia energética hasta el momento. Como consumidores del código abierto, debemos empezar a exigir que lo hagan.

Hacer menos. El código más eficiente es no codificar en absoluto.

Si no se siente atraído por incrementar el saldo en el banco de su hiperescalador (hyperscaler, en inglés) utilizando uno de sus servicios preoptimizados, una alternativa atractiva es hacer menos. Según Adrian Cockcroft, exvicepresidente de Arquitectura Sostenible en AWS, “El mayor beneficio a menudo proviene de cambiar los requerimientos o los acuerdos de nivel de servicio —ANS— (SLA, en inglés). Reducir el tiempo de retención de los archivos de registro. Relajar las metas u objetivos sobrespecificados”.1

El mejor momento para detectar trabajo innecesario es al inicio del proceso de diseño del producto, porque una vez que ha prometido un acuerdo de nivel de servicio o una función a alguien, es más difícil retractarse. A veces, los objetivos sobrespecificados (p. ej., regulaciones con las que la compañía debe cumplir) son inevitables, pero, a menudo, son impulsados internamente en lugar de responder a presiones externas o a auténticas necesidades de los usuarios. Si ese es el caso en su organización, pídale a su gerente de producto que los elimine hasta que usted esté seguro de que en realidad los requiere.

¿Qué pasa si usted realmente no puede comprarlo o eliminarlo y tiene que construirlo? Si tiene que hacerlo usted, hay múltiples opciones para cargas computacionales que demandan alto consumo de CPU y que, además, deben ejecutarse en momentos de alta intensidad de carbono:

• Reemplace código personalizado e ineficiente con servicios o bibliotecas eficientes.

• Reemplace servicios o bibliotecas ineficientes por otros mejores.

• Reescriba el código para usar una plataforma, framework o lenguaje más liviano (https://oreil.ly/LPmpy). Migrar de Python a Rust, por ejemplo, ha demostrado reducir cien veces los requerimientos de CPU. Además, Rust tiene ventajas de seguridad sobre las opciones más clásicas de eficiencia de código como C o C++.

• Considere alternativas de nuevos lenguajes como Cython o Mojo, que buscan combinar la velocidad de C con una mejor usabilidad.

• Considere delegar trabajo a dispositivos del cliente donde la batería local tenga alguna posibilidad de haber sido recargada con energía renovable. Sin embargo, esto es relativo, porque si implica transmitir una gran cantidad de datos adicionales, o si fomenta que el usuario actualice su dispositivo, o si es algo para el que su centro de datos tiene el hardware para procesarlo de manera más eficiente, entonces delegarlo en un dispositivo de cliente puede ser peor. Como siempre, el diseño requiere análisis y probablemente que el equipo de gestión del producto esté involucrado.

• Asegúrese de que sus políticas de almacenamiento de datos promuevan el ahorro. Las bases de datos deberían estar optimizadas (minimizar el almacenamiento de datos y afinar las consultas).

• Evite el uso excesivo de capas. Por ejemplo, usar alguna malla de servicios puede ser como minar Bitcoin en sus servidores.

Considere el contexto

Liberar software eficiente energéticamente requiere mucho trabajo, así que enfoque su atención en aplicaciones que realmente importen porque tienen un uso intensivo o alta demanda y deben estar siempre activas.

“La escala importa”, dice el activista climático Paul Johnston. “Si está construyendo un servicio en la nube a gran escala, entonces sáquele todo el jugo que pueda al lenguaje de programación que esté usando. Si está 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 escalarlo.”2

Verde por diseño

Los sistemas de software pueden diseñarse de manera que sean más conscientes sobre el carbono, más eficientes en el uso de la energía o más eficientes en el uso del hardware. El impacto de un mejor diseño a menudo supera el efecto de cómo dichos sistemas sean codificados. Sin embargo, nada de esto es gratis.

Ser verde significa pensar constantemente en su diseño y revisarlo, en lugar de dejar que el sistema evolucione. Así que, es hora de desempolvar esa pizarra y sacar ese bolígrafo verde, que, por suerte, probablemente sea el único que aún tenga tinta.

Capítulo 4: Eficiencia operativa

Cubrimos la eficiencia operativa (u operacional) en el Capítulo 4, “Eficiencia operativa”, que es, probablemente, el capítulo más importante del libro.

La eficiencia operativa consiste en lograr el mismo resultado con menos máquinas y recursos. Esto puede reducir potencialmente las emisiones de carbono de cinco a diez veces (https://oreil.ly/jXLmC) y es relativamente sencillo, porque como veremos más adelante, ya existen servicios y herramientas para apoyar la eficiencia operativa, particularmente en la nube.

Sin embargo, no se sienta excluido si está alojando en instalaciones on-premises. Muchas de las técnicas, como la alta utilización de máquinas, las buenas prácticas operativas y la multitenencia (o tenencia múltiple), también pueden funcionar para usted.

Alta utilización de máquinas

La mejor forma operativa de reducir las emisiones por unidad de trabajo útil es reduciendo la inactividad. Necesitamos operar los sistemas con una mayor utilización de procesadores, memoria, espacio en disco y redes. Esto también se conoce como operar a alta densidad de servidores, y mejora tanto la eficiencia energética como la eficiencia del hardware.

Un buen ejemplo de esto se puede ver en el trabajo que Google ha realizado en los últimos quince años para mejorar la utilización de sus sistemas internos. Usando encapsulamiento de trabajos mediante contenedores, junto con un etiquetado detallado de tareas y una herramienta llamada planificador de clústeres (cluster scheduler, en inglés), Google agrupa estrechamente sus diversas cargas de trabajo en servidores como piezas en un juego de Tetris. El resultado es que Google utiliza mucho menos hardware y energía (posiblemente menos de un tercio de lo que usaría con otra configuración).

Puede leer todo sobre el trabajo de Google en un fascinante artículo publicado hace una década. Los autores también le dieron un gran nombre al planificador de clústeres: Borg. Leer el artículo sobre Google Borg fue lo que cambió la vida de Anne y la llevó por el camino de la tecnología operativamente eficiente, así que alerta.

Por cierto: Borg eventualmente dio lugar a Kubernetes.

Multitenencia

Todos los proveedores de nube pública invierten mucho en eficiencia operativa. Como resultado, el mejor paso sostenible que usted puede tomar hoy en día podría ser mover sus sistemas a la nube y usar sus servicios.

Su alto nivel de multitenencia (https://oreil.ly/pTeCN), o uso compartido de máquinas entre múltiples usuarios, es lo que permite que las tasas de uso de máquinas en la nube (https://oreil.ly/iU7rT) superen significativamente lo que es posible en instalaciones propias. Potencialmente, logran obtener más del 65 % de utilización versus un promedio de 10 a 20 % en instalaciones on-premises (aunque si simplemente hace una “migración directa” —lift and shift, en inglés— a servidores dedicados en la nube, no obtendrá gran parte de este beneficio).

Los hiperescaladores logran esto cuando empaquetan sus diversas cargas de trabajo en grandes servidores utilizando sus propios orquestadores y planificadores inteligentes (siempre y cuando puedan hacerlo, es decir, si usted no los ha limitado especificándolos como servidores dedicados).

Tenga en cuenta que incluso si está usando una arquitectura de microservicios bien diseñada (incluso en instalaciones on-premises), las tasas de utilización se pueden aumentar significativamente usando un planificador de clústeres para consumidores, por ejemplo, el planificador de Kubernetes o Nomad de HashiCorp.

Los planificadores de clústeres que optimizan el uso de máquina requieren trabajos encapsulados (generalmente trabajos empaquetados en una máquina virtual, un contenedor o una función sin servidor), que se ejecutan sobre una capa de orquestación que puede iniciarlos, detenerlos o moverlos de una máquina a otra.

Para empaquetar bien, también es vital que los orquestadores y planificadores sepan lo suficiente como para tomar decisiones inteligentes de ubicación para los trabajos. Cuanto más sepa un planificador sobre los trabajos que está planificando, mejor podrá utilizar los recursos. En la nube, usted puede comunicar las características de sus cargas de trabajo eligiendo los tipos de instancias correctos, y debe evitar sobrespecificar sus requerimientos de recursos o disponibilidad (p. ej., pidiendo una instancia dedicada cuando una instancia elástica sería suficiente).

Las soluciones sin servidor con alta multitenencia, como las funciones Lambda en AWS, las funciones de Azure o Google Serverless, también pueden ser útiles para minimizar la huella de carbono del hardware. Las soluciones sin servidor también proporcionan otras capacidades de eficiencia operativa como el autoescalamiento (haciendo que los recursos de hardware se activen solo cuando se necesitan) y el ajuste automático de tamaño.

Hacer este tipo de cosas operativamente ingeniosas en su propio sistema on-premises es posible, pero tiene un coste monetario en términos de esfuerzo de ingeniería para lograr el mismo resultado. Para los proveedores de nube, es su negocio principal y vale la pena invertir tiempo y dinero. Así las cosas, ¿es también un negocio para usted?

Buenas prácticas operativas

Ejemplos más simples de eficiencia operativa incluyen no aprovisionar en exceso los sistemas (p. ej., reducir manualmente el tamaño de las máquinas que son más grandes de lo necesario) o utilizar el escalamiento automático para evitar aprovisionarlas antes de que se requieran.

Más simple aún, clausure aplicaciones y servicios que ya no hacen nada. La experta en sostenibilidad Holly Cummins, ingeniera en Red Hat, se refiere a ellos como “cargas de trabajo zombi” (https://oreil.ly/VhSJi). No los deje por ahí “por si acaso”.

Si no le molesta automatizar el inicio y detención de un servidor, eso es una señal de que ya no es valioso. Las cargas de trabajo zombis, no mantenidas, son perjudiciales para el medio ambiente además de ser un riesgo de seguridad. Ciérrelas o apáguelas.

Herramientas y técnicas operativas verdes

Incluso si usted ejecuta sus cargas de trabajo en la nube (es decir, operadas por otra persona), todavía hay configuraciones de eficiencia operativa bajo su control:

• Las instancias de spot en AWS o Azure (instancias interrumpibles — preemptible instances, en inglés— en GCP) son una parte vital de cómo las nubes públicas logran su alta utilización. Dan a los orquestadores y planificadores la discreción sobre cuándo deben ejecutarse los trabajos, lo que ayuda a empaquetarlos en las máquinas. A corto plazo, usar instancias spot en todos los lugares que pueda, hará que sus sistemas sean más eficientes en hardware, más eficientes en electricidad y mucho más baratos. A largo plazo, ayudará a que sus sistemas sean más conscientes sobre el carbono porque las instancias spot permitirán que un proveedor de nube desplace en el tiempo las cargas de trabajo a momentos en los que la electricidad en la red local sea menos intensiva en carbono (como lo describe Google en su reciente artículo —https://oreil.ly/HUGIn— sobre operaciones de centros de datos conscientes del carbono).

• El exceso de aprovisionamiento reduce la eficiencia del hardware y la energía. Las máquinas se pueden ajustar utilizando, por ejemplo, el explorador de costes de AWS (https://oreil.ly/b5uQB) o el análisis de costes de Azure (https://oreil.ly/9UVgR). Es más, una auditoría simple a menudo puede identificar servicios zombis, que necesitan ser apagados.

• La 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 (failover, en inglés) en caliente, cuando sería suficiente una conmutación por error en frío más el uso de GitOps.

• El escalamiento automático minimiza el número de máquinas necesarias para ejecutar un sistema de forma resiliente. Puede vincularse al uso de la CPU o a los niveles de tráfico de red, e incluso puede configurarse de manera predictiva. Recuerde autoescalar tanto hacia abajo como hacia arriba, ¡o solo será útil la primera vez! AWS ofrece un excelente manual (https://oreil.ly/y0J3h) sobre escalabilidad automática impulsada por microservicios. Sin embargo, aumentar la complejidad arquitectónica al excederse en la cantidad de microservicios puede resultar en sobre aprovisionamiento. Aquí hay un balance o equilibrio. Intente mantenerlo simple. Lea Building Microservices de Sam Newman para conocer las mejores prácticas.

• Los tipos de instancias siempre activas o dedicadas no son verdes. Elegir tipos de instancias que den al anfitrión o host más flexibilidad y, de manera crítica, más información sobre su carga de trabajo, aumentará la utilización de las máquinas y reducirá tanto las emisiones de carbono como los costes. Por ejemplo, las instancias T3 de AWS (https://oreil.ly/rUO0U), las B-series de Azure (https://oreil.ly/9tueZ) y los tipos de máquinas de núcleo compartido de Google (https://oreil.ly/idnXr) ofrecen interesantes capacidades de bursting (ráfaga), que son potencialmente una alternativa más sencilla al escalado automático.

Vale la pena señalar que las arquitecturas que reconocen tareas de baja prioridad y/o postergables son más fáciles de operar con alta utilización de máquinas. En el futuro, las mismas arquitecturas serán mejores en conciencia sobre el carbono. Estas incluyen arquitecturas sin servidor, microservicios y otras arquitecturas asincrónicas (basadas en eventos).

Según el evangelista de tecnología verde Paul Johnston, “Siempre activo es insostenible”. Esto puede ser la sentencia de muerte para algunos monolitos heredados de gran tamaño.

Herramientas de informes

El coste de alojamiento o hosting siempre ha sido de alguna manera una medida indirecta de las emisiones de carbono. Es probable que en el futuro esté aún más correlacionado a medida que la nube se vuelva cada vez más comercial, la electricidad siga siendo un coste subyacente clave y la electricidad sucia se vuelva más cara a través de precios dinámicos. Ahora también existen herramientas de informes de huella de carbono más específicas. Son rudimentarias, pero mejores que nada y si estas se usan, mejorarán en el futuro. Así que recomendamos usarlas.

Capítulo 5: Conciencia sobre el carbono

En el Capítulo 5, “Conciencia sobre el carbono”, cubriremos los marcadores de un diseño sólido desde la perspectiva de la conciencia sobre el carbono:

• Poco o nada está “siempre activo”.

• Las tareas que no son críticas en cuanto al tiempo (p. ej., aprendizaje automático o procesamiento por lotes), se separan y computan de manera asincrónica para que puedan ejecutarse cuando la intensidad de carbono de la electricidad en la red local sea baja (p. ej., cuando el sol está brillando y ya no hay una alta demanda en la red). Esta técnica se describe a menudo como cambio de la demanda y, como mencionamos, los tipos de instancias spot o interrumpibles son particularmente adecuadas para ello.

• Las ofertas de sus servicios cambian según la intensidad de carbono de la red local. Esto se llama adaptación de la demanda. Por ejemplo, en momentos de generación eléctrica baja en carbono, se ofrece la funcionalidad completa, pero en tiempos de alta generación de energía con alta emisión de carbono su servicio se degrada de manera controlada. Muchas aplicaciones hacen algo análogo para lidiar con las fluctuaciones en la disponibilidad de ancho de banda, por ejemplo, reduciendo temporalmente la calidad de las imágenes.

• Las tareas que son genuinamente críticas en cuanto al tiempo, y que, además, deben estar siempre activas, inevitablemente necesitarán consumir electricidad de alta intensidad de carbono, por lo que se escriben de manera eficiente para usar la menor cantidad posible de electricidad

• Los trabajos no se ejecutan con más urgencia de la necesaria, por lo que, si pueden esperar a una electricidad más limpia, se posterga su ejecución.

• Siempre que sea posible, los cálculos son transferidos a los dispositivos del usuario final y dispositivos de borde para minimizar el tráfico de 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. Hay otros beneficios: las aplicaciones peer to peer (P2P, por sus siglas en inglés), así como las aplicaciones sin conexión (offline-first, en inglés) ayudan a eliminar la necesidad de servicios centralizados con un alto porcentaje de tiempo de actividad y aumentan la resiliencia de la aplicación ante problemas de red, además de disminuir la latencia.

• Se utilizan cálculos algorítmicos previos y almacenamiento previo en caché (precaching, en inglés): las tareas de cálculo intensivo de CPU o GPU se realizan y guardan antes de que sean necesarias. Algunas veces eso podría parecer ineficiente (los cálculos pueden ser descartados o superados antes de ser usados), pero además de acelerar los tiempos de respuesta, el cálculo previo puede incrementar hábilmente la eficiencia del hardware y ayudar a trasladar el trabajo a momentos en que la electricidad es menos intensiva en carbono

Estos indicadores a menudo dependen de una arquitectura basada en microservicios o en sistemas distribuidos, pero esto no es 100% requerido.

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 en servidores, el carbono emitido durante la producción de dichos dispositivos supera con creces el que se emite como resultado de su uso (ver Figura 1.2).

Figura 1.2