Carbon Aware Cloud

Olivier Bierlaire — Tue, 07 Mar 2023 13:33:48 +0000

Microsoft recently announced that Xbox will now be "Carbon Aware". It will download updates during periods of low carbon intensity on the power grid.

Can we imagine doing the same for a cloud infrastructure? Can we imagine a carbon aware cloud? Public cloud providers are constantly improving their environmental impact by, for example, saving water or building solar plants. However, the virtual machines we spin up or the computing tasks we trigger are completely up to us. And there is room for improvement.

What is the problem with data centres?

According to the International Energy Agency, data centres consume between 220 and 320 terawatt-hours (TWh) of electricity, which is around one percent of the world's electricity demand in 2021. Data centres account for around 0.3% of all global CO2 emissions. While this number may seem small, it can be compared to the total emissions of countries like France, UK or Australia!

Projections published by Nature suggest that the electricity demand of Information and Communications Technology (ICT) will jump to 20% of global electricity. To put this in perspective, ICT currently has the same carbon footprint as the aviation industry, and data centres account for 20% of it according to the Shift Project. This share is only expected to grow!

Energy Forcast of ICT - Nature

First, measure your cloud carbon footprint

There are tools available to analyse the carbon footprint of your cloud infrastructure. Major public cloud providers have released tools for this purpose:

AWS Carbon Footprint Tool
Google Cloud Carbon Footprint
Microsoft Azure Sustainability Calculator

Various open-source initiatives, like Cloud Carbon Footprint, can analyse your cloud provider bill, get resource usage, and estimate carbon emissions.

Other tools, like Scaphandre, rely on monitoring agents to measure the electric consumption of your machines.

There are many methodologies to estimate power consumption of your cloud resources. Basically, if you know the underlying models of the CPU, memory, disk, or GPU, you need to multiply it by their usage percent over time, and you will have the power consumption in kilowatt-hours (kWh).

Having the power consumption is the most difficult part. Once you have it, there are various methods to estimate CO2 emissions from it.

The key part is multiplying your power consumption (E) by the carbon intensity of the electricity consumed (I).

But, what’s the carbon intensity of the electricity ? Cloud provider might provide some net value, taking in account their effort to offset carbon (basically net zero according to Google), but realistically electricity used by data center comes from the regional grid. So, depending on where the data center is located, electricity can be more or less “clean”:

We can even get a real time value from projects like Electricity Maps

Then, reduce your cloud carbon footprint

Once you know how to measure your carbon footprint, it's time to take action! The first thing that comes to mind is making software more energy efficient. However, on the infrastructure level, there are choices that can be made.

Move to an Hyperscaler provider

Moving to a hyperscaler cloud provider can have a significant impact. Public cloud providers, such as AWS, GCP, and Azure, are constantly working to lower energy bills by improving water cooling, among other things.

Choose your region wisely

According to Google, hosting in Paris can result in a carbon footprint as low as 59 gCO2eq/kWh, while in Frankfurt it can jump to 269. By choosing a "greener" region in the same neighbourhood, the impact on carbon footprint can be massive!

Follow the sun

Carbon intensity varies a lot during the day because of renewable energy which depends on weather conditions. During a windless night, carbon intensity is worse than during a windy and sunny day!

Scheduling a heavy task, like machine learning, where it’s daylight can be a powerful way to reduce the carbon footprint of asynchronous tasks.

Leverage Infrastructure as Code (IaC)

Infrastructure as Code (IaC) tools like Terraform enable infrastructure automation. Your infrastructure is described in a machine-readable file, which can be analysed and generated (templates, variables). Changing the region of an infrastructure could be as simple as changing the value of a variable.

By reading these Terraform files, tools like Carbonifer can compute the size and number of virtual machines in your infrastructure and estimate the carbon footprint in gCO2eq/h.

Integrating such a tool with your Continuous Integration (CI) could raise alerts when you reach a threshold of CO2 emission estimation for any planned changes to your infrastructure (thanks to GitOps).

Accept loss of quality

There is virtually no limit to the performance of your software, regardless of the cost in money. Having more and bigger machines can ensure customer satisfaction with features like Ultra HD streaming and instant responsiveness. However, during a dark, cold winter when electricity relies on fossil fuels, it may not make sense to prioritise these features. Cloud companies could reduce their quality of service slightly to remain within their climate commitments. Tools could be developed to resize "autoscaling groups” when the carbon intensity of the cloud is high.

