# Methodology Our environmental impact calculations all use a Lifecycle Assessment (LCA) methodology. This means we take into account the manufacture, usage, and disposal of all our hardware. To perform this LCA, we follow the [Product Category Recommendations (PCR)](https://librairie.ademe.fr/economie-circulaire-et-dechets/6105-7697-product-category-rule-pcr-for-cloud-services-and-data-centre-it-hosting-services.html#/44-type_de_produit-format_electronique), created by [ADEME](https://www.ademe.fr/en/frontpage/), the French Agency For Ecological Transition. The PCR was developed in collaboration with industry partners, including Exoscale. The impact data we use in our calculations comes from [ResilioDB](https://resilio-solutions.com/en/services/database), developed by [Resilio](https://resilio-solutions.com). The calculations are performed using [LCA-as-code](https://lca-as-code.com/), developed by [Kleis Technology](https://kleis.ch/). ## Concepts The following key concepts form the building blocks of our impact estimation methodology. ### Zones Our infrastructure is divided into **zones**. Each zone maps directly to one data center. You can read more on our [Zones page](https://www.exoscale.com/datacenters/). ### Hardware The hardware included in our impact estimations falls into three categories: 1. **Rack servers** - stand-alone servers with CPUs, GPUs, RAM, storage, power supplies and cooling 2. **Blade servers** - servers with dedicated CPUs, GPUs, RAM, and storage, in a shared _chassis_, providing shared power and cooling 3. **Network equipment** - including switches and routers All hardware exists in a rack, which exists in a room in one of our data centers. ### Types of impact All impact estimates include two types of impact: - **Manufacture** - impacts related to building, transporting and disposing of hardware - **Usage** - impacts related to resource consumption at runtime Note that manufacture impacts are zone-independent, i.e. the impact is the same no matter where the hardware is deployed. Usage impacts are heavily zone-dependent, as the electricity mix and datacenter configuration are different in each zone. ### Pools Resource pools are groups of hardware that are either dedicated to a specific product (e.g. Instances or SOS), or mutualized between products (e.g. shared networking equipment). Each piece of hardware belongs to exactly one pool, and its impact is allocated to users proportional to their usage of that pool. An example is the pool of hypervisors and networking equipment used to run our Instances product in the `ch-gva-2` zone. ## Calculating impact To calculate the impact of a user's usage of a given product, we calculate the total impact of the pools involved in that usage, then share the pool impacts based on the proportion of resources consumed. ### Pool impact The total impact of a pool is: ``` impact_pool = impact_manufacture_pool + impact_usage_pool ``` where ``` impact_manufacture_pool = sum(impact_manufacture_hardware) impact_usage_pool_per_hour = sum(impact_usage_hardware_per_hour) ``` where ``` impact_usage_hardware_per_hour = power_consumption * electricity_impact_zone_per_kwh ``` - `power_consumption` is the average power consumption of a given piece of hardware in kilowatts - `electricity_impact_zone_per_kwh` is the average impact of consuming 1 kWh of electricity from the grid in the given zone, taken from [ElectricityMaps](https://app.electricitymaps.com) ### Allocation ratio To allocate a share of the total pool impact to a given usage, we calculate two ratios, one based on the resources used, versus the resources available in the pool, and one based on the duration of the usage versus the lifespan of the pool: ``` resources_ratio = resources / resources_pool_total time_ratio = duration / lifespan_pool ``` The value of `resources` and `resources_pool_total` will vary depending on the product, and also on the type of impact we are calculating (see below). Specifically: ``` impact_usage = resources_ratio_usage * duration * impact_usage_pool_per_hour impact_manufacture = resources_ratio_manufacture * time_ratio * impact_manufacture_pool impact = impact_usage + impact_manufacture ``` Where `resources_ratio_usage` and `resources_ratio_manufacture` are product-specific, and discussed below: ## Product-specific details As discussed above, each product will have a slightly different methodology. The difference is in how we calculate the ratio of the user's resources to the total resources available in the pool (i.e. the value for `resources_ratio_usage` and `resources_ratio_manufacture`). ### Instances Each Instance type has allocated vCPUs, GPUs, RAM, and attached storage (note that block storage is treated as a separate product). Each GPU has an amount of video random-access memory (VRAM). We calculate Instance impact using the ratio of these resources to the total amount of each resource in the pool, as outlined in the PCR. Specifically: ``` alloc_vcpu = pct_weight_cpu * (vcpu_instance / vcpu_pool) alloc_gpu = pct_weight_gpu * (vram_instance / vram_pool) alloc_ram = pct_weight_ram * (ram_instance / ram_pool) alloc_storage = pct_weight_storage * (storage_instance / storage_pool) resources_ratio = alloc_vcpu + alloc_gpu + alloc_ram + alloc_storage ``` Where - `vcpu_instance`, `vram_instance`, `ram_instance`, `storage_instance` are the vCPU, VRAM, RAM, and storage allocated to the Instance respectively - `vcpu_pool`, `vram_pool`, `ram_pool`, `storage_pool` are the total vCPU, VRAM, RAM, and storage available in the pool - `pct_weight_cpu`, `pct_weight_gpu`, `pct_weight_ram`, `pct_weight_storage` are the weights assigned to each component, and reflect how much impact we attribute to each (see below); note that these sum to 100% #### Component weights The values of `pct_weight_cpu`, `pct_weight_gpu`, `pct_weight_ram`, and `pct_weight_storage` reflect how much weight we give to each component when calculating impact, and are different for the usage and manufacture impacts. When calculating usage impact, these weights are based on the average relative power draw of each component type in the pool. Specifically: ``` power_draw_total = power_draw_cpu + power_draw_gpu + power_draw_ram + power_draw_storage pct_weight_cpu = 100 * power_draw_cpu / power_draw_total pct_weight_gpu = 100 * power_draw_gpu / power_draw_total pct_weight_ram = 100 * power_draw_ram / power_draw_total pct_weight_storage = 100 * power_draw_storage / power_draw_total ``` When calculating manufacture impact, these weights are based on the manufacture impact of each type of component: ``` impact_manufacture_total = impact_manufacture_cpu + impact_manufacture_gpu + impact_manufacture_ram + impact_manufacture_storage pct_weight_cpu = 100 * impact_manufacture_cpu / impact_manufacture_total pct_weight_gpu = 100 * impact_manufacture_gpu / impact_manufacture_total pct_weight_ram = 100 * impact_manufacture_ram / impact_manufacture_total pct_weight_storage = 100 * impact_manufacture_storage / impact_manufacture_total ``` ### Object and block storage Both object and block storage follow the same methodology, based on the ratio of a user's storage to the total storage in the pool. To calculate object and block storage impact, we use the following: ``` resources_ratio_usage = storage_user / storage_pool resources_ratio_manufacture = storage_user / storage_pool ``` Meaning we simply divide the user's storage by the total storage available in the pool, and share total pool impact based on this ratio. ## Shortcomings There are several trade-offs inherent in the PCR methodology, which are discussed below. ### Pooling Pooling resources is key to the PCR methodology, and without it, the methodology would be unfeasible to implement at scale. Without pooling, we would need to track specific hosts, utilization, and power consumption for every workload, which is difficult in a production cloud. Collecting and standardizing this data across all products is even more difficult. While pooling brings many advantages, it also brings the following issues: 1. Workloads do not see the impact of the specific hardware they use. Instead, they see an average impact of all the hardware used to run that product. 2. Hardware lifespan is averaged. Users using older hardware will see no change in impact versus newer hardware with the same resource allocation. ### Idle resources The PCR methodology does not include a factor to account for the level of utilization within a pool. For example, the impact of a given Instance is always the same, regardless of whether that is the only Instance running in an otherwise idle pool, or whether the pool is almost full. This is good because it means that impact estimations are consistent, and not dependent on levels of activity on the provider's hardware. However, it does mean that idle machines are ignored in impact calculations, and the impact of a provider's own (in)efficiency must be accounted for elsewhere.