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.

Where do we go from here?

“Don’t Panic!” - Douglas Adams, The Hitchhiker’s Guide to the Galaxy

Perhaps we should have had Douglas Adams’ quote on the cover of this book because we’re not doomers. We believe humanity will adapt to and mitigate climate change and survive and then thrive on our new renewable power sources. 

However, not all enterprises, organizations, or software systems will. They will have to adapt or die, as the saying goes.

The good news is that our industry is beginning to wake up. Five years ago, it was controversial to talk about green software at a tech conference because the subject was seen as “political”. Now, you would have to be somewhat behind the times (another British understatement) to think green software was anything but a pragmatic move. 

The purpose of this book is a practical one. We want to help folk create systems that can handle the transition from the highly dependable, seasoned, but carbon-intensive fossil-fueled electricity grids of the past to the new renewably-powered ones of the future. In addition, those systems need to use hardware more efficiently.

<Sidebar>As an aside, you may have noticed we made no attempt in this book to convince anyone of the reality of climate change. If you don’t see any cause for concern in the famous hockey stick shaped graph of global temperature rises over the past millennia, you aren’t part of our target audience.</Sidebar>

As we said at the beginning, the energy transition isn’t going to last forever. Eventually, the solar, wind, nuclear, and battery combo will be humming and we will have more and cheaper power than we do today. That time will arrive faster than we think. However, in the meantime we are switching humanity over from energy sources with which we have had hundreds of years of experience to brand new ones. 

Let’s face it, homo sapiens got bloody good at fossil-fueling and we aren’t going to be as good at renewables for decades. That means we consumers of electricity need to lend a hand.  

Why us?

The tech industry and its use of electricity isn’t the biggest contributor to climate change. Nor are we the most difficult to decarbonize - we aren’t agriculture, manufacturing, transportation, or buildings. Data centers are the cause of only a few percentage points of fossil fuel energy use, although if you include embodied carbon waste from all those phones and other devices our impact is higher. 

We are not the worst culprit but that doesn’t matter. We are still a culprit. It is necessary for every industry to cut their emissions and we get no special pass. There is no silver bullet to climate change. We can’t just fix one or two sectors to solve the problem. We all have to get our direct and indirect emissions down to close to zero.

Even if we didn’t have a social imperative to reduce our emissions, we have plenty of commercial ones. Our industry runs on electricity and the electricity market is in the process of being revolutionized. Always available, fossil-fueled electricity is being replaced with lower cost but variable renewables. Batteries and nuclear can provide a degree of availability at times of no wind or solar, but they will add materially to the electricity’s cost. 

Going green is not just about battling climate change, it is about adapting to a new world. Systems that use demand shifting and shaping to run on low carbon electricity will have far, far cheaper power. Often free. That is starting to be true even now, and the companies that can make excellent use of this new power will win. 

Power is the carrot but there is also a stick. At the time of publishing, the European Union will have just introduced a new set of regulations called the Carbon Border Adjustment Mechanism (CBAM). The CBAM imposes tariffs on imports of goods into the EU and of services provided to EU citizens. These tariffs are related to the greenhouse gasses emitted directly or indirectly during their production. 

In the beginning, those import rules only apply to heavy polluting industries like steel and coal, but within 9 years the EU expects them to apply to all goods and services. In future, that means to access the EU market we’ll need to have accurate numbers on our scope 1, 2, and 3 emissions and we’ll pay hefty taxes on them. Tech companies will have to step up and comply with CBAM in the same way we all had to adopt the GDPR. Except CBAM will be a lot more difficult. 

<Sidebar>The European Union’s General Data Protection Regulation (GDPR) applies to any organization that wants to collect data about EU citizens. It came into effect in May 2018, and just before that there was a scramble by companies worldwide to get their heads round it and comply - with hefty fines if you got it wrong. 

The lesson here is the EU knows how to throw its weight around and has plenty of form for doing so. Their attention is now on greenhouse gas emissions and they have no intention of letting companies from outside the EU, in countries with lower emissions standards, undercut EU businesses.</Sidebar>

The problem is, this is tough stuff. Going green is the most difficult challenge our industry has faced. For many companies, it will take ten years to get from level 1 of the Green Software Foundation’s Maturity Matrix, which we covered in Chapter 12, to level 5, and it looks like 10 years is all the EU is going to give us. At best. It might well be less.

Moving through the matrix

