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.

Chapter 6 - Hardware Efficiency

“It’s hardware that makes a machine fast. It’s software that makes a fast machine slow.” - Craig Bruce

Hardware efficiency? But wait, I thought this was a book about software? After all, we do mention “software” twice in the title. Yes, that is a fair point, but nonetheless, software runs on hardware and it is well worth diving a little further into. No matter if you are a seasoned hardware geek who first learned to code in assembly or someone who just sees hardware as a means to an end, this chapter has something for you.

Hardware in the context of this book means any device that can be used to run software. That covers quite a wide range of different types of devices. Especially given that some enterprising people even implemented the game Doom on a pregnancy test (thankfully not controlled using the original input method). In this chapter we will focus on the two groups of more widely used hardware devices: servers and consumer devices like phones, desktops and laptops. We’ll leave the discussion of carbon efficiency in pregnancy tests to someone else.

As we have seen in previous chapters, in data centers the main problem we can tackle as green software practitioners is electricity consumption. But for consumer devices, embodied carbon is the greater issue, as it makes up a larger share of the overall carbon footprint of the device’s lifetime. In fact, for smartphones the manufacturing cost stands for 85%-95% of the annual carbon footprint of the phone. We are also using more and more of these devices, Deloitte’s 2022 Connectivity and Mobile Trends Survey found that the average US household has 22 connected devices. 

For these reasons it is vital for us as software builders to use less hardware and make what we do use last longer. No matter if you are deploying code to the cloud, to a server in your self-hosted data center or to a consumer device there are concrete actions you can take. This chapter will tell you to make sure your software is not the reason for customers throwing away perfectly working hardware and encourage you to use your consumer power to make hardware producers green their operations and support hardware for longer. We will also talk about device longevity, and how you can achieve it by for example extending the lifetime of the hardware within your control and consider using second hand hardware.

Another fascinating topic is how to build hardware better or more sustainably. But we are not the experts here. Thus, we will only slightly tangent the topic and talk a little bit about what the big players in the industry are doing, as well as recycling and e-waste.

We hope that by the end of this chapter you, just like us, feel that us software developers can and do impact hardware usage.

Embodied Carbon

Hardware comes with an already-paid carbon cost, which we call embodied carbon. To manufacture hardware devices like servers or phones is a quite complicated process. Materials need to be mined somewhere, then shipped around the world (possibly several times) to be assembled, often using an energy intensive procedure, before the device finally lands in your hands. 

This embodied carbon cost of hardware is made up of several components, with integrated circuits being the largest single source of emissions. In Chapter 2, you saw examples of how high this cost could be for end user devices. In general getting the exact embodied carbon numbers is not always easy. In Chapter 9 - Measurements we will show you how cloud providers are reporting on hardware data. The Software Carbon Intensity (SCI) Guidance project from the Green Software Foundation also maintains a list of data sets which provides embodied carbon data from different types of devices.

As software practitioners we have little control over the embodied carbon cost (except by using our spending power). As a green software practitioner, the only remaining thing you can do is to be mindful of the debt that lands in your hand at the same time as your shiny new device and plan for how you will amortize it. There are two main ways to decrease the embodied carbon cost of your software: increase the lifetime of your hardware or increase the utilization of said hardware. This section will cover different ways to achieve these two goals as well as some interesting things for you to consider both as self-hosted and as a cloud user.

Device Longevity

How long do end user devices live? We will give you our favorite answer: it depends. In this case, it depends on the type of device. For smartphone you can expect only 2-3 years of lifetime. Smartphones also have a rapid release cycle, one example is Apple, which release approximately one new iPhone per year. While for gaming consoles the major manufacturers in the industry release new consoles on a roughly 7-years cycle cadence. That means that they design for you to be able to happily play video games to your heart's content until the next model is released. Sometimes even longer than that, for example, the XBox One was designed to last ten years and that appears to be holding up. For servers owned by a public cloud provider the lifetime is 4-6 years. Microsoft announced the extension of server life times from four to six years in July 2022, Alphabet announced the change in expected useful life of their servers and networking equipment to six years in January 2023 and AWS increased their servers expected useful life to five years in January 2022. These numbers are the financial practice numbers, and we cannot say for sure how long the cloud providers actually keep their servers. We welcome increased transparency into this data from cloud providers. 

