Carbon-aware Scheduling: How Green Software Foundation…
Location-Shifting, Time-Shifting y Demand-Shaping: cómo funciona realmente el Carbon-aware Scheduling, con trade-offs honestos y ejemplos de patterns.
La sostenibilidad en la nube se vende principalmente como una estrategia de marketing: logotipo verde, compensación de CO2, informe de RSC. La discusión interesante se desarrolla en otro lugar. La planificación consciente del carbono (Carbon-aware Scheduling) desplaza las cargas de trabajo hacia donde la mezcla de energía es limpia en ese momento o hacia donde lo será en el futuro. Esto no es ideología, sino una decisión arquitectónica con números concretos, verdaderos compromisos y un grado de madurez que varía mucho según el patrón.
Lo más importante en resumen
- Tres patrones tienen la mayor palanca. Location-Shifting, Time-Shifting y Demand-Shaping – cada uno resuelve una parte diferente del problema del CO2, rara vez los tres funcionan juntos.
- La intensidad de carbono de la red es la medida guía. Sin datos fiables y resueltos por hora de la red (WattTime, ElectricityMaps), cualquier optimización sigue siendo un juego de adivinanzas. Los proveedores de nube proporcionan cada vez más esta señal por sí mismos.
- El caso de negocio se sostiene o cae según el perfil de carga de trabajo. Los lotes asíncronos y el entrenamiento de ML son los candidatos más rentables. Las API críticas de latencia y los servicios con estado generalmente no soportan el desplazamiento.
RelacionadoLa IA impulsa la nube – y el consumo de energía / Costos de inferencia de IA en 2026: FinOps para cargas de trabajo de GPU
Los impulsores son la Fundación Green Software (fundada en 2021 bajo el paraguas de la Fundación Linux, con miembros como Accenture, Microsoft, GitHub, Intel) y una serie de proveedores de datos que proporcionan la intensidad de CO2 de la red de manera regional y en tiempo real. La fundación ha identificado tres palancas en sus patrones: Demand Shifting (Location-Shifting y Time-Shifting) y Demand Shaping. Cada palanca tiene un efecto diferente en las emisiones, la latencia y los costos. Quien conoce las diferencias toma mejores decisiones arquitectónicas. Quien las mezcla, obtiene un proyecto de lavado verde con esfuerzo de CI.
Este artículo clasifica técnicamente los tres patrones. Muestra dónde la palanca de CO2 es real, dónde sigue siendo pequeña y qué significa esto prácticamente para los arquitectos de nube hoy en día.
Qué es técnicamente la planificación consciente del carbono
La planificación consciente del carbono es la decisión de cuándo y dónde se ejecuta una carga de trabajo, tomada en función de una señal externa: la intensidad de CO2 de la red eléctrica en una región determinada en un momento específico. La intensidad se expresa en gramos de CO2 equivalente por kilovatio hora. Cuanto mayor es la proporción de energía eólica y solar, menor es el valor. Cuanto mayor es la proporción de carbón o gas, mayor es el valor.
Los servicios como Electricity Maps o WattTime proporcionan la señal a través de API. La granularidad típica es de intervalos de 5 minutos o 1 hora. La planificación en sí se realiza en el clúster (a través de plugins del programador de Kubernetes), en el sistema CI/CD (GitHub Actions tiene un modo de compilación consciente del carbono a través de la integración con Azure) o en la lógica de la aplicación (marcos de procesamiento por lotes que retrasan el inicio de un trabajo hasta que la intensidad esté por debajo de un umbral).
La Green Software Foundation distingue tres patrones prácticos. No son términos de marketing, sino decisiones arquitectónicas claras con diferentes efectos y riesgos.
| Patrón | Principio | Adecuado para | Grado de madurez |
|---|---|---|---|
| Desplazamiento de ubicación | Desplazar la carga de trabajo a una región con una red eléctrica limpia | Procesamiento por lotes, entrenamiento de ML, agregación de datos sin restricciones de latencia | Productivo en GCP/AWS, requiere configuración multirregional |
| Desplazamiento temporal | Desplazar la carga de trabajo a la hora limpia dentro de la misma región | Informes posteriores, copias de seguridad, reentrenamiento de modelos | Utilizable con integración del programador (Airflow, Argo) |
| Conformación de la demanda | Reducir el esfuerzo computacional cuando la intensidad de CO2 de la red es alta | Transcodificación de video, características de UX no críticas, precomputación | Temprano, a menudo implementado en la aplicación |
Fuente: Catálogo de patrones de la Green Software Foundation 2024/2025.
Location-Shifting: llevar la carga de trabajo a la corriente limpia
Location-Shifting traslada un trabajo a una región con una intensidad de CO2 actualmente más baja. Técnicamente, esta es la variante más obvia: los proveedores de cloud tienen muchas regiones y la definición de la carga de trabajo suele ser independiente de la región. Los grandes hyperscalers ofrecen datos de emisiones regionales como parte de sus exportaciones de facturación.
El impacto es real porque las redes eléctricas en Europa están compuestas de manera muy diferente. Un lote que se ejecuta en una región con una alta proporción de energías renovables causa significativamente menos emisiones que el mismo lote en una región con una carga base fósil. Esto no es un truco contable: la electricidad está ligada a la ubicación. La mezcla de la red local determina la carga real.
Los límites son tangibles. La residencia de datos (DSGVO, regulación sectorial, contratos con clientes) puede prohibir un traslado a través de Europa. La latencia aumenta si los datos o los usuarios no están en la región de destino. Y el tráfico de salida entre regiones cuesta dinero – con grandes cantidades de datos, el lado de los costos puede consumir el beneficio de CO2 si no se controla el traslado.
Location-Shifting es más sólido donde los datos ya están disponibles de forma multirregional: conjuntos de datos de entrenamiento en almacenamiento de objetos que de todos modos se replican. O cargas de trabajo sin persistencia: cálculos por lotes sin estado que solo leen entradas y escriben resultados.
Time-Shifting: llevar la carga de trabajo a la hora limpia
Time-Shifting mantiene la carga de trabajo en su región, pero retrasa el inicio a una ventana con menor intensidad. El caso típico: una compilación nocturna o un entrenamiento de ML que comienza hoy a las 2 de la mañana porque entonces la proporción de energía eólica en la red es alta. O que comienza justo a las 4 de la mañana porque la previsión de intensidad actual lo recomienda.
Técnicamente, esto suele ser más sencillo que Location-Shifting: no hay efectos de red, no hay preguntas sobre la residencia. Un plugin de programación o un wrapper de cron basado en sondeo consulta la API de intensidad y activa el trabajo cuando se alcanza el umbral. Proyectos de Kubernetes como el escalador KEDA con conciencia de carbono o el lote de Google Cloud con la bandera de sensibilidad de carbono van exactamente en esta dirección.
El límite es la tolerancia a la demora. Una compilación de CI que espera cuatro horas no bloquea un lanzamiento – pero un trabajo de ingestión de registros que espera seis horas viola los requisitos de cumplimiento (plazos de GDPR, pistas de auditoría). Quien practique Time-Shifting de manera seria debe definir por carga de trabajo cuánto retraso es aceptable. De lo contrario, surge una segunda clase de trabajos «que se ejecutan en algún momento» que nadie depura.
Demand-Shaping: menos cálculo cuando la electricidad es sucia
Demand-Shaping es el patrón más exigente. En lugar de posponer la carga de trabajo, la aplicación adapta sus necesidades de recursos a la señaligen. Ejemplos: un codificador de video elige un preset más débil cuando la intensidad de CO2 es alta, una canalización de recomendaciones reduce la profundidad de su modelo, un trabajo de análisis calcula agregados más gruesos.
El encanto: Demand-Shaping también funciona para aplicaciones críticas de latencia que no pueden esperar ni migrar. El precio: la aplicación debe modelar explícitamente la compensación. Ya no es un tema de infraestructura, sino de producto. Un equipo que cambia su codificación de video de «Alta» a «Estándar» cuando la mezcla de electricidad es mala debe responder por el resultado ante el cliente. Quien no lo comunica arriesga tickets de soporte.
Compensaciones: lo que habla en contra de la programación consciente del carbono
La programación consciente del carbono no es un almuerzo gratis. Los patrones chocan con otros objetivos de arquitectura. Estas colisiones no son teóricas. Quien no lo entiende temprano se acumula deuda técnica, que bajo la etiqueta de «sostenibilidad» es más difícil de discutir que la complejidad habitual.
A favor
- Ahorro real de CO2 en cargas de trabajo por lotes, sin grandes cambios.
- Capacidad de informe: los proveedores de nube ofrecen cada vez más informes de emisiones auditables por región y ventana de tiempo.
- Señal interna: hace visible y discutible el consumo de energía en ingeniería.
- En muchos casos, neutral en costos o incluso más barato (los precios fuera de pico a menudo correlacionan con baja intensidad).
En contra
- Conflictos de latencia y residencia en Location-Shifting, a menudo no negociables regulatoriamente.
- Complejidad adicional en la programación: una nueva señaligen que puede fallar, retrasarse o ser incorrecta.
- No hay palanca para cargas de trabajo sincrónicas y orientadas al usuario sin lógica de Demand-Shaping.
- Peligro de lavado verde: un mal monitoreo hace que el ahorro sea imposible de verificar.
Piloto: cómo se ve una entrada realista
La tentación es grande de establecer Carbon-aware Scheduling como una iniciativa de plataforma. Rara vez es sensato. El mejor camino es un piloto estrecho que produzca un resultado real antes de que se escriban las directrices.
- Identificar candidatos. ¿Qué cargas de trabajo toleran retrasos de varias horas? Típico: compilaciones nocturnas, entrenamiento de ML, transformaciones de registros, rollups de análisis. No servicios orientados al usuario, ni pipelines síncronos.
- Elegir y verificar la fuente de la señal. Electricity Maps y WattTime son proveedores establecidos, los hyperscalers tienen sus propias API. Comprobar los valores una vez al día frente a la factura del proveedor hasta que la señal parezca fiable.
- Programar realmente una carga de trabajo. No un «concepto», sino un trabajo que cuelga en el programador de producción y se retrasa o cambia regionalmente. Medir durante cuatro semanas: tiempo de ejecución, costos, CO2, fallos.
- Medición desde el principio. Comparación antes-después en el mismo panel, donde también se muestran los costos y SLO. Si el número de CO2 solo aparece en el informe de sostenibilidad, no se operará.
- Escalar solo después. Si el piloto muestra un patrón reproducible, elevarlo a la capa de plataforma – como una opción del programador, no como una obligación.
Qué sigue siendo difícil
La mayor debilidad abierta es la atribución. Los proveedores de cloud informan de emisiones por región, pero rara vez por trabajo o servicio. Quien quiera saber cuánto CO2 causa un microservicio concreto durante un sprint, debe calcularlo él mismo – con intensidad energética, tiempo de ejecución, utilización y suposiciones sobre la efectividad del uso de energía del centro de datos. Esto es factible, pero es trabajo de ingeniería y no un clic en el panel. En la práctica, esto significa: un modelo de telemetría interno que calcula las métricas de tiempo de ejecución del programador con curvas de intensidad regionales y agrega resultados por equipo o servicio. Los equipos sin un modelo de este tipo se quedan con estimaciones que difícilmente se pueden justificar frente a los clientes o procesos de auditoría.
Otro punto a menudo subestimado: la responsabilidad operativa del propio programador. Si se interrumpe la alimentación de la señal de carbono, debe estar claro qué sucede – ¿se detiene el trabajo, se ejecuta inmediatamente, espera a un tiempo de espera? Sin un plan de contingencia definido, se producen fallos silenciosos. Carbon-aware Scheduling necesita la misma rigidez en la gestión de incidentes que cualquier otro programador de producción; de lo contrario, se convierte en un sistema en la sombra junto al funcionamiento real de Cron o Kubernetes.
La segunda debilidad abierta es la calidad de la señal. Las previsiones para las próximas horas han mejorado, pero no son exactas. Quien construye un programador que reacciona a cada pequeño pico en la mezcla de la red, obtendrá inicios de trabajo inestables. Más pragmático es una regla simple: retrasar hasta la próxima ventana por debajo de un umbral; de lo contrario, iniciar después del tiempo de espera máximo de todos modos. Sin optimización de segundo orden, sin pronóstico de ML sobre el pronóstico.
Y finalmente, el límite más honesto: Carbon-aware Scheduling reduce las emisiones de las cargas de trabajo desplazadas. No reduce la demanda absoluta de energía. Quien quiera hablar en serio sobre la sostenibilidad en la TI, no puede evitar temas de eficiencia: mover menos datos, modelos más ligeros, políticas de retención limpias, manejo consciente de la infraestructura inactiva. La programación es una palanca, no la respuesta.
Recomendación
Para los equipos que operan muchas cargas de trabajo por lotes, vale la pena el desplazamiento en el tiempo como primer paso: baja complejidad, ahorro sólido, sin trampas de residencia. El desplazamiento de ubicación es interesante si Multi-Region ya está establecido y los datos lo permiten – de lo contrario, se vuelve rápidamente caro. La formación de la demanda vale la pena para algunos productos bien elegidos con componentes críticos de latencia y computación intensiva, pero no como iniciativa transversal.
Quien trata Carbon-aware Scheduling como un tema de arquitectura, lo introduce en las discusiones a las que pertenece: selección de región, diseño del programador, diseño de datos. Quien lo trata como un tema de comunicación, construye una etiqueta que mueve poco. Los patrones de la Green Software Foundation no son un manifiesto – son un vocabulario con el que se pueden tomar estas decisiones de manera limpia.
Preguntas frecuentes
¿Necesito una herramienta especial para la programación consciente del carbono?
No. Para un piloto, basta con un contenedor Cron que consulte una API de intensidad y retrase el inicio del trabajo. Las características de la plataforma como KEDA-Carbon-Scaler o los modos de procesamiento por lotes propios del proveedor son útiles cuando se deben coordinar varias cargas de trabajo.
¿Qué tan confiables son las señales de emisión?
Buenas para la mezcla actual de la red en la mayoría de las regiones europeas. Las previsiones de varias horas son útiles, pero no exactas. Quien optimiza para previsiones de minutos, arriesga una programación inestable. Más robusto: combinar umbrales y tiempos máximos de espera.
Conflicto con la residencia de datos: ¿cómo manejarlo?
El cambio de ubicación solo dentro de un clúster de regiones legalmente liberadas. Las especificaciones de residencia suelen ser más fuertes que cualquier regla de carbono, por lo que es necesario coordinar con la privacidad de datos y el cumplimiento antes de que un programador pueda seleccionar regiones.
¿Vale la pena la programación consciente del carbono desde el punto de vista financiero?
A menudo neutral o ligeramente positivo: los momentos de baja intensidad de CO2 coinciden con frecuencia con tarifas eléctricas fuera de pico y disponibilidad de instancias Spot. Al cambiar de ubicación, el tráfico de salida puede anular el efecto, por lo que siempre hay que tener en cuenta los costos de red.
¿Qué definitivamente no es adecuado para la programación consciente del carbono?
API síncronas orientadas al usuario. Sistemas transaccionales con presupuestos de latencia estrictos. Cargas de trabajo con tiempos de respuesta vinculados a SLA. Aquí, la formación de la demanda sigue siendo el único camino, y es un tema de producto, no una decisión de infraestructura.
Fuente imagen de título: Pexels / Alfo Medeiros (px:15418504)
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