In Chapter 12, we talked about the Green Software Maturity Matrix and how we have to move up it. For most of us, that means climbing from level 1 (barely started on efficient and demand-shapeable and shiftable systems) to level 5 (systems that can run 24/7 on carbon free electricity). 

Achieving level 5 is a long term project. We will have to take it gradually to give new tooling and green platforms time to develop. However, we can all start work immediately at getting to levels 2 or 3. For that, we only need operational tools that are already available. 

With some focus, we believe most of us could cut carbon emissions from our existing systems in half within six months. That is our challenge for all our maturity matrix level 1 and 2 readers (i.e. pretty much everyone). 

The Green Software 50% Challenge

“Or how I cut my emissions in half using common household objects”

How on Earth could you cut your emissions by 50%, fast, and without buying expensive tools that don’t even exist yet?!! Using the superpower of currently being rubbish. A much underrated superpower in our opinion. 

The good thing about being at level 1 of the Green Software Maturity Matrix is there is plenty of low hanging fruit immediately in front of you. You have several quick and relatively easy options to cut your emissions:

• Identify and switch off those zombie servers that aren’t doing anything (or anything much). Remember, as we discussed in chapter 4, this alone saved VMWare 66% on their emissions when they moved one DC in Singapore.

• Do a one-off rightsizing exercise on all your servers because everything tends to be overprovisioned to start with.  

• Are you turning off your test systems in the evening and on weekends?

• Because of its extreme multi-tenancy, the cloud already uses only a fraction of the electricity of an on prem DC. AWS claims to be 3.4 times more energy efficient than an average US DC and 5 times more efficient than a European one. Move some stuff to the cloud. (Note - you could also call on your non-cloud hosting providers to be more efficient. That isn’t likely to pay off inside 6 months but you need to play the long game if you want to stay out of the public cloud).

• If you are already in the cloud, review your instance types. Could you be using spot or Burstable instances or autoscaling?

• Many clouds are now offering instances based on more efficient Arm chips (for example, AWS’s Graviton that claims up to a 60% reduction in carbon emissions for an identical service).

Let us remind you that cloud veteran Pini Reznik told us that in his experience, "An average cloud system can cut its resource consumption and bills by up to 50% just using ops best practice tuning and optimization." And that’s before you move to Arm processors. This is relatively straightforward stuff with a huge impact.

You can measure the scale of cut you’ve achieved by the reduction in your like-for-like hosting bills. Hosting cost is only a rough proxy for emissions but it’s good enough at this stage and it’s simple to explain and track. No clever tools required! 

Hurray! You’ve saved loads of money and you are now working on level 2 of the maturity matrix.

<Sidebar>Hosting cost isn’t a perfect emissions measure but it will do. It gives you something to track progress against and the ability to do year on year deltas. Chapter 9 also describes other possible proxies. The ‘like-for-like’ comparison could be based on visitor or order numbers. Pick whatever you are already using for your like-for-like reporting. If you aren’t doing any, take a look at the retail sector where like-for-like sales is a ubiquitous metric that takes into account a variety of things including time of year.</Sidebar> 

The hosting bill reduction is not a straight cost saving because work will be required to deliver it, but it is an emissions reduction. 

For this level 1->2 challenge, you should be aiming for a manual audit, rightsize, and cleanup rather than a regular, automated one - that would be better but don’t run before you can walk. Automation needs to happen on a later rung of the maturity matrix. “The perfect is the enemy of the good”, as Voltaire said. We start manually and automate eventually.

What next?

There are already commodity tools and services out there that happen to be green, mostly because that saves money for the folk operating them. Maybe they are code efficient at scale, like some cloud services, or deliver good machine efficiency, like serverless, or support demand shifting, like spot instances. You need to start using them.

You may have noticed the green platforms that already exist are mostly in the cloud. That’s not because Jeff Bezos is secretly a social justice warrior. It’s because efficiency is coupled both with being green and cutting operational costs. That means hosted services at scale get a huge win from making themselves efficient. The payoff for the providers - who are the ones that have to put in the effort to achieve efficiency - is far greater than for open source tooling where you are the one saddled with the hosting bills.

<Sidebar>We are consequentialists. We don’t care what the motivation was behind a piece of code being carbon efficient, we only care whether it is or not. As we said in the introduction, this book isn’t about your soul, it’s about your planet. A carbon dioxide molecule has the same effect on the climate whether it was put into the atmosphere by a saint or a sinner. 