What determines that you might only get 2 years life time out of a brand new smartphone while a gaming console will last you more than 3 times longer? We can’t completely leave out consumerism and the end-user craving for more slim devices, longer battery life and better performance. End-users have backed smartphone providers into a corner where they need to deliver more performance to be able to adequately compete for market shares. This might be changing as consumers grow more environmentally aware though. One example is the increased growth in sales by the Dutch modular, repairable smartphone Fairphone. Fairphone sold around 120,000 devices in 2022 — up from around 88,000 in 2021 and 23,000 in 2018.

But if we go back to the lifetime of electronic devices and what affects it, one thing which causes us to chuck out hardware, perhaps well before their expiration date, is Moore’s law. 

Moore’s law posits that the number of transistors on a microchip doubles every two years, and other forms of progress mean that devices get new features, which developers want to exploit in their new app releases. Mobile phones, for example, have got faster, evolved to have dedicated GPU and machine learning chips, and acquired more memory. Apps take advantage of this progress, and that is fine and unavoidable. The same holds true for servers, PCs, gaming consoles and kitchen ventilators (yes, they come with apps now).

Another thing that impacts longevity is hardware failure, either mechanical or electrical. Out of the two, mechanical is more common, simply because mechanical parts face more wear and tear than electrical components. For client end devices, you as a software practitioner have very limited leverage in avoiding hardware failures. What we as an industry needs here is to see hardware manufacturers take a bigger responsibility in designing for longevity. We believe that 10 years of use should be the new standard for device longevity.

You might not be able to do much to avoid client side hardware failures, but you have leverage to avoid the kiss of death by software-defined obsolescence, which we’ll dive further into in the next section. 

Software-Defined Obsolescence

Software-defined obsolescence is what happens when support ceases to be provided to a device. This support could include things like regular updates, upgrades or fixes to the device. For the purpose of this section let us consider three different types of this scenario where this can happen for client devices:

1. Manufacturer of device cease support

2. Favorite/Flagship/Important/Vital software on client device is no longer supported

3. Minor/Additional/Nice-to-have software on client device is no longer supported

For the first scenario you, as a developer, are still bound by the device support provided by the manufacturer. For good reasons, users should not hang on to their devices once they are out of security support. As software practitioners, the best we can do here is to push for longer support by the manufacturer.

When it comes to smartphones, the company which has the longest OS support is Apple, where the new iOS 15 supports phones that are up to six years old. For Android phones the market is a bit more diverse, Google, Samsung and chipset maker Qualcomm have all committed to providing four years of security updates for a large selection of their devices and Google is promising 5 years for some of the Pro phones. While this is an improvement from the past, all providers need to improve, even Apple. Device life expectancies must be much longer than six years to justify the embodied cost of the manufacturing process. To compare, gaming consoles provide several years more of expected lifetime than smartphones, they are built to last. This demonstrates that devices can last longer if manufacturers choose it. 

Let us consider the second scenario, a user's favorite piece of software is no longer supported on a device. This requires, or at least heavily entices, the user to throw the device away and replace it with a new one should they wish to continue using the software. The device in question might be working perfectly well for other use cases, shining a bright light of responsibility on the software (and by extension, you as its creator). The same can be said for the third scenario, where a non-favorite piece of software no longer is available to the user on a specific device, although perhaps not to the same extent.

When a working device is discarded because it is missing a piece of software and the consumer buys a new device, a carbon debt occurs. As green software practitioners we of course want to avoid this software-caused additional embodied carbon cost. How to achieve this is simple to explain, but perhaps a little more work-intensive to achieve. The greenest thing to do is to provide backwards compatibility and don’t let your software be a nail in the coffin for a perfectly working device. 

