Sustainable software engineering

estimates to hardware-based telemetry.

• Tooling: Integrate tools like cloud-carbon-footprint for cloud usage estimation or scaphandre / codecarbon for host-level energy measurement.
• SCI Standard: Adopt the Software Carbon Intensity (SCI) Standard from the Green Software Foundation. SCI provides a formula to score software: $$SCI = (Energy \times CarbonIntensity) + EmbodiedEmissions$$
• Implementation: Instrument critical services to report SCI scores alongside standard metrics in your observability stack (e.g., Prometheus/Grafana).

Step 2: Algorithmic and Code Efficiency

Code efficiency determines the computational load. Inefficient algorithms scale energy consumption linearly or exponentially with data volume.

• Complexity Analysis: Audit hot paths for $O(n^2)$ or worse complexity. Refactor to $O(n)$ or $O(\log n)$.
• Memory Management: Memory allocation and garbage collection consume significant energy. Use object pooling, avoid unnecessary allocations, and prefer streaming over loading full datasets into memory.
• Language Selection: For compute-bound tasks, compiled languages (Rust, Go) often offer better performance-per-watt compared to interpreted languages (Python, Node.js), though runtime optimizations in V8/JIT can mitigate this.

Step 3: Carbon-Aware Computing

Shift workloads in time and space to match grid carbon intensity.

• Temporal Shifting: Defer non-urgent batch jobs to times when renewable energy generation is high.
• Spatial Shifting: Route traffic to data centers in regions with lower carbon intensity, provided latency constraints allow.
• Implementation: Use APIs like Electricity Maps or WattTime to fetch real-time carbon intensity and integrate this into your scheduler.

Step 4: Infrastructure Optimization

• Right-Sizing: Continuously analyze CPU/Memory utilization. Downsize instances where utilization is consistently low.
• Autoscaling: Configure aggressive down-scaling policies. Use predictive autoscaling for known traffic patterns.
• Serverless vs. Containers: For sporadic workloads, serverless functions often provide better carbon efficiency due to granular billing and zero idle cost. For steady high-load, optimized containers on bare metal or VMs may be more efficient.

Code Example: Carbon-Aware Scheduler

The following TypeScript implementation demonstrates a scheduler that checks grid carbon intensity before executing a batch job. It integrates with a hypothetical carbon intensity API and implements a threshold-based deferral strategy.

import { createClient } from '@electricitymaps/client';

interface Task {
  id: string;
  priority: 'critical' | 'standard' | 'background';
  execute: () => Promise<void>;
}

interface SchedulerConfig {
  carbonThreshold: number; // gCO2eq/kWh
  region: string;
  maxDeferralTimeMs: number;
}

export class CarbonAwareScheduler {
  private config: SchedulerConfig;
  private carbonClient: ReturnType<typeof createClient>;
  private queue: Task[] = [];

  constructor(config: SchedulerConfig, apiKey: string) {
    this.config = config;
    this.carbonClient = createClient({ apiKey });
  }

  /**
   * Schedules a task based on current carbon intensity.
   * Critical tasks bypass the check; others are deferred if intensity is high.
   */
  async schedule(task: Task): Promise<void> {
    if (task.priority === 'critical') {
      await task.execute();
      return;
    }

    const intensityData = await this.carbonClient.fetchZoneData(this.config.region);
    const currentIntensity = intensityData.carbonIntensity;

    if (currentIntensity <= this.config.carbonThreshold) {
      // Low carbon intensity: Execute immediately
      console.log(`[Scheduler] Executing task ${task.id} at ${currentIntensity} gCO2eq/kWh`);
      await task.execute();
    } else {
      // High carbon intensity: Defer
      console.log(`[Scheduler] Deferring task ${task.id}. Intensity ${currentIntensity} > ${this.config.carbonThreshold}`);
      this.queue.push(task);
      this.scheduleDeferredCheck();
    }
  }

  private scheduleDeferredCheck(): void {
    // Check again after a delay to avoid polling storms
    setTimeout(async () => {
      if (this.queue.length === 0) return;

      const intensityData = await this.carbonClient.fetchZoneData(this.config.region);
      const task = this.queue[0];

      if (intensityData.carbonIntensity <= this.config.carbonThreshold) {
        this.queue.shift();
        await task.execute();
      }
      
      // Re-schedule check if queue still has items
      if (this.queue.length > 0) {
        this.scheduleDeferredCheck();
      }
    }, 60000); // Check every minute
  }
}

