Building Green Software by Anne Currie, Sarah Hsu and Sara Bergman, published by O'Reilly is available here under a CC BY-NC-ND Creative Commons license i.e. you can read it and quote it for non commercial purposes as long as you attribute the source (O'Reilly's book) and don't use it to produce derivative works.

You can buy the book from good bookstores including Amazon in all regions (currently on offer in the UK). or read it on the O'Reilly site if you are an O'Reilly subscriber.

Carbon Awareness

“Carbon-aware computing is the quick-win every green software practitioner should know about.” - Your favorite authors. 

We learned in Chapter 2 that not all electricity is the same; some is deemed dirty because it was generated from higher-carbon resources, such as oil or coal, while some is considered clean because it was made from renewable or low-carbon sources, such as hydro or nuclear. The idea of doing more in our application when electricity is clean and less when electricity is dirty is what we call carbon-aware computing. 

Carbon-aware computing is the new and very cool kid on the block. It’s an area of software engineering that is gaining an incredible amount of traction. According to the Green Software Foundation’s 2023 State of Green Software Report, we learned that “carbon-aware software is central to decarbonization.” Among the survey participants, although only 8% currently practice carbon-aware techniques in their development, another 46% were eager to start.

We should also give massive kudos to the public cloud providers for leading by example in communicating and publishing their major advancements in the space. For example, Microsoft announced that Windows Update became carbon-aware starting with Windows 11 in September 2022. Similarly, Google shared that they have been using carbon-aware approaches across the board since May 2021.   

