Carbon-aware computing es la idea de que 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-5x menos CO₂ que al mediodía con gas natural. Sin cambiar hardware, sin reescribir apps, solo con scheduling inteligente. Este artículo cubre tools y patterns prácticos.
El concepto base
La red eléctrica no tiene carbono constante:
- Noche con viento: ~50-100g CO₂/kWh.
- Día con sol fuerte: ~100-200g.
- Picos de demanda con gas: ~400-500g.
- Zonas con carbón: >800g.
Un workload que consume 1MWh:
- En zona limpia y horario óptimo: ~50kg CO₂.
- En zona sucia y horario malo: ~800kg.
16x diferencia sin cambiar nada excepto timing/ubicación.
Tipos de flexibilidad
No todos los workloads son flexibles:
Flexibles en tiempo:
- Batch processing.
- ML training.
- Data warehouse refresh.
- Backups.
- Indexing.
Flexibles en ubicación:
- Workloads estateless multi-región.
- CDN origin.
- Compute-only tasks (no data residency tight).
No flexibles:
- User-facing requests.
- Real-time streaming.
- OLTP transactions.
- Control loops.
El 20-40% del compute total de una org puede ser diferible sin impacto user-facing.
Fuentes de datos
APIs principales:
- Electricity Maps: real-time y forecast por región, pay-per-use.
- WattTime: similar, foco US con historical data.
- Carbon Aware SDK: de Green Software Foundation, wrapper open-source.
- Google Cloud: publica carbon data por región.
- Microsoft Azure: similar.
Free tier suficiente para experimentación.
Patterns simples
Delay batch jobs
Si un backup o ETL puede correr en cualquier momento en ventana de 24h:
from carbon_aware import get_cleanest_hour
hour = get_cleanest_hour(region="es-es", window_hours=24)
schedule_job_at(hour, "backup-db")
Cambio trivial, impacto medible.
Route workloads between regions
Workload flexible puede ejecutarse en:
- Suecia (hydro, muy limpio).
- Irlanda (gas, medio).
- Polonia (carbón, sucio).
region = get_cleanest_region(candidates=["se-north-1", "ie-west-1", "pl-central-1"])
deploy_to(region)
Útil para training ML o data processing donde la data puede viajar.
Scale based on carbon
HPA tradicional escala por CPU. Carbon-aware HPA ajusta por carbono:
- Carbon low: scale up, procesa más.
- Carbon high: scale down, diferir.
Keda + carbon metric scaler hace esto.
Integración con Kubernetes
Stack emergente:
- carbon-aware-keda-operator de Microsoft.
- Custom HPA basados en Prometheus + carbon metric.
- Kubernetes Scheduler plugins para nodos flexibles.
Ejemplo con KEDA:
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
Green Software Foundation
La Green Software Foundation desarrolla:
- Carbon-Aware SDK: library multi-idioma.
- Software Carbon Intensity (SCI) specification.
- Training y certifications.
Linux Foundation + Microsoft, GitHub, Accenture, Thoughtworks. Buena señal de momentum.
Casos con ROI real
- Google: goal 24/7 carbon-free energy 2030. Reportan millones de kg CO₂ evitados anualmente via scheduling.
- Microsoft: Xbox descarga actualizaciones priorizando horas low-carbon.
- Meta: data centers con workload shifting.
- NHS UK: pilots moviendo MRI processing nocturno.
Escala individual de empresa mediana: 10-30% reducción de CO₂ en workloads flexibles con mínimo esfuerzo.
Métricas y reporting
Para trackear:
- CO₂ por workload: estimar con cloud APIs + carbon intensity.
- SCI score: Software Carbon Intensity — g CO₂ per función de negocio.
- Carbon savings: diferencia entre ejecución naive y carbon-aware.
- Report en CSRD: algunos cloud providers ya reportan emissions de tus workloads.
Costes vs beneficios
Carbon-aware típicamente no añade costes:
- Cloud pricing por hora es uniforme en la misma región.
- El cambio es solo scheduling logic (código trivial).
- Tiempo añadido solo si diferir batch causa delay inaceptable.
Beneficios:
- CO₂ reducción real, reportable.
- ESG / CSRD compliance ayuda.
- Marketing: green credentials genuinos.
Muy pocos casos donde costó más que beneficio, asumiendo tiempo dev razonable.
Limitaciones
Ser honesto:
- Data accuracy: forecasts tienen error ±20%.
- Regional coverage: Electricity Maps tiene muchas regiones pero no todas.
- Savings modest: típicamente 10-30% de workloads, no 100%.
- Greenwashing risk: si solo reports pero no reduces significativamente.
Ideologías competitivas
Dos corrientes:
- Carbon-aware (flexibility-first): mover workloads.
- Carbon-neutral via offsets: comprar créditos.
La industria empuja por la primera. Offsets son supplement, no replacement.
Para empezar
Path pragmático:
- Audit: qué workloads son flexibles y cuánto consumen.
- Prototype: 1-2 jobs movidos a horas low-carbon.
- Medir: CO₂ antes/después con Electricity Maps.
- Expand: más workloads, automatización con KEDA.
- Report: incorporar en sustainability reporting.
3-6 meses a implementación mature.
Conclusión
Carbon-aware computing es low-hanging fruit para sostenibilidad IT. Sin cambios de hardware ni reescritura de apps, puedes reducir emisiones de workloads flexibles 10-30% con scheduling inteligente. Herramientas existentes (Electricity Maps, KEDA, Carbon-Aware SDK) facilitan implementación. Combined con workloads sustainable architecture y commit real de renewable energy, es pieza importante del puzzle. En contexto de CSRD y regulación europea creciente, será expected en años — mejor adoptar antes que ser forzado.
Síguenos en jacar.es para más sobre sostenibilidad IT, Kubernetes y green software.