The behavior of gasses is wholly determined by statistics, which makes it the ultimate realm of utilitarianism.</Sidebar>

As we said in the introduction, we already know much of what we need to do to cut the next 30% or 40% off our carbon emissions and, again, we don’t need to do much measurement to achieve it and nail most of level 3 of the maturity matrix:

• Make sure your hosting provider or operations team has extremely tough carbon zero hosting targets. Compare them with the cloud and pile on some pressure.

• Ensure machines are hosted on grids and in regions with a high renewable or nuclear mix (AWS currently has 19 sustainability target regions, for example).

• Choose only green platforms that are committed to a low carbon future and have a community that will hold them to that commitment. Move to those platforms if necessary.

• Choose an architecture that will support demand shifting and shaping (i.e. usually not always on monoliths).

• Set high bars for operational efficiency and machine utilization because the best way to both cut emissions and embodied carbon is to use fewer servers. The public clouds are comparatively very efficient. Again, that is because of scale and incentives rather than saintliness. We don’t care. In most cases we can cut our emissions very significantly by moving to a public cloud and using its services well (‘lift and shift’ buys you something but you need to move way beyond it).  

• Design products and systems to support demand shaping and shifting for carbon awareness.

• Do less and be lean in your approach. Don’t build and save stuff before need.

• Make sure your software is never the final nail in the coffin for working end user devices because of the lack of backwards compatibility or security patches.

• Build basic performance metrics into your systems and do at least basic performance analysis. Resolve any egregious bottlenecks that you find (and you will). They are just bugs that are slowing you down, costing you money and emitting greenhouse gasses. As we said in chapter 3, performance is often a good proxy for carbon emissions.

• Start to automate the rightsizing you did at level 1 and look at LightSwitchOps so you can turn off systems at will if you think they are no longer used. You’ll need some simple metrics for that too so you can spot low activity servers.

• For code that has to run all the time, make it efficient.

Green platforms are a key part of this story. Code efficiency can be difficult and expensive. For most of us, it needs to be something we demand of our tools and platforms rather than build ourselves (apart from fixing those obvious performance bottleneck bugs). We must all put pressure on our suppliers for green platforms and if they don’t comply, switch to ones who will.

This phase of greening your systems is tougher to measure but it is possible. The public cloud providers now all have basic carbon footprint tools (we talked about this more in chapter 9). If you are not in the cloud, you need to ask your hosting suppliers to start giving you footprint information. You can still act without data but you’ll be flying somewhat blind, and in the long run you are going to need it to do business in the EU.

If you manage to get here, you are more-or-less at level 3 of the Green Software Maturity Matrix.

To everything there is a season

At this stage we could talk about measurement and tuning systems and getting to levels 4 and 5 of the maturity matrix, but we won’t. That’s because at this stage it’s of limited use to the majority of folk who will be reading this book. Getting to levels 2 or 3 would be a massive achievement in itself. 

<Sidebar>We’ll cover getting to levels 4 and 5 of the maturity matrix in edition 2, assuming there’s sufficient demand to get another edition. Let’s call it a cliffhanger. Decent tools and platforms should be available by then. At this point, it would all be custom.</Sidebar>

Getting emissions data out of your suppliers and doing the simple cleanup actions we’ve talked about above will take a while. If you’ve done it already, well done. Now you need to automate it. If you’ve already done that, you’re the ones who should be writing the book.

If you start taking detailed measurements and tuning your code before you’ve got rightsizing sorted and your ops in good shape and automated then you’re wasting your time. As we have said before, efficient ops is more fundamental than efficient code to green software. You could spend 3 years optimizing your monolith for efficiency, cutting its cpu and memory usage by 95% or more, but if you run it on the same server you’ll have a more or less identical carbon footprint. Your efforts would be wasted if you didn’t get the ops right first. 

In terms of priorities, nail operational efficiency and basic performance testing and cost cutting, then demand shapeable and shiftable architectures, then worry about code efficiency (and ideally get that through green platforms).

The cost?

In Bill Gates’ book, ‘How to Avoid a Climate Disaster’ he talks about a ‘green premium’. This is the cost of going green and how we need to reduce it to zero.

In the tech industry, the great news is hosting costs are not subject to a ‘green premium’. When we go green we reduce machine counts and electricity use and save money. In fact, as we discussed in chapter 11, FinOps (minimizing the operating costs of a system) is a very effective way to reduce your greenhouse gas emissions. Going green saves money. 

