Carbon-aware computing es la idea de que los workloads flexibles pueden ejecutarse cuando y donde la energía es más limpia. La intensidad de carbono de la red eléctrica varía por hora y región: ejecutar un batch job de noche con viento alto emite 3-5 veces menos CO₂ que al mediodía con gas natural. Sin cambiar hardware, sin reescribir aplicaciones, solo con scheduling inteligente.

Puntos clave

  • La intensidad de carbono de la red varía hasta 16x entre el escenario óptimo y el peor según zona y hora.

  • El 20-40% del compute total de una organización es diferible sin impacto en usuarios finales.

  • La reducción típica es del 10-30% de CO₂ en workloads flexibles con mínimo esfuerzo.

  • Las herramientas principales son Electricity Maps API, WattTime y el Carbon Aware SDK de la Green Software Foundation.

  • El carbon-aware computing no añade costes cuando el scheduling es lógico: no hace falta infraestructura nueva.

El concepto base

La red eléctrica no tiene carbono constante. Ejemplos representativos:

  • Noche con viento alto: ~50-100 g CO₂/kWh.

  • Día con sol fuerte: ~100-200 g.

  • Pico de demanda con gas natural: ~400-500 g.

  • Zonas dependientes del carbón: >800 g.

Un workload que consume 1 MWh:

  • En zona limpia y horario óptimo: ~50 kg CO₂.

  • En zona sucia y horario malo: ~800 kg.

16x de diferencia sin cambiar nada excepto el timing y la ubicación.

Tipos de flexibilidad

No todos los workloads son flexibles. La clasificación práctica:

Flexibles en tiempo (diferibles sin impacto usuario):

  • Batch processing y ETL.

  • Entrenamiento de modelos ML.

  • Refresh de data warehouse.

  • Backups e indexing.

Flexibles en ubicación (stateless multi-región):

  • Workloads stateless que no tienen restricciones de residencia de datos.

  • Tareas de compute puro donde los datos pueden viajar.

No flexibles:

  • Requests de usuarios en tiempo real.

  • Streaming de datos en tiempo real.

  • Transacciones OLTP.

  • Control loops.

El 20-40% del compute total de una organización puede ser diferible sin impacto en la experiencia de usuario.

Fuentes de datos: APIs de intensidad de carbono

Las tres fuentes principales:

  • Electricity Maps[1]: datos en tiempo real y forecast por región para más de 50 países. El tier gratuito cubre experimentación.

  • WattTime[2]: enfoque en EE.UU. con datos históricos granulares.

  • Carbon Aware SDK[3] (Green Software Foundation): wrapper open-source multi-idioma que agrega más de una fuente de datos.

Patterns de implementación

Diferir batch jobs

El cambio más simple: si un backup o un job ETL puede correr en cualquier momento en una ventana de 24 horas, se puede optimizar el horario:

from carbon_aware import get_cleanest_hour

hour = get_cleanest_hour(region="es-es", window_hours=24)
schedule_job_at(hour, "backup-db")

Cambio de unas pocas líneas, impacto medible en el reporte de emisiones.

Routing de workloads entre regiones

Para workloads verdaderamente stateless:

region = get_cleanest_region(candidates=["se-north-1", "ie-west-1", "pl-central-1"])
deploy_to(region)

Suecia (hidroeléctrica, limpia) frente a Polonia (carbón, >600 g/kWh) puede suponer una diferencia de 6-8x en emisiones por el mismo workload.

Carbon-aware HPA en Kubernetes

El stack emergente para escalar basado en intensidad de carbono:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: carbon-aware-workload
spec:
  scaleTargetRef:
    name: my-deployment
  triggers:
    - type: external
      metadata:
        scalerAddress: carbon-aware-scaler.default:8080
        region: eu-west-1
        threshold: "300"  # g CO₂/kWh

Cuando la intensidad supera el threshold, el HPA reduce réplicas y difiere trabajo. El carbon-aware-keda-operator[4] de Microsoft implementa este patrón. Para la capa de observabilidad de estas métricas, ver monitorización de contenedores.

El papel de la Green Software Foundation

La Green Software Foundation[5] (Linux Foundation + Microsoft, GitHub, Accenture, Thoughtworks) desarrolla:

  • Carbon Aware SDK: librería multi-idioma de referencia.

  • Software Carbon Intensity (SCI) specification: métrica estándar de g CO₂ por unidad de negocio.

  • Formación y certificaciones.