// Usage Example
const scheduler = new CarbonAwareScheduler({
  region: 'FR', // France (typically low carbon due to nuclear/hydro)
  carbonThreshold: 50, // Defer if > 50 gCO2eq/kWh
  maxDeferralTimeMs: 3600000 // Max 1 hour deferral
}, 'YOUR_API_KEY');

const batchJob: Task = {
  id: 'etl-nightly',
  priority: 'background',
  execute: async () => {
    console.log('Running ETL job...');
    // Simulate work
    await new Promise(r => setTimeout(r, 1000));
  }
};

scheduler.schedule(batchJob);

Architecture Decision: Event-Driven vs. Polling

• Decision: Use event-driven architectures (e.g., Kafka, SNS/SQS) instead of polling loops.
• Rationale: Polling requires continuous compute cycles to check for state changes, even when no work exists. Event-driven systems allow compute resources to remain idle (consuming near-zero energy) until an event triggers processing.
• Impact: Reduces idle energy consumption by up to 90% for low-frequency operations.

---

Pitfall Guide

Avoid these common mistakes when implementing sustainable engineering practices.

1. Ignoring Scope 3 Emissions:

   • Mistake: Focusing only on cloud compute (Scope 2) while ignoring embodied emissions from hardware manufacturing and supply chain (Scope 3).
   • Correction: Extend lifecycle assessment. Reuse hardware, optimize for longer device lifespans, and choose cloud providers with strong circular economy commitments. Include embodied emissions in SCI calculations.

2. Optimizing for CPU Only:

   • Mistake: Refactoring code to reduce CPU usage but inadvertently increasing disk I/O or network traffic, which also consume energy.
   • Correction: Measure total energy consumption. Network transfers and storage operations have distinct energy profiles. Optimize data locality and compression to reduce I/O energy.

3. Carbon Shifting Without Reduction:

   • Mistake: Implementing carbon-aware scheduling but increasing total workload volume due to the "rebound effect" (efficiency leads to more usage).
   • Correction: Set absolute carbon budgets alongside efficiency targets. Use carbon budgets to cap total emissions, forcing architectural innovation rather than just temporal shifting.

4. Over-Provisioning for "Green" Margins:

   • Mistake: Adding excessive redundancy or over-provisioning resources to handle peak loads, resulting in chronic under-utilization.
   • Correction: Implement precise autoscaling with predictive models. Use spot instances for fault-tolerant workloads. Regularly audit utilization and right-size resources.

5. Neglecting Developer Environment Energy:

   • Mistake: Optimizing production code but leaving developer CI/CD pipelines and local environments inefficient.
   • Correction: Optimize CI/CD runners. Use caching, parallelize tests efficiently, and shut down runners immediately after jobs. Encourage developers to use lightweight tooling and monitor local energy usage.

6. Using Heavy Frameworks for Simple Tasks:

   • Mistake: Loading a massive framework (e.g., full Angular/React bundle or heavy ORM) for a simple microservice or static page.
   • Correction: Match the tool to the task. Use micro-frameworks, static site generation, or serverless functions where appropriate. Minimize bundle sizes and dependencies.

7. Static Region Selection:

   • Mistake: Deploying all workloads to a single region based solely on latency or cost, ignoring carbon intensity variations.
   • Correction: Implement geo-routing based on carbon intensity where latency budgets permit. Use multi-region deployments to shift load to greener regions dynamically.

---

Production Bundle

Action Checklist

• Deploy Carbon Observability: Install cloud-carbon-footprint or equivalent agent to baseline current emissions.
• Define SCI Scores: Implement SCI calculation for top 5 critical services and expose as metrics.
• Set Carbon Budgets: Establish maximum allowed CO2e per service per month; alert on breach.
• Audit CI/CD Pipelines: Identify and eliminate idle runners; implement cache strategies to reduce rebuild energy.
• Enable Carbon-Aware Scheduling: Integrate grid intensity APIs for batch jobs and non-critical workloads.
• Right-Size Infrastructure: Run utilization analysis and downsize instances with <20% average CPU/Memory usage.
• Optimize Data Transfer: Enable compression, implement CDN caching, and reduce payload sizes.
• Review Dependencies: Remove unused libraries and replace heavy dependencies with lightweight alternatives.

Decision Matrix

Use this matrix to select the optimal architectural approach based on workload characteristics.