So, in this Chapter, we will present another way of achieving greenness within our software system: by applying carbon-aware techniques. We will start by addressing how to tell if electricity is clean or dirty and what we can do to our applications with this new piece of information. Then we will move on to our favorite topic of discussion: drawbacks you must consider (so you're fully equipped to respond to any question on the topic with our favorite line: 'it depends'). Finally, we wrap up the chapter by examining some real-world examples so you will feel inspired to start your own quest right away!

Carbon Intensity of Electricity

Whenever and wherever we need electricity to power anything, we usually plug our electronics directly into a wall socket, and that’s pretty much the end of the story. This thoughtless assumption that all electricity is clean, hence low-carbon, is mostly because we don’t smell or see dirt when a wall socket is used (maybe school trips to fossil fuels power plants should be a thing?). 

How can we, the very end user of electricity, tell whether that energy is clean or dirty? Before we share how you can find out, let’s quickly review the distinction between the two states and how to tell them apart. 

It’s not just the software industry but, basically, all industries that are now the primary users of a metric called carbon intensity. It measures how much carbon dioxide equivalent(CO₂eq) is emitted per kilowatt-hour (kWh) of electricity consumed. 

If you remember what we talked about in Chapter 2, carbon is a convenient way for us to refer to all Greenhouse gasses (GHGs). The standard unit of measurement for carbon intensity is grams of carbon equivalent per kilowatt-hour (gCO2eq/kWh). And with this standardization, we can now differentiate the environmental impact of electricity usage.   

Let’s say you can plug your laptop directly into a wind farm; the carbon intensity of the electricity you are getting would technically be zero (without considering the impact of the materials making up the wind farm, of course!). However, it’s not really possible for anyone to use electricity directly from a wind farm. 

Most of us don’t have a choice in what we get from the electricity grid; we simply get a mixture of anything accessible at that moment (coal-powered electricity with a side of wind-generated sprinkles, maybe?). The carbon intensity of electricity for our day-to-day usage is a mash-up of all the currently available power resources in a country’s national grid, which includes lower and higher-carbon sources. 

Electricity grids are a tricky topic, especially how they operate across different countries and how differences in operations can affect a region’s electricity market and, hence, the global market. If you want more information on those fascinating topics, we recommend you check out the International Energy Agency's (IEA) resources. 

Ultimately, the metric of carbon intensity is what most of us mere mortals need to understand so we can tell dirty and clean electricity apart. Take Google Cloud, for instance; they label a region as “low carbon” when the grid's carbon intensity stays under 200 gCO2eq/kWh. 

Understanding this metric isn't just about software efficiency; it establishes a mental model that encourages us toward a broader goal- the efficient and intelligent utilization of low-carbon electricity!

Variability of carbon intensity

You are probably familiar by now with the fact that electricity's carbon intensity has a variability side to it. It’s a metric that is affected by geographical location and times of day. 

Some regions, such as Taiwan or the United Kingdom, have the geographical advantage of enjoying very breezy weather all year round; therefore, wind-generated electricity is easy to come by. In fact, it was reported that wind farms overtook gas-fired power plants in electricity generation for the first time in the UK during the first three months of 2023. 

In contrast, most Nordic countries have hydropower as their primary renewable energy source since they have the joy of having abundant water resources (mostly from rivers) all year round. 

However, even if you are in a region with all the latest in renewable technology, complete with gleaming solar panels covering your entire roof, you may still need to find alternative electricity sources when the Sun decides to take an extended break and withhold its rays, or the wind stops blowing. Owing to the unpredictable nature of weather conditions everywhere, the carbon intensity of electricity is subject to fluctuations over time. 

Today, the expectation of a constant supply of electricity is tightly ingrained in modern society, where any minor interruptions, such as power cuts, are seen as exceptions rather than the norm. In other words, almost every single one of us expects energy at all times and in most places. 

So, how do the electricity grids around the world deal with the unpredictable nature of renewable energy supplies while supporting the demands of their tiny tyrant customers? We will spend the following section briefly covering the workings of electricity grids and some of the key contributing factors that make up energy markets. 

Electricity demand 

Demand for electricity changes throughout the day, and supply always needs to meet that demand. The difficult job of maintaining a reliable service typically falls to each country’s national grid. They are responsible for ensuring the delicate balance is maintained between the amount of electricity they deliver and the amount of electricity their customers request. 

National grids require the ability to stop and start power generation at a moment’s notice to serve this purpose, which is generally much easier to achieve with fossil fuels due to their usual ready supply (although we all saw what happened during the energy crisis in Europe in 2022). 

For example, if the need for more electricity suddenly arises, we can rely on coal-burning stations to increase the amount by simply burning more coal or quickly halt the supply by stopping the burning of coal. We refer to how swiftly we can adjust energy production as the dispatchability of a power generation source. 

Brownouts vs blackouts

What happens when supply falls short of the current demand? In such cases, a brownout occurs, which is a dip in electrical voltage across power lines due to a surge in demand. 

A blackout describes when there is a complete failure of electrical power (i.e., no electricity). This can happen when there is more electricity than required, causing the grid to trip breakers to stop infrastructure from burning out. 

In contrast to fossil fuels, renewable sources, such as wind or solar, are less controllable. We cannot will the weather (as much as we might want to), so sometimes we throw away renewable electricity because there is too much of it for a given moment, and we want to avoid a blackout. We call the intentional reduction of electricity supply curtailment.

Marginal power

The demand for more electricity at any specific time does not consistently lead to increased production across all power plants—whether they are renewable, low-carbon, or non-renewable sources. Instead, the required energy is provided by the cheapest power plant with surplus capacity, as power plants are dispatched according to rising costs. The power plant that meets the additional demand is commonly referred to as the marginal power plant.

Consider a scenario where our grid comprises 50% solar and 50% coal sources. If we need to acquire extra electricity at any given moment, the immediate consequence is usually increased production from coal-powered plants because, as noted earlier, fossil fuel-based sources have higher dispatchability. In order to meet any abrupt surge in demand, marginal fossil fuel power plants usually step in, leading to extra emissions referred to as marginal emissions.

The picture we want to paint here is that balancing electricity demands and the energy market is fiddly. As green software practitioners, we should be aware of these concepts so we can be mindful of our systems’ electricity usage and eventual carbon emissions. 

<Sidebar> Imagine waking up to a super hot day in Hsinchu, Taiwan, before the sun even rises. Groggy and disoriented, you make your way through the darkness toward your air conditioner, hoping to turn up the machine to stop the excessive sweating. You are doing this with little thought because you assume Taiwan's well-developed national grid can handle the surge in electricity demand during such weather.

However, you were not the only one to experience this unbearable heat. Every one of your neighbors has already turned up their machine to the maximum to stay cool.

On a typical and not-so-hot day, electricity demand is relatively steady. Hence, the national grids are fine with maintaining the delicate balance between the electricity they supply and the amount their customers ask for. 

However, as you may have guessed, the situation can change rather rapidly, especially during the unprecedented scenarios brought about by climate change. The ever-so-fast increase in demand from everyone can easily lead to blackouts or brownouts. The national grid needs to respond swiftly to avert such situations. 

During this morning peak, when most people are still at home getting ready for work, they have to call upon plants with high dispatchability, such as gas-burning ones. These plants increase the generation quickly by burning more gas. In this scenario, the gas-burning plant becomes the marginal one, as it’s the first to dispatch electricity, which unfortunately results in additional marginal emissions. 

As the morning goes on, people leave to go to the office one by one, and the demand for electricity returns to a steady level, so the national grid can then uphold its sustainability pledge of utilizing more renewable resources. 

Since it’s a day when the Sun decides to play ball, and with electricity demand under control, we are now getting too much solar power. As a result, some of the excess electricity will be thrown away through the process of curtailment.</Sidebar>

Tooling

We have spent some time understanding the carbon intensity of electricity, its fluctuating nature, and, most importantly, the contributing factors that affect the scale of its intensity. What sort of tooling is available out there that can help us absorb this information? And even better, consume and act on it in real-time? 

For practitioners in the UK, there's access to a partnership between the UK’s National Grid, various non-governmental organizations (NGOs), and academic institutions known as the Carbon Intensity API. This Application Programming Interface (API) is powered by machine learning (ML) to forecast the carbon intensity at least 96 hours ahead for each region in Great Britain.

This enables the API’s consumers to schedule their electricity usage to minimize carbon emissions at a regional level. The Carbon Intensity API team’s efforts have led to several success stories, wherein their partners have used the product to regulate their devices based on the cleanliness of the current energy, thereby making a significant contribution to carbon reduction.

For engineers outside of the UK, you are also in luck, as there are several frameworks that can help you out on this front, too. First of all, we have the famous Electricity Maps. Why famous? Electricity Maps has partnered with several leading software players, such as AWS, Google, and Salesforce, to provide their customers with real-time and global coverage of the carbon intensity of electricity. 

Google uses the data to shift its workloads based on the greenness of the current electricity (more on this later) and in its 24/7 carbon-free energy (CFE) reporting. With this collaboration, Google is on track to be the first major cloud provider to operate on 24/7 carbon-free energy. 

<Sidebar>24/7 CFE signifies our capability to consistently align every kilowatt-hour (kWh) of electricity consumption with carbon-free generation, round the clock, every day, and in every location. According to the United Nations, achieving this represents the ultimate goal for a “completely decarbonized electricity system.”</Sidebar>

Electricity Map provides “hourly carbon electricity consumption and production data for over 50+ countries globally (and 160+ zones)”. The data is available in three distinct time frames: historically, in real-time, and as forecasted for the next 24 hours.

SDK, please!

Since we software developers are an infamously lazy bunch, someone has done the hard work and open-sourced a Software Development Kit (SDK) on top of another carbon intensity API (WattTime) to enable faster time to market with carbon-aware techniques (Yay!). 

The Carbon Aware SDK by the Green Software Foundation was the star of the show during last year’s first GSF hackathon, where participants were able to use the toolkit as a Web Application Programming Interface (WebApi) and Command Line Interface (CLI) to integrate carbon intensity information with their solutions. 

There were over 50 finished hackathon projects, from Kubernetes extensions to User Interface (UI) design adjustments. Please head to the Real-World Examples section below to see what caught the authors’ eyes.  

Carbon intensity is one of the most crucial ingredients when it comes to calculating the total carbon footprint of a piece of software or system. We will present a more detailed analysis of toolings in Chapter 8, with strengths and shortcomings considered. 

Demand Shifting

Now that we've established that not all electricity is generated the same way, let’s move on to the million-dollar question: How do we respond to this newfound information, a.k.a. the metric?

Once again, carbon-aware computing is about responding to fluctuations in carbon intensity. At its core, the strategy involves relocating your application to a different time or location in response to changes in a critical benchmark.

Load Balancing (LB) and Content Delivery Networks (CDN) are well-known techniques that the tech industry uses to redirect traffic to areas best equipped to handle request demands based on the current situation. 

If your use case allows flexibility in when and where your software runs, you can consider shifting your workload accordingly. 

For example, if your task is not time-sensitive, i.e., it doesn’t need to be up 99.99% of the time but only once or twice in a given month, like training an ML model. You should then consider training your enormous Large Language Model (LLM) when electricity is the greenest. 

If jurisdictions allow, you can also consider training the model at a location with much lower carbon intensity. But more on this in Chapter 8, where we ponder applying shifting time and place to green Artificial intelligence (AI) practices while also examining what considerations are needed at every stage of an ML lifecycle. 

Demand shifting can be broken down into time and spatial shifting, with the former usually deemed easier to execute than the latter. This is not only because modification on implementation and deployment may be required but also because local law can be a challenging hurdle to deal with where data is concerned (more on those later). 

Time shifting​

Carbon intensity varies throughout the day so if we can delay a workload we could potentially save carbon. This temporal technique is called time shifting, which, in our firm opinion, is one of the low-hanging fruit opportunities that everyone in the business of reducing their software’s carbon footprint should grasp with both hands. 

There are many circumstances out there where we can take advantage of a shift in time to achieve carbon reduction. For example, as previously mentioned, the training stage of an ML model can immensely benefit from running at the time of the day with the greenest energy. Researchers from University College Dublin back this. They reported that practicing time-shifting methodologies for ML models can result in nearly 45% to 99% of software-related carbon reductions. 

Another scenario that can hugely profit from time shifting is batch processing. A batch job is a type of workload that groups multiple tasks and executes one after the other without real-time user input. For instance, software updates and system backups can happen almost anytime in a given period. Microsoft has been scheduling its Windows updates in this manner, resulting in a 99% reduction in carbon emissions. 

The last example we want to note is more on you as an end-user of video streaming or computing gaming. We are all aware of how much electricity these activities consume. So, have you considered exercising flexible viewing such that you pause your 4D streaming when the carbon intensity of the grid is high? Or, instead of watching movies on demand, you download your favorite binge during a clean energy period? Both of those habits can reduce the overall carbon footprint of internet usage. However, this is an individual action, and we know it is the systemic change we need. It would be much better if this happened automatically, and the good news is it can. 

As we discuss in Chapter 7, video streaming services already use caching in locations such as Content Delivery Networks (CDNs) in order to encourage data to be transferred while the internet is quiet. We would love to see customers’ favorite shows automatically downloaded to CDNs or homes during a time when the electricity was greenest. Then, we can all leisurely pursue our treasured programs day and night with a clean environmental consciousness. And, of course, there is also the potential for a return on dollar savings and an increase in the application’s performance. 

Location shifting​

The second category of demand shifting can be summed up well by citing the words of the famous British Rapper, Dave, who sang, “If you send me the location, then I’ll be right there.” 

Similar to what Dave promised to do in the song- swiftly respond and be where he's needed when given a location. If we move our applications to another physical location in response to a change in carbon intensity, it's called spatial shifting.

Spatial shifting can be a fruitful exercise to reduce overall carbon emissions. For example, if we have a long-running application deployed in the Asian locations of Google Cloud Platform (GCP), and if latency (or any other concerns) is not an issue, moving it to a region that naturally has lower carbon energy sources can massively decrease the carbon footprint of the application.  

Relatively short-lived and not real-time computing programs like large-scale data processing and generating 3D animations can also be location-shifting beneficiaries. Those types of scenarios typically just need to get on with it, such as rendering graphics in the 3D animation use case, before producing the end result that most people care about. Location is immaterial.

Demand Shaping 

With the previous demand-shifting strategies of adjusting the timing or location for an application, we are still working with the assumption that there is a constant supply of electricity. However, as already explored, renewable energy supply is never really stable or endless. Therefore, we are proud to introduce another strategy within the carbon-aware family to address this scenario: demand shaping.

Demand shaping is not new to the computing world. The idea behind it has been exercised many times over to fulfill various requirements. For example, video calling applications like Zoom or Google Meet use similar concepts to work with unstable and fluctuating network bandwidth. 

During a call, if your network bandwidth is suffering, the application will automatically reduce the video quality. This prioritizes preserving network capability for audio, ensuring that you can still carry on with a conversation, which is the primary objective of a video conferencing call. 

Another example we'd like to highlight is how progressive web applications (PWAs) effectively tackle network bandwidth issues through various methods. For instance, the progressive loading technique, also called lazy loading, allows applications to load gradually in stages. This approach significantly enhances the app's performance on slow networks by avoiding the simultaneous loading of all resources.

<Sidebar>We talk more about demand shaping’s history in chapter 7.</Sidebar> 

In contrast with the previous example where the concerned telemetry is network bandwidth, for carbon-aware solutions, what demand shaping is most worried about is the amount of carbon dioxide equivalent emitted as a by-product from electricity generation. 

If carbon intensity decreases, we should aim to do more in our software systems and less when carbon intensity is skyrocketing. We could make this happen in two ways: firstly, we can make it automatic; secondly, let the application clients decide. 

The first way should be familiar to most software developers as the technique is well-known to engineers who have to deal with patchy networks or other indicators, such as CPU or memory resources, in the on-demand mode of cloud computing. 

The latter is closely tied to a key concept of sustainability: consumption reduction. We wholeheartedly believe that we can accomplish plenty by becoming more efficient with resources, but at some point, we may all need to start consuming less (at least until the energy transition is complete). However, this is a book about software, so we will not start a philosophical debate between tribes. 

Nonetheless, as green software practitioners, we have the opportunity and the ability to steer how our users use our applications, so we can definitely present options to allow them to cancel a process or stop live streaming when carbon intensity is high. 

Any devil's advocates?

Just like everything else in software, there is a fine line to walk when considering redesigning your application to be more carbon-aware. From the previous sections, we gathered that our workload can be carbon-aware in two ways: demand shaping or demand shifting, where the shift can be in either time or space. All are valuable game plans for reducing software carbon emissions; however, careful consideration should be applied depending on use cases and requirements.

Location shifting can be tricky.

Before we discuss the pros and cons of location shifting, we want to debunk the arguments that have been presented against this approach. Folks have expressed their worry that if most of the world moves all its workloads to a region with low carbon intensity, such as France, we will overload it, leading to increases in application latency, making a region more prone to service outages, and potentially degrading a managed service’s performance with throttling, etc. 

However, we are very far away from this reality. Moving even just one microservice of a software system across regions can be difficult, not only in the technical implementation sense but also in other areas, such as legal requirements for storing data (pesky privacy laws!). 

However, this brings us to the point we want to make about moving applications to a different region to achieve carbon reduction when doing carbon-aware computing: thoughtful review needs to be exercised.

For example, one of the most critical aspects of an application is its performance. Service Level Agreements (SLAs) should never be breached, even at the expense of the environment. Although, revisiting SLAs is not unheard of for many reasons, such as changes in business requirements or tech stacks.

<Sidebar> A service-level agreement (SLA) is a contract between a service provider, such as Azure, and a customer, such as you, an application developer. It documents the service level that the provider promised to deliver for its clients. SLAs typically cover areas such as how long an application should be up for (uptime), when an application should respond to a request (response time), and how long a resolution for an incident should be. There are many brilliant books out there that detailedly describe SLAs; we highly recommend you check out Google’s Site Reliability Engineering book. </Sidebar>

The availability of resources can also throw a spanner in the works; if the region we are shifting our workload to does not have enough resources, then the move cannot be completed. But, of course, we can have enough monitoring in place to make sure we keep track of the carbon intensity as well as the availability of resources to ensure a smooth transition.

Any extra work can increase a team’s responsibility, including setting up additional metrics, all of which can lead to a hike in cloud cost. 

Lastly, as mentioned many times, the regulatory side of things could be the biggest hurdle, given that each country has different requirements and laws on how all things software should be governed.

In the authors’ opinion, location shifting’s counterpart, time shifting, is an approach that may be easier to accomplish. This is because, with time shifting, a lot of the already discussed concerns are not valid. 

For instance, we do not need to worry about moving data across countries and trying to be compliant in a new region. We also don’t need to be as worried about performance and latency. Lastly, costs should be lower since no additional resources are required, and no transfer cost is needed. In fact, latency-insensitive workloads can be much cheaper to operate (for example, by running them in spot instances, as described in Chapter 4).

The final thing we must contemplate is the cost of greener electricity. Currently, we are getting a flat price from our grid provider or even cloud provider in most countries (although not all - Spain and some Northern European countries have already introduced dynamic electricity pricing based on renewables), but there are some complicated behind-the-scenes calculations happening based on the electricity market and price of clean energy. Dynamic pricing will reach us all eventually. Don’t let it surprise you. In the future, carbon awareness will save a lot of money. 

Real-World Examples

What a lucky bunch we are! We get to witness the incredible innovations that are happening across all sorts of software businesses in the carbon-aware computing space. We have seen use cases from mobile phones to data centers. Additionally, Carbon Hack 2022, hosted by the Green Software Foundation, attracted over 50 finished projects of nearly 400 participants to showcase their carbon-aware ideas. Why don’t we spend the next section exploring real-life carbon-aware implementations? 

Google

Let’s start by looking at Google’s effort. They began their carbon-aware journey in 2020 with time-shifting. Every single Google data center, every day, runs a calculation based on hour-by-hour guidelines to help align their computing tasks with times of low-carbon electricity supply. This is done by comparing two types of forecasts for the following day. 

The first forecast, provided by their partner, Electricity Maps, predicts how the local electricity grid's average hourly carbon intensity will vary throughout the day. 

Google then also creates its own internal power usage forecast for its data centers during the same time frame to complement the data provided by its partner. 

Google reported excellent results from their pilot: they effectively increased their consumption of lower-carbon energy by aligning load to periods of low carbon intensity. 

This result was a milestone because it proved that time-shifting is a fruitful tactic. Next, in 2021, Google embarked on a location-shifting quest, where they also reported successfully moving computing tasks that can run from basically anywhere to locations with cleaner energy.

They initially started this effort with their media processing domain, where they encoded, analyzed, and processed millions of multimedia files for YouTube, Google Photos, etc. And, of course, none of those efforts affected how the application was supposed to run, meaning no breach of SLAs or SLOs for those applications. 

Xbox

In 2023, Xbox consoles also ventured into time-shifting after Microsoft’s carbon-aware Windows updates enabled it to become the first carbon-aware gaming console. 

Xbox now arranges game, app, and OS updates at a specific moment during its nightly maintenance time frame, as opposed to the previous random wake-up between 2 to 6 AM. The console will now be powered up at a particular time when the electricity from the grid is the cleanest (providing the console is plugged in and has access to the internet).  

Xbox also announced a new power-saving mode, Shutdown, that can cut electricity consumption by up to 20 times! This new feature saves electricity when the console is off while not affecting the end-user experience in terms of the console’s performance or abilities.

iPhone

Apple also has a slice of this carbon-aware cake. With iOS 16.1, iPhone users can now charge their devices with lower-carbon electricity.

Carbon Hack 22

The Green Software Foundation’s Carbon Hack 22 attracted many innovative carbon-aware projects, especially around addressing the immense energy requirement for training an ML Model. The winner of the hack, Lowcarb, set out specifically to tackle this. The solution was a plugin for Flower, a popular Federated Learning framework, allowing its users to schedule training jobs on clients in various geographic regions.

The winner benchmarked their solution on an image classification problem, demonstrating an impressive 13% reduction in the training’s associated carbon emissions without surrendering “any training speed, final accuracy, or fairness of client selection,” which is an essential requirement in a federated learning setup. 

<Sidebar> Federated Learning is a decentralized ML model training methodology where the model's training happens across data from multiple locations without the data ever leaving its respective place. Because of Federated Learning’s decentralized nature, preserving fairness in client selection is of utmost importance for the model’s accuracy and efficiency. </Sidebar>

There was another hack idea we wanted to highlight that focused on the existing gaps in the current carbon-aware markets. Even though many examples have been tried and tested, the global adoption of carbon-aware demand shifting and shaping is still below the ideal level. 

One of the main difficulties lies in the increased responsibilities the development team will face. They must now re-instrument their application, determine how to deploy and maintain this new feature, and, most importantly, monitor this new concept without compromising their systems’ Service Level Objectives (SLOs).

To help, a carbon-aware solution at the web traffic level was proposed. Instead of instrumenting your already-built web applications with an SDK to react to carbon intensity, the hackathon participants introduced carbon-aware features at the Load Balancing (LB) or Domain Name System (DNS) Level.

Suppose your application is multi-region, and you have deployed it across multiple locations. In this case, you could easily employ this idea to preferentially redirect your traffic to the area with the least carbon intensity without much friction (as long as other load balancing requirements were still met). 

Additionally, in many enterprises, a centralized Networking team could take on the burden of implementing carbon-aware features for the whole firm. So the application team can enjoy the benefits without any hassle! 

You’re Carbon and Aware.

We hope you are now also a fan of carbon-aware practices and that you feel the urge to grab a large bowl of popcorn to watch how this idea is making waves across all corners of software engineering.

We also hope to have inspired you to embark on your adventure right away. Not only do you understand the different carbon-aware approaches, but you are also armed with resources to debate each strategy’s advantages and disadvantages to your heart's content. 

Lastly, let’s not forget the quick win we all should have on speed dial: the simple time shift for our non-temporally critical applications.