La SCI specification es importante porque define una métrica normalizada que permite comparar entre organizaciones y reportar en CSRD. Esa misma lógica de eficiencia energética conecta con las decisiones de diseño de un data center sostenible. Dónde se ubica y de qué mix eléctrico se abastece el proveedor cloud importa tanto como el momento en que se ejecuta cada workload.

Casos con ROI real

  • Google: reporta millones de kg CO₂ evitados anualmente via scheduling en sus data centers.

  • Microsoft: Xbox descarga actualizaciones priorizando horas low-carbon.

  • NHS UK: pilotos de procesamiento nocturno de imágenes médicas.

Para una empresa mediana: reducción del 10-30% de CO₂ en workloads flexibles con un sprint de implementación.

Costes frente a beneficios

Carbon-aware computing no añade costes cuando el scheduling es lógico:

  • El pricing de cloud por hora es uniforme dentro de la misma región.

  • El cambio es solo scheduling logic (código trivial).

  • El tiempo añadido solo existe si diferir el batch causa un delay inaceptable para el negocio.

Los beneficios:

  • Reducción real y reportable de CO₂.

  • Ayuda al cumplimiento de CSRD y ESG reporting.

  • Credenciales verdes genuinas (no carbon offsets comprados).

Limitaciones honestas

  • Los forecasts tienen un error de ±20%: no es ciencia exacta.

  • La cobertura regional no es universal: Electricity Maps cubre bien Europa Occidental pero hay zonas con datos pobres.

  • Los ahorros son 10-30% de los workloads, no del 100% del compute.

  • Riesgo de greenwashing si se reporta sin reducción real significativa.

Para empezar

El path más pragmático:

  • Auditar qué workloads son diferibles y cuánto consumen.

  • Prototipo con 1-2 jobs movidos a horas low-carbon usando la API gratuita de Electricity Maps.

  • Medir el CO₂ antes y después.

  • Expandir a más workloads y automatizar con KEDA.

  • Reportar en el sustainability reporting corporativo.

En contexto de CSRD y regulación europea creciente, el carbon-aware computing pasará de ser una opción a ser una expectativa en los próximos años. Mejor adoptarlo antes que ser forzado a hacerlo.

Versión en inglés: Carbon-Aware Computing: Reduce Emissions Without Rebuilding Everything.

Fuentes:

  1. Electricity Maps: intensidad de carbono en tiempo real y forecast por región[1]
  2. WattTime: datos históricos granulares de la red eléctrica en EE.UU.[2]
  3. Carbon Aware SDK, Green Software Foundation (repositorio en GitHub)[3]
  4. Green Software Foundation: SCI specification y programas de certificación[5]

Preguntas frecuentes

¿Qué workloads puedo diferir a horas de energía limpia sin afectar a los usuarios?

Los flexibles en tiempo: batch processing y ETL, entrenamiento de modelos ML, refresh de data warehouse, backups e indexing. Los workloads stateless sin restricciones de residencia de datos también son flexibles en ubicación y pueden moverse a la región más limpia. No lo son las requests de usuarios en tiempo real, el streaming, las transacciones OLTP ni los control loops. En total, el 20-40 % del compute de una organización es diferible sin impacto en la experiencia de usuario.

¿Cuánto CO₂ se ahorra realmente con carbon-aware scheduling?

En una empresa mediana, una reducción del 10-30 % de CO₂ en los workloads flexibles con un sprint de implementación, no del 100 % del compute. La intensidad de la red varía hasta 16x entre el mejor y el peor escenario. Un workload de 1 MWh emite unos 50 kg CO₂ en zona limpia y horario óptimo, frente a unos 800 kg en zona sucia y hora mala. Los forecasts tienen un error de ±20 %, así que no es ciencia exacta.

¿Encarece la factura de cloud ejecutar los jobs según la intensidad de carbono?

No añade costes cuando el cambio es solo lógica de scheduling: el pricing de cloud por hora es uniforme dentro de la misma región. Son unas pocas líneas consultando una API como Electricity Maps, cuyo tier gratuito cubre la experimentación. El único coste aparece si diferir el batch causa un delay inaceptable para el negocio. A cambio obtienes una reducción real y reportable de CO₂ útil para CSRD y ESG.

Fuentes

  1. Electricity Maps
  2. WattTime
  3. Carbon Aware SDK
  4. carbon-aware-keda-operator
  5. Green Software Foundation