Of course, supporting a wider range of hardware versions, with widely varying technical capabilities, increases both maintenance and testing costs. Luckily, on the smartphone side of things, both Android and iOS have some guidance to provide. Android has a guide for how to make your UI remain backwards compatible, this guide includes key learnings:

• Abstract the new APIs.

• Proxy to the new APIs.

• Create an implementation with older APIs.

• Use the version-aware component.

A guide is good of course, but this will require action and additional work from application developers. Backwards compatibility on Android phones is not a new problem, long ago in 2010 the Android Developer blog ran a post about “how to have your (Cup)cake and eat it too”, outlining some steps to achieve backwards compatibility. 

Cloud Applications And Services

When you run your software in the cloud, one of the things you pay for is not having to bother with asset management. Someone else is responsible for the servers placed in the server room, including how to run them, when to decommission them and, to an extent, how to organize workloads running on top of them. This is often very convenient, as it limits the amount of things you need to bother yourself with and it can also be an argument for why moving to the cloud is a sustainability win. What people mean when they say this is typically that hyper scale cloud providers are more efficient than traditional data centers. This is not magic. Public cloud providers are more efficient because they spend more effort on making their data centers more efficient. After all, selling the cloud is their primary business. For most other companies something else entirely, like selling clothes, is their primary business.

In order for you to reap the benefits of all these efficiency efforts your cloud provider has made, you need to work with the tech and not hamstring it by using the cloud exactly like you would a normal data center. Why is this important? In Chapter 2 you learned about energy proportionality for a server. For a data center we can extrapolate the same behavior, but due to the scale of public cloud providers it is like energy proportionality on steroids. 

Things like PUE and operational costs add on massively in terms of energy cost to underutilized resources. In addition, if you pay for a large virtual machine (for example) but only end up using a small percentage of it, you send the signal to the cloud provider to build more data centers, which in turn means building more carbon-intensive hardware components like semiconductors. 

Capacity planning for the cloud providers is a long haul game and hardware components come with a long delivery time, something made even more glaringly obvious during the semiconductor shortage in the early 2020s. According to Debra Bernstein, Senior Principal Sustainability Technologist at Intel, “The actions we take now will make sure we right-size our industry for the future”. Our Chapter 4 on operational efficiency covered how to help achieve this goal from the software perspective in greater detail, so if you skipped Chapter 4 head on over there for a refresher after you are done with this chapter.

You also want to use the most efficient architecture your cloud provider can offer for your workload. One example of that can be using the AWS Graviton processor powered instances. These are designed exclusively for AWS and are a good option if you are already hosted in their cloud. The Graviton based instances consume 60% less energy than comparable non-Graviton instances in AWS. Not all workloads can run on the AWS Graviton as they implement the Arm64 instruction set. However, a great number of workloads can and in those cases a 60% energy reduction for the price of a config change is a low hanging fruit.

Self-Hosted Data Centers

If you are not writing software for the public cloud, but for your own data center (you are perfectly allowed to call a room of servers a data center in the context of this chapter), then you have more choices to make on the hardware efficiency side. When you are self-hosted, you own asset management. Yay for complete freedom! Yay, analysis paralysis..? If you are self-hosted, you own your sustainability and efficiency strategy. Completely. 

In theory, this means that you can build the most optimized and sustainable data center the world has ever seen. In practice, it takes significant engineering effort to make hardware efficient decisions. We are not aiming to provide the blueprint for the perfectly green data center, but this section will give you some useful tips to guide you on your journey there. Almost everything that was said about operational efficiency in Chapter 4 is true here as well, so don’t skip out on that chapter! 

Most importantly, when you are self-hosted, you control the lifetime of your hardware. Extending the lifetime is one of the best, and easiest, ways to decrease your embodied carbon cost. Remember, the carbon debt of producing a server is already paid to the environment, we can only amortize it and delay further carbon spendings. Let’s take a look at an example of what this could mean.

We assume the embodied carbon cost of a new server is 4000 kg of CO2eq and you originally plan to keep this device for 4 years. The yearly embodied carbon cost is then 1000 kg of CO2eq per year. Now if you extend the lifetime of a server from 4 years to 5 years, your yearly embodied carbon cost shrinks to only 800 kg of CO2eq per year, or 20%. 

