Why a reproducible model matters

Teams face two recurring tensions when evaluating edge and serverless options. Shorter network paths can cut energy spent on data transmission while distributing compute can create replication and idle overheads. Without a clear model and measurement plan there is a high risk of optimistic assumptions and greenwashing. The rest of this article gives a repeatable research style framework you can apply to any workload so results are auditable.

Core factors that drive emissions

At a high level each user request triggers three types of work that map to energy use and carbon emissions. State each type explicitly when you build a model.

• Compute work executed in functions or containers. This covers the CPU and memory energy consumed during request processing and any idle or background overhead required to keep the runtime ready.
• Network transfer between client, edge locations, origin servers, and any intermediate caches. Energy per byte varies with technology and distance.
• Storage and persistence such as object reads, database queries, and replication. This includes I O energy and any additional copies created by regional replication.

Each of these energy components is multiplied by the carbon intensity of the electricity that powers the infrastructure, and by facility level overheads such as power usage effectiveness. Architectural choices that alter any component can shift the balance from lower to higher emissions.

Variables to collect and instrument

Design your model around observable metrics. The following items are the minimum you should measure or estimate for each deployment option and for each deployment region.

• CPU time per request in seconds or CPU-seconds. Use runtime traces or provider execution metrics.
• Memory allocated and time held measured as GB seconds for serverless platforms that bill or report memory time.
• Network bytes per request both inbound and outbound across each hop.
• Storage operations per request including reads, writes and their regional replication counts.
• Invocation rate and concurrency to derive utilization and idle overhead.
• Cold start frequency if cold starts require significant extra work or longer runtime initialization.
• Regional grid carbon intensity expressed as grams CO2 per kWh for the data center region at the time of interest.
• PUE power usage effectiveness for the facility or provider region when available.
• Replication factor number of active replicas for the function or storage per request served.

The core equation

Use a per request emissions formula built from measurable parts. Express all energy terms in kilowatt hours for a single request and then multiply by carbon intensity.

Emissions per request in grams CO2 = (E_compute + E_network + E_storage) × PUE × CI

Where each component is defined as follows.

• E_compute equals CPU energy plus memory energy. Derive CPU energy from CPU seconds multiplied by average CPU power draw in watts. Derive memory energy from GB seconds times memory power per GB.
• E_network equals total bytes transferred multiplied by energy per byte for each network segment. Separate client to edge, edge to origin and inter datacenter links if you can.
• E_storage equals I O energy cost for reads and writes plus any additional cost for replication.

After summing these energy components convert kWh to grams CO2 using the regional carbon intensity CI in grams CO2 per kWh. Multiply by PUE to include facility overheads. If a request triggers operations in multiple regions apply the appropriate CI and PUE for each region and sum the resulting emissions.

How to use sensitivity analysis rather than single point estimates

Many inputs vary with traffic patterns, time of day, and provider reporting. Run a sensitivity sweep across realistic ranges for the most uncertain variables. Common candidates for sensitivity analysis are network energy per byte, cold start frequency, and utilization driven idle overhead. Present results as ranges and identify break even contours where one architecture becomes cleaner than the other.

Illustrative calculation workflow

The following workflow is a reproducible way to produce an audit ready comparison. Replace placeholder instrumentation with your concrete measures.

1. Collect baseline telemetry for the current centralized serverless option. Export CPU seconds per invocation, memory GB seconds, request bytes, storage operations, invocation rate and cold start counts over a representative week.
2. Deploy a functional equivalent at the edge with the same code path and collect the same telemetry for the same workload or a controlled synthetic replay.
3. Map telemetry to energy: convert CPU seconds and memory GB seconds to energy using device power profiles or provider reported energy coefficients. Convert bytes to energy using network energy per byte estimates per hop.
4. Apply regional CI and PUE to convert energy to grams CO2. If a request touches multiple regions apply the regional factors where the work occurs.
5. Run sensitivity sweeps for cold start rate, replication factor and network energy per byte. Report median and percentile results and show the break even lines where emissions are equal.
6. Document assumptions, instrumentation methods and time windows so results are reproducible by another team member.

Common scenarios and qualitative decision rules

These rules help prioritise where to run the full quantitative comparison.

• If requests are heavy on network transfer and the edge reduces long haul traffic substantially the edge is more likely to lower emissions, provided additional replicas do not create large idle overhead.
• If requests are compute heavy and edge replicas are underutilised the additional compute replication often raises emissions compared with a highly utilised central region.
• If regional grid carbon intensity differs markedly use region aware routing to prefer low carbon regions. The emissions impact can outweigh small network savings.
• If cold starts are frequent and cause large initialization work then edge deployments with many cold starts per unit time can increase energy use despite lower network distance.

Practical optimization levers to test

When a model shows an edge option raises emissions it also reveals which levers are most effective to reduce impact. Typical levers include improving cache hit rates to reduce origin fetches, increasing utilization through request routing or batching, reducing cold start work by slimming runtimes, and choosing regions with lower carbon intensity for replicas. Use the model to estimate the marginal effect of each lever before implementation.

Reporting format for stakeholders

Present results in a compact set of reproducible metrics. Include per request grams CO2 for each architecture, the range from the sensitivity analysis, the dominant contributors by percentage, and the assumptions and data windows. A simple graphic that shows break even contours for replication factor versus network energy per byte makes tradeoffs tangible for product and procurement teams.

Next steps for teams

Start by instrumenting the metrics listed earlier. Run a small controlled experiment that replays real traffic against both deployments and apply the core equation. Use the resulting model to prioritise engineering work that reduces the dominant emission source rather than relying on intuition. Keep the model and raw telemetry alongside release artifacts so future audits can reproduce the comparison.