A product team needed fast image thumbnails for users around the world. The original design used a central serverless function in a single cloud region that generated thumbnails on demand. That design gave correct images but some users saw slow responses. The team considered two alternatives. One was to run the image worker as edge serverless functions distributed to many locations. The other was a hybrid where a central processor created thumbnails at upload time and a global CDN served cached results.<\/p>\n
Architecture changes emissions through three linked channels. First, network transfer changes. Delivering bytes from a nearby edge or a CDN reduces long distance transfer and the backbone work inside network operators. Second, compute changes. More locations often mean more separate compute instances, higher idle overhead and more cold start events unless usage is well amortised. Third, electricity carbon intensity varies by region. Running compute in a low carbon grid reduces emissions for the same energy use while running the same work in a high carbon grid increases them.<\/p>\n
The team set up a repeatable experiment to avoid guesswork. The core idea was to measure the same user requests on different architectures and map energy use to carbon using regional grid intensity. The steps below describe the minimum viable approach to make the tradeoffs visible and auditable.<\/p>\n
The team compared three architecture patterns and tracked how each influenced the channels described earlier.<\/p>\n
Compute happens in a small set of regions, usually near the origin storage. Advantages include fewer duplicated artifacts, simpler caching relationships, and more predictable cold start patterns because traffic concentrates in a few places. Drawbacks for a global user base include longer network paths and higher user perceived latency for distant requests.<\/p>\n
Functions run in many locations close to end users. This reduces client perceived latency and lowers network backbone transfer. However the same workload may be executed in many places, increasing total compute instances and potentially raising cold start frequency unless functions remain warm. If functions run where grid carbon intensity is high the carbon per request can increase even if energy use is similar.<\/p>\n
On upload, an origin process precomputes and stores thumbnails. A global CDN then serves cached images to users. This pattern shifts compute from request time to upload time and maximises cache hits for subsequent reads. The tradeoff is extra compute at upload and additional storage or origin egress, but in many cases it reduces repeated runtime compute and long distance transfer.<\/p>\n
The following criteria helped pick the lowest carbon option for each workload profile. Use them as heuristics, not absolute rules.<\/p>\n
During testing the team tried several optimisations and measured their effect on the relative carbon outcome between options rather than assuming the direction of change.<\/p>\n
They moved to serve most user requests from cached thumbnails by generating images at upload time. That reduced repeated serverless invocations and lowered network egress when the CDN was able to serve nearby users. For images that were truly unique they introduced size quotas and client side downscaling guidelines to reduce per request work and transfer.<\/p>\n
On the edge deployment they reduced function memory allocations to better match the measured working set. This lowered billed vCPU units and reduced idle memory time. They also introduced a small warm pool for the busiest locations to reduce cold start frequency while measuring whether the energy cost of the warm pool was outweighed by fewer cold starts.<\/p>\n
For both serverless and edge variants the team tuned cache TTLs based on update patterns so cache invalidation did not cause unnecessary origin invocations. They also batched some low urgency image conversions to run on schedules in a preferred low carbon region when policy allowed.<\/p>\n
Edge increased carbon in two recurring scenarios. The first was low cacheability combined with moderate compute per request. When each request performed expensive CPU bound work and caching was ineffective the edge pattern caused many separate compute invocations across locations. Total energy rose compared to a single centralised pool that could amortise startup and background overhead.<\/p>\n
The second scenario involved high cold start rates across many regions. When requests were sporadic each edge location started functions frequently. The energy cost of repeated initialization and the extra control plane activity raised the energy per useful operation. Mitigations such as provisioned concurrency reduced cold starts but introduced baseline energy use that also needed measurement.<\/p>\n
To make claims auditable the team published the measurement method and the raw metrics they collected. They included CPU time, memory seconds, network bytes, cache hit rates, function invocation counts, and the exact carbon intensity sources used for each region and time window. They reported per request energy proxies and the resulting CO2 equivalent per request for each architecture. This allowed stakeholders to review assumptions and reproduce the comparison.<\/p>\n
If you cannot measure, assume more than one outcome is possible. Edge serverless can reduce carbon when it meaningfully lowers repeated network transfer and when compute per request is small or well amortised. It can increase carbon when compute per request is large, cacheability is poor, cold start rates are high or many edge locations sit on carbon intensive grids.<\/p>\n
Start with these actions. First, profile the workload to understand per request compute and cacheability. Second, run the same representative traffic against candidate architectures and collect the same set of runtime metrics. Third, convert energy proxies to emissions using region specific grid intensity and publish the method so others can verify it. Fourth, test simple optimisations such as precompute at upload, cache TTL tuning, matching memory to actual needs and selective provisioned concurrency before making a final architecture decision.<\/p>\n
Use the experiment described here as a template for other workloads. Image resizing is instructive because the split between compute and cacheable bytes is easy to control. For other workloads such as APIs, video processing or AI inference adjust the representative request set and the energy proxies you collect. Keep the focus on comparable measurements and traceable assumptions so architecture decisions reduce real emissions rather than shifting them invisibly.<\/p>\n","protected":false},"excerpt":{"rendered":"
This case study explains how moving a serverless workload toward the edge can lower emissions in some situations and raise them in others. Readers will learn a practical measurement workflow, the variables that matter, and clear decision criteria to pick the lowest carbon architecture for a given workload.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","footnotes":""},"categories":[106,82,4],"tags":[],"class_list":["post-622","post","type-post","status-publish","format-standard","hentry","category-cloud-architecture","category-edge-computing","category-sustainability"],"aioseo_notices":[],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false},"uagb_author_info":{"display_name":"Webcarbon Team","author_link":"https:\/\/webcarbon.io\/news\/author\/webcarbon_wqpz61\/"},"uagb_comment_info":0,"uagb_excerpt":"This case study explains how moving a serverless workload toward the edge can lower emissions in some situations and raise them in others. Readers will learn a practical measurement workflow, the variables that matter, and clear decision criteria to pick the lowest carbon architecture for a given workload.","_links":{"self":[{"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/posts\/622","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/comments?post=622"}],"version-history":[{"count":1,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/posts\/622\/revisions"}],"predecessor-version":[{"id":623,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/posts\/622\/revisions\/623"}],"wp:attachment":[{"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/media?parent=622"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/categories?post=622"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webcarbon.io\/news\/wp-json\/wp\/v2\/tags?post=622"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}