When you are on bare metal, e.g. on a dedicated server only used by you typically without an OS or any additional applications, or if you are on-premise, you can get down to the nitty gritty of hardware. Ohm’s law dictates that power is voltage multiplied by current, P = V x I, and that energy is power over time, E = P x t. Taken together we learn that lower voltage means lower energy spendings. On the public cloud, you cannot choose the voltage, but in your own bare metal setup, you can! This is because any given device has a range of voltage (V) where it will operate as intended. This range of V is fairly tight and it will need different tuning throughout the lifecycle of the hardware. Which means that voltage tuning is not really something the everyday software person should or can do, but it is definitely possible and one way to lower the energy consumption on the hardware level. We did promise you nitty gritty, did we not?

If you own your own data center, you also own the “off-button”. One of the main benefits of the cloud is that the cloud never sleeps, however your software might actually go to sleep! For example, if your business does not span the globe you surely have hours of peak-demand and hours of little-to-no demand. During those hours of off-peak demand, you can actually shut your hardware down completely, thus saving considerable energy. “We need to not be afraid to go into low-power states as an industry! Some might not want to take the risk of shutting hardware off, but from a sustainability perspective, it is the right risk to take”, says Debra Bernstein, Senior Principal Sustainability Technologist at Intel. The risk on the hardware side is two-fold, both the risk of not having enough capacity in case of sudden increase in demand and the risk of hardware failure on start-up. These two concepts were discussed more in-depth in Chapter 4, in the section called “LightSwitchOps”. The possible sustainability gain of shutting your hardware off is saved energy use from avoiding having those idle servers consuming energy.

<sidebar>Having to deal with repairs is one of the more tedious parts of asset management. However, if we were to find a silver lining it is that hardware failures can in some scenarios give you rare, green, insights. For example, is it always your disks that kick the bucket the first? This is quite a likely scenario if you have mechanical disks, as mechanical parts are always more prone to failure than electrical components. Knowing this, could you change your software to write to disk less before you actually break the disk? This type of software change that directly impacts your hardware longevity might be rare but for some it could be a hidden gem.</sidebar>

On the server creation side, manufacturers invest significant resources to increase the reliability and lifetime of their products. One example is Intel adding aging "odometers" on the chips which will make it possible to turn off the portion of the chip most likely to fail, but still operate the rest of the chip. Which is pretty cool, but it will need software to help them do so. For example, if 2 out of 64 vCPUs are at risk, what layers of software need to be involved to operate using only the 62 good vCPUs? If you are self-hosted, this is an area where you can work together with your hardware provider to overall increase the lifetime of your servers.

Specialized Hardware

If we take a step back from client devices for a while and go back to our world of servers and data centers, one thing to ponder is is specialized hardware greener than general purpose hardware? With specialized hardware we mean things like Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or Tensor Processing Units (TPUs). This type of hardware can typically take the role of processing units, but they can also be used for other purposes.

According to Debra Bernstein, “When it comes to sustainability and general purpose versus specialized hardware, there is no definitive answer that covers all scenarios. Specialized hardware is good if you deeply understand the problem space and can maximize the utilization of your hardware, because it is more efficient in terms of energy use. It also becomes more sustainable from an embodied carbon perspective, if you will keep the hardware for longer”. 

However, if you have a more generic problem space or a newer problem space you might not yet fully understand then the decision tree grows more branches. You will have to consider whether or not you have the expertise in your organization to write efficient software for your specialized hardware and if this is something you can make a long term bet on. With general purpose hardware, you can always repurpose the hardware later on for new problem spaces, thus increasing the lifetime, ergo get more bang for your embodied carbon bucks. With specialized hardware, this is more difficult and short term energy efficiency wins might not outweigh the embodied carbon cost over time, especially if you have to decommission your hardware after a short time period.