Unfortunately, that still doesn’t mean going green is a no brainer for tech. There are real potential dangers depending on how you do it. Specifically, there are risks to developer productivity if you attempt to make your own code highly efficient, such as reimplementing your systems in Rust or C. You'll soon hit the problem that it can be a lot of work, so there are opportunity costs.

Proposing an approach focussed primarily on code efficiency could derail a green initiative because no one is willing to give up development speed. In an uncertain world, the last thing anyone wants to sacrifice is their ability to react fast. We authors don’t want you to either and we don’t believe it is the right definition of green software. We define green software quite differently.

“All the things!”

Green is what all software is going to have to be from now on. It's not a niche. So it must fulfill all our needs. It has to be: productive for developers, and resilient, and reliable, and secure, and performant, and scalable. 

It has to be all the things.

At the start of this book we defined green software as software that is carbon efficient and aware, but that isn’t really correct or, at least, it’s only partially right. A true definition of green software is that it meets all our modern needs AS WELL AS being carbon aware and efficient.

In this book we’ve often talked about this as if, "luckily, with green software you can have it all!" because indeed you can. However, that isn't luck. We are pushing a specific vision of green software that can meet all these needs because it has to get universally adopted. 

Physically, you could reduce your expectations of many of the requirements above to cut emissions. You could at least halve them if you gave up on reliability, for example. You could rewrite your code in C to increase efficiency 10 or even 100 fold and have your developer productivity go out the window. You could only run when the sun is shining and have the suckiest latency in the world. However, your boss may be less sanguine about the plan. 

<Sidebar>In some contexts you could, in fact, downgrade reliability, or performance, or developer productivity. In that case, the above options would work very well. They are just not the mainline.</Sidebar> 

Fundamentally, if your green strategy can’t work for a business at scale then it’s not green - it’s a form of wishful and well meant greenwashing. 

Then how?

The good news is in the tech industry we are in the fortunate position of being able to avoid most of the costs of going green. Even better, we can improve our performance on all of our other goals whilst at the same time reducing emissions. We can have it all!  How?!! The same way that we have made most of our astonishing progress in the past decade: via code reuse.

Code reuse

If code is hard to write and maintain, like highly efficient code or hardware-efficient multi-tenancy platforms, then we need to make sure that it gets used loads and loads of times by loads and loads of people to make it both work well (because test in production has always been a thing) and worth the investment. 

In the tech industry, that means one of two things: open source or services, particularly services provided at ultra scale.

Security experts have a saying: “never roll your own crypto[graphy].” The reason is that it’s extremely hard to get security design right. Nevertheless, we still have security. We just use security and encryption products and services, of which there are plenty, rather than attempt to implement it ourselves. We have high expectations that those tools and platforms are secure. We demand it. If they weren’t, we wouldn’t use them. 

By using tools that do their job well, as well as security we get developer productivity, scalability, performance, and resilience (usually those are also requirements placed on a security tool or service). Now is the time for us to start having the same expectations of our platforms for carbon efficiency and awareness. We need that AS WELL AS scalability, ease of use, security, resilience, and performance. All at low cost. 

It is achievable. 

However, we must demand green platforms that deliver all the things because if we don’t ask, we don’t get.

So, what is Green Software?

Green Software isn't climate friendly carbon efficient and aware software. Or it isn’t only that. Low or zero carbon is necessary but it isn't sufficient. 

Productive for developers, cheap, resilient, secure, performant, and scalable. Green software has to be all these things too before it can eat the world. That means we need to demand tools and services that enable us to do it all. We need green platforms. Then we must use them.

It won’t be easy. But it will be green.

Epilogue

“There is much good work to be done by every one of us and we must begin to do it.” - Wendell Berry

You are probably thinking, “Finally, these three have finished!” Hold your horses—we are not done quite yet. 

We have talked about carbon throughout this book, but we can’t ignore the fact there are other environmental impacts that we also need to pay attention to. Water supply (especially clean), plastic pollution, ecological damage from mining precious metals for hardware to name but a few. 

Water is starting to get a lot of attention because our latest tech sensations, LLMs, require a boatload of DCs to train and operate. However, there is still not enough noise about the other aspects and this is where you can come in. 

We techies are famously good at solving problems, so we ask your help to kick off conversations about all the stuff we haven’t talked about so far. Reading this book was merely the start. 

Until next time, ciao from Sara, Sarah, and Anne! The saga of techies for the planet shall be continued in revision 2 of the book!