Carbon Aware Cloud

Although there is not yet a fully integrated solution for a carbon-aware cloud, various tools, automations and methodologies can help in the following ways:

Estimate the CO2 emissions of a deployment
Analyse the Carbon Footprint of an existing infrastructure
actively pilot your infrastructure according to the carbon intensity of the grid

By changing the hosting region, selecting a better time of day, or accepting a lower quality and automating these actions, there are ways to reduce our cloud carbon footprint.

OPSoletes: Are Sysadmins/Ops becoming things of the past?

Olivier Bierlaire — Wed, 08 Feb 2017 13:26:32 +0000

At first, I was a developer. One day the guy in charge of the infrastructure/ops resigned and my boss asked me to take over his duties. Well… The handover was basically me asking dumb questions like “What the hell is SystemD?”, “Why do you want me to use docker?”, “Amazon? The bookstore?”… Again, I was a dev…

When he left, I still had no idea of what needed to be done in order to host our brand new web application. I learned.

One day, we asked an AWS expert to consult us. He taught me how to deploy an entire AWS EC2 infrastructure in few hours. He showed me how cool are AutoScaling Groups and Cloud-init/Userdata. And we started a new infrastructure, from scratch, with only 3 basic concepts:

User-data/Cloud-init

When you spin a new instance up in the cloud, you can add a little script. That script (user-data or cloud-init) is executed as soon as the machine is up. You can use it in order to set up your Linux server, install packages, get your code and run it!

#!/bin/bash
# Install NodeJS
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
# Install git
sudo apt-get install -y git
# Get our code
git archive --format=tar --remote=https://login:pass@github.com/mycompany/myproject.git HEAD | tar xf -
# Run the app
cd myproject
npm start

AutoScaling group (ASG)

Even if you don't need to “Auto-scale”, it is an elegant way to manage your machine(s). Imagine you have an API server, you need 3 instances in order to be highly available, you just tell your ASG to start 3 machines (using userdata to set up and run your api server). If you need 4, scale-it to 4 in one click. When a machine dies (memory full, etc), it will automatically be replaced! You need to upgrade, no problem, once you have updated your ASG (a new Launch configuration actually), you can kill one instance, it will be replaced by the new one with your new version! yay! Rolling upgrade!

Elastic Load Balancer

In order to have one public endpoint you can place an Elastic Load Balancer in front of your Autoscaling Group. It will also perform health checks for helping your ASG replacing unhealthy instances. Done: you have a single public endpoint!

Seriously, the AWS consultant helped my workmates and I to set this up in one afternoon. One afternoon. You don't need more to have a robust infrastructure, no need to have a multi-year experienced ops background.

Of course, we also needed databases, a file storage, etc. The key is Managed Services. Cloud providers like Amazon or Google can provide it in one click. No need to take care of backup, logs, patch, etc. They will manage it for you.
By the end of the day, even if I was the Designated Ops Survivor, the entire dev team was able to deploy a new version of our code on our servers, on a real robust, highly available infrastructure, auto-managed by the team.

My job as ops expert became more about exploring new techs rather than dealing with daily issues like backups, patches, installing new versions of our app, etc.

That's why I'm thinking Sysadmins, ops, etc as a thing of the past. A few companies will probably still need them. Amazon need some in order to offer us a nice sparkling AWS Cloud! But if you are a start-up, creating a web application as a lot of us, you don't need to deal with linux patches. You need to focus on your business. With Cloud providers and a DevOps oriented organization: an infrastructure can be managed by the dev team. You can use the leverage of the IAAS (infrastructure as service) without the burden of sysadmin daily duties.

Are ops OPSolete?

Forem: Olivier Bierlaire

Carbon Aware Cloud

What is the problem with data centres?

First, measure your cloud carbon footprint

Then, reduce your cloud carbon footprint

Move to an Hyperscaler provider

Choose your region wisely

Follow the sun

Leverage Infrastructure as Code (IaC)

Accept loss of quality

Carbon Aware Cloud

OPSoletes: Are Sysadmins/Ops becoming things of the past?

User-data/Cloud-init

AutoScaling group (ASG)

Elastic Load Balancer