One concrete example of more efficient ASIC use over using a CPU can be found in the field of block ciphers. Block ciphers are used to encrypt (or decrypt) large amounts of data, which is something some pieces of software do quite often. For example, Transport Layer Security (TLS), which can be found not only in the Internet Protocol suite but also in Data Processing Units (DPUs) and the latest Xeon processor, is a cryptographic protocol. In this field, ASICs have been found to be faster and cheaper compared to other types of hardware.

But what about specialized hardware for specialized software? Yes, this is where we talk about blockchains and crypto and their use of GPUs, as well as AI and ML and their use of specialized hardware like AI accelerators. Even though the GPU was originally designed for processing graphics, it turned out to be ideal for the matrix mathematics involved in machine learning and crypto. And yes, this is where we mention Jevons paradox again, which you might remember from Chapter 3. Jevons paradox is the historical observation that when we get more efficient at doing something, it gets cheaper and we all do much more of it. Like mentioned earlier in this chapter, specialized hardware can be great in terms of energy efficiency for specialized use cases. The crux is, when something gets more efficient, e.g. cheaper, you do more of it. 

We saw this for some early AI applications like image processing. The chips got more efficient, thus more image processing was performed, leading to more chips being produced. That in turn means more embodied carbon as the efficiency gains does not map to an equal reduction in embodied carbon. Meaning more chips equals more carbon. To add on to this consideration, you might need to consider more dimensions. Like, does your problem actually need this specialized software solution? This question, for permissions blockchains in particular, has fascinated one of our authors, Sara, since she was in university and she wrote the first ever paper comparing the performance of permissioned blockchains and distributed databases. 

As for the ethics of building specialized hardware for specialized software and its energy use, we’ll defer that discussion for another time.

e-Waste

Electronic waste is typically shortened to the more sci-fi sounding “e-waste” or the more formal Waste Electrical and Electronic Equipment, or “WEEE” for short. The StEP initiative defines e-waste as “a term used to cover items of all types of electrical and electronic equipment (EEE) and its parts that have been discarded by the owner as waste without the intention of re-use.”. And we have LOADS of e-waste. In fact, it is the fastest growing waste stream. According to the UN, the world produced as much as 50 million tonnes of e-waste in 2019 and it is projected to grow to 120 million tonnes by 2050. To put that number in perspective, 50 million tonnes is more weight than all of the commercial airliners ever made. Or if you prefer animal comparisons, 50 million tonnes is the same mass as approximately 250 000 blue whales.

E-waste has several consequences on the climate and our planet. In 2019, only 20% of e-waste was formally recycled, despite e-waste containing lots of precious materials such as gold, platinum or cobalt. Unsafe or informal recycling of e-waste, which happens primarily in developing countries, has high risks of resulting in harm both to the environment and to the people working there. E-waste contains toxic materials such as lead, cadmium, mercury and arsenic, hazardous both to the planet and people. Of course, e-waste is also a direct indication of how many new devices the world needs to produce. Our society depends more and more on electrical devices and rare are the cases when a device gets thrown out without immediately being replaced by something new. Thus creating even more emissions from embodied carbon. Considering the fact that the manufacturing cost stands for 85%-95% of the annual carbon footprint of smartphones, even if the replacement phone is more energy efficient, replacing it is not a green choice.

<sidebar>Okay, so the world throws out a lot of electrical equipment. Of course, not all of this is caused by the software industry, devices which are not traditionally seen as software devices, like refrigerators, TVs and washing machines also count as electrical equipment. With the Internet of Things and Smart Homes these traditionally “dumb” devices are becoming smarter, thanks for software. This is again, fine and unavoidable, but it further highlights the responsibility software practitioners have for the hardware lifecycle. Not only should we consider servers and laptops within our realm of influence. If a consumer throws out their perfectly working dishwasher in order to get the ability to control their new dishwasher through an app, then software is directly causing more e-waste.</sidebar>

That was maybe a bit bleak, we do tend to focus on solutions in this book so let us talk about solutions for a while. What is being done to combat this and how can you help? You might have guessed it, but the key here is to apply the things we have talked about earlier in this chapter, using your own devices longer and making sure you enable your customers to do the same.

