Microsoft’s Asim Hussain on Designing Software for Sustainability and the Green Software Foundation

QCon London 2021 · London, Europe

by Asim Hussain · 2 November 2021

▶ talk tech green

Microsoft’s Asim Hussain on Designing Software for Sustainability and the Green Software Foundation

Charles Humble interviewed me for the InfoQ podcast about what “green cloud” really means, back when I was green cloud advocacy lead at Microsoft and chairperson of the Green Software Foundation. It’s a wide-ranging conversation that runs from the placement of a comma in my job title to carbon intensity, load shifting, the embodied-carbon objection, and the measurement problem the whole field hinges on.

AI-generated summary of my talk

Key takeaways

Green isn’t a destination, it’s a direction. A cloud doesn’t become green — you head towards building software that emits the least carbon possible per unit of work, constantly.
Optimise for one variable: carbon. The UN has 17 sustainable development goals; it’s almost impossible to get engineers to optimise for 17. Whatever choice reduces carbon emissions is the right direction.
Electricity is a carbon proxy. Most of the world’s electricity still comes from burning fossil fuels, so using less — and using it more intelligently — is where software people have real leverage.
Carbon intensity varies by region and by time. Grids have lost their old “battery” (coal) and now lean on variable renewables with no storage, which is exactly what makes load shifting work.
A carbon-aware workload behaves like a battery — or a virtual power plant. Shifting load through time and space looks, to a utility provider, just like grid storage, so you’re actively helping the energy transition.
On embodied carbon, hardware wins on devices — but software controls hardware’s lifespan. Servers are mostly electricity; phones and laptops are mostly embodied carbon, and software decides how long they stay useful.
Measurement is the central problem. The Software Carbon Intensity spec is a rate (carbon per user, per API call) that deliberately excludes offsets, so it incentivises real reductions, not neutralisation.

Jump into the talk

Put the comma in the right place

The first thing I told Charles was where the comma goes. I was the green cloud advocacy lead — that’s “green, cloud advocacy”, not “green cloud, advocacy”. Some people genuinely went hunting for a “Green Cloud” service in the Azure catalogue. There is no such thing. The job is really about looking at software through the lens of sustainability: being a conduit between the fast-growing community of green software practitioners — technologists who care passionately about doing their day job more sustainably — and the cloud services at Microsoft. Educating that community, and listening to what they need so it can feed back into the product.

What green cloud actually means

Green isn’t a point you arrive at. The energy powering public clouds isn’t 100% renewable, and depending on the region it might be nowhere near it — carbon is being created. So green cloud is a direction you head in constantly: how do you build applications, and how does a provider build services, that emit the least carbon possible per unit of work.

At Microsoft that sits inside four pillars: carbon, water (data centres are huge consumers of potable water), waste (the “zero to landfill by 2030” goal, with circularity centres that break a failed server down on-site so its parts get reused rather than shipped off), and protecting biodiversity. But my work is squarely the carbon question. The two big sources are embodied emissions — the carbon baked into all the hardware when it’s made and when it’s destroyed — and electricity, which still mostly comes from burning fossil fuels.

One variable, and the thing that surprised me

We wrote the principles of sustainable software a couple of years earlier because, frankly, nobody agreed on what “green” even meant. A lot of what you need to know here simply isn’t taught in a traditional computing education — you can pick it up through your own research, but it takes the best part of a year. The principles condense that into about half an hour so a room can level-set the language.

The first principle is all about carbon. There are people who say optimise for all 17 UN sustainable development goals — but it’s incredibly hard to get engineers to optimise for one variable, let alone seventeen. So we point you in a single direction: if the choice you’re making reduces carbon, it’s the right one.

The second is electricity. Honestly, this was the shocker for me coming in — I had no idea what a major source of global emissions electricity is. That’s also the opportunity: the things we build consume electricity, so if you can use less, you have an impact. The third is carbon intensity: the grams of carbon emitted per kilowatt hour. It varies by region — some grids burn coal, some spin up when it’s windy — but, crucially, it also varies over time. The old grid didn’t need batteries because coal was the battery: need more power, burn more coal. Lean on variable renewables like wind and solar and there’s no battery, so how clean your electricity is now swings hour to hour. That’s what makes load shifting possible — moving a workload to a cleaner region, or a cleaner time.

The embodied-carbon objection

Charles pushed me on embodied carbon — the carbon used to build a piece of hardware, which Anne Currie has argued is typically higher than the carbon it emits running over its lifetime. So isn’t focusing on software focusing on the wrong thing?

My world is about answering: if you’re in the business of building software, what influence do you actually have? Yes, a lot of emissions are in hardware — but the lever software has is making hardware last longer. On phones, laptops and tablets, most of the carbon really is embodied; these devices are built to sip power and have no moving parts to break. So the decision to replace one is driven by perceived performance. Apps start feeling slow because they’re coded for the latest chipsets, or vendors simply stop supporting older devices — I had to replace my mum’s phone once purely because Skype stopped working on it. That’s a software decision. The web has known the answer for years: progressive enhancement. Don’t build for the 1% on the latest iPhone and degrade from there — assume the lower-end device and only layer on extra functionality when you’ve detected the capability is there.

Software that looks like a battery

When you make an application carbon-aware, two things happen. You take advantage of lower-carbon electricity, so you can rightly say your software is emitting less. But you also help the transition: by running when intensity is low, you’re supporting the renewable plants generating at that moment. And here’s the part I love — to a utility provider, shifting load through time and space looks exactly like a battery. Conceptually it’s strange, but for all intents and purposes you are grid storage. The term the industry uses is a virtual power plant; there are startups trying to IoT together the world’s laptop batteries and EV chargers because, collectively, they look like one.

The measurement problem

Every member organisation of the Green Software Foundation named the same thing as their biggest challenge: measurement. The standard tool, the Greenhouse Gas Protocol, assumes everything fits inside one organisation — but software doesn’t. Windows is used by hundreds of thousands of organisations, yet only Microsoft’s own usage lands cleanly in its scope. Open source is worse: there’s no organisation around the project, and almost everything in the cloud is built on it.

So we’re building the Software Carbon Intensity specification. It’s not a total — it’s a rate, an intensity: for Windows, that might be carbon per user. And we’ve taken a deliberate position that neutralisations — offsets and renewable energy credits — shouldn’t count in the calculation. Offsets matter, but if you tell an organisation it can spend twenty million and lose half its roadmap reducing emissions, or half a million on offsets, the investment never flows to the thing that actually needs it. Because the SCI is a rate built from scratch for software, it incentivises real reductions rather than neutralisation — and that’s the whole point.