Scenario	Recommended Approach	Why	Cost Impact
Sporadic, Unpredictable Traffic	Serverless Functions	Zero idle cost; granular scaling matches demand exactly.	Lowers cost during low traffic; potential spike during bursts.
Steady, High-Volume Processing	Optimized Containers on Spot VMs	High utilization efficiency; spot instances offer significant discount.	Reduces compute cost by 60-70% vs. on-demand.
Batch Data Transformation	Carbon-Aware Batch Jobs	Shifts execution to low-carbon periods; utilizes spot/preemptible resources.	Lowers cost and carbon; adds latency variability.
Real-Time API with Strict Latency	Right-Sized VMs/Containers	Predictable performance; avoids cold starts. Optimize code for efficiency.	Moderate cost; savings from right-sizing and efficiency.
Static Content Delivery	Edge CDN / Static Generation	Moves compute to edge; eliminates origin server load.	Very low cost; minimal latency and energy.

Configuration Template

Terraform Configuration for Sustainable Region Selection

This template demonstrates how to configure infrastructure with sustainability constraints, selecting regions based on carbon intensity data and enabling auto-scaling with aggressive down-scaling.

variable "carbon_intensity_threshold" {
  description = "Maximum acceptable carbon intensity in gCO2eq/kWh"
  type        = number
  default     = 100
}

variable "allowed_regions" {
  description = "Map of regions to their average carbon intensity"
  type        = map(number)
  default = {
    "us-east-1"    = 350  # High intensity
    "eu-west-1"    = 200  # Medium intensity
    "eu-north-1"   = 30   # Low intensity (Hydro/Nuclear)
    "ap-south-1"   = 450  # High intensity
  }
}

locals {
  # Filter regions below threshold, fallback to lowest intensity if none match
  sustainable_regions = [for k, v in var.allowed_regions : k if v <= var.carbon_intensity_threshold]
  target_region       = length(local.sustainable_regions) > 0 ? local.sustainable_regions[0] : sort([for k, v in var.allowed_regions : v])[0]
}

resource "aws_autoscaling_group" "sustainable_asg" {
  name                = "carbon-optimized-asg"
  vpc_zone_identifier = [aws_subnet.public.id]
  min_size            = 1
  max_size            = 10
  desired_capacity    = 1

  # Aggressive scaling policies to minimize idle time
  dynamic "tag" {
    for_each = {
      "Name"        = "sustainable-service"
      "CarbonZone"  = local.target_region
      "Efficiency"  = "optimized"
    }
    content {
      key                 = tag.key
      value               = tag.value
      propagate_at_launch = true
    }
  }

  # Use spot instances for fault-tolerant workloads to reduce embodied and operational carbon
  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 0
      on_demand_percentage_above_base_capacity = 0
      spot_allocation_strategy                 = "capacity-optimized"
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.eco_launch.id
        version            = "$Latest"
      }
    }
  }
}

resource "aws_launch_template" "eco_launch" {
  name_prefix   = "eco-"
  instance_type = "t4g.medium" # Graviton processors offer better performance-per-watt

  metadata_options {
    http_tokens = "required"
  }

  # Enable detailed monitoring for precise right-sizing
  monitoring {
    enabled = true
  }
}

Quick Start Guide

Get your engineering team started with sustainable practices in under 5 minutes per service.

1. Install Measurement Agent: Run the following command in your repository to add cloud-carbon-footprint for immediate cloud cost-to-carbon estimation:

   npx cloud-carbon-footprint init
   

   Configure the tool with your cloud provider credentials to generate the initial emissions report.

2. Identify Top Energy Consumers: Review the generated report. Identify the top 3 services consuming the most energy. Focus optimization efforts here for maximum impact.

3. Apply Immediate Efficiency Wins: For the identified services:

   • Enable auto-scaling with a scale-in cooldown of 300 seconds.
   • Switch to Graviton/ARM-based instances if supported (typically 20% better performance-per-watt).
   • Enable compression on all API responses and static assets.

4. Integrate Carbon Check in CI: Add a step to your CI pipeline to fail builds if the estimated SCI score exceeds the baseline:

   # .github/workflows/carbon-check.yml
   - name: Check Carbon Intensity
     run: |
       SCI=$(calculate_sci --service my-service)
       if (( $(echo "$SCI > $BASELINE_SCI" | bc -l) )); then
         echo "Carbon budget exceeded: $SCI > $BASELINE_SCI"
         exit 1
       fi
   

5. Schedule Batch Jobs: Refactor cron jobs or scheduled tasks to use the CarbonAwareScheduler pattern or cloud-native scheduling with carbon constraints. Configure jobs to run only during off-peak hours or when renewable energy availability is high.