Governments around the world are also doing their bit to help reduce this massive waste stream. In March of 2023, the European Commission adopted a proposal including the right to repair consumer goods. This proposal has been approved by the European Parliament and now only needs to be approved by the European Council to make it a reality. This sends a clear signal to the industry, repairs over replacements. If this proposal passes as-is, it will mean legal guarantees to be able to repair goods if it is technically possible. In December of 2022, New York was the first state in the USA to pass a similar bill, requiring manufacturers to repair electronic equipment. In India, new e-waste management rules from the government took effect in April of 2023, providing customers the right to repair electrical equipment. For you as a software engineer, it will likely (hopefully!) mean we will see older client end devices stay on the market for longer. Which in turn makes backwards compatibility even more important to your customers.

There are also more avant garde solutions being proposed by our industry. One of those is the concept of a Junkyard Data Center, which utilizes discarded smartphones as a computing resource. This research project showed that for specific workloads, it is greener (and cheaper!) to use repurposed clusters of smartphones compared to traditional servers, especially from an embodied carbon perspective.

Less avant garde, is the robust second hand market that exists for servers and server room equipment. This can be a great option for both saving cost and embodied carbon.

What Are Hardware Producers Doing To Make Their Operations Greener?

Is the burden all on us as software developers then? Shouldn’t the hardware producers play a part in this? Yes, they should and luckily for us and the planet, many already have targets set up.

Taiwan Semiconductor Manufacturing Company Limited (TSMC) is the world's largest dedicated independent semiconductor company and they have set several targets to make their operations greener. These targets include driving low-carbon manufacturing, like reducing greenhouse gas emissions per unit of production by 40% to 2030, using renewable energy, increasing energy efficiency by saving 5,000 GWh cumulatively between 2016 and 2030, and strengthening climate resilience.

Another heavy-weight figure in the semiconductor industry is Intel. They have also set several climate targets to green their operations. Their 2030 sustainability goals include achieving net positive water, sending zero waste to landfills, and using 100% renewable electricity across their global operations. For their Scope 1 and 2 GHG emissions, the 2030 goal is to reduce by 10% to ultimately reach net-zero in 2040. Intel’s subsidiary, Intel Resale Corporation, also works to help minimize e-waste.

Arm, a British semiconductor and software design company, whose primary business is the architecture, design and licensing of CPUs cores that implement the ARM architecture family of instruction sets. Arm is committed to taking a science-aligned approach to cut absolute emissions, from all scopes, by at least 50% to achieve net zero carbon by 2030 from an FY19 baseline. Among other things this includes sourcing 100% renewable energy, cutting energy consumption and investing in tech-based carbon removal projects.

Apple has several climate targets for their consumer device manufacturing as well. These include producing all Apple devices using 100% renewable energy by 2030 and increasing the use of recycled and renewable material to eventually produce new devices with only recycled and renewable materials.

Microsoft is targeting to be zero-waste for all its direct operations, products and packaging by 2030 and already now have programs for purchasing refurbished devices like Surface and Xbox as well as a recycling scheme.

As the consumer device market is quite large, we won’t cover all of the producers and their targets here, but hopefully this gives you some curiosity to explore your favorite manufacturer a little deeper. 

We do want to say that setting an ambitious target is not the same as reaching said target, so we software folks are not off the hook just yet. Collectively, the software industry and the practitioners who make up the software industry (yes, we’re talking about you now) have massive consumer power over the hardware industry. You can influence hardware producers to ensure that hardware is produced efficiently and sustainably, as well as push for ease of repairs and recycling. 

That Is A Wrap!

No matter what type of software you and your organization writes, you run on hardware. In this chapter we hope that you have been able to pick up some tools to be greener in your utilization of hardware. Not everything will apply to everyone but if we were to give you a summary of our most important tools from this chapter, they would be the following:

• Make sure your software is not the reason for customers throwing away perfectly working hardware.

• Use your consumer power to make hardware producers green their operations and support hardware for longer.

• Extend the lifetime of the hardware within your control.

• Consider using second hand hardware.