Carbon Emissions as a Non-Functional Requirement

Carbon emissions feel like costs in terms of non-functionals. In many cases, the cost is not actually listed as a hard non-functional requirement, but every architect knows that we strive to minimise it where possible and we’re often working to a rough budget. This is how I see carbon emissions too. It's a non-functional need that I want to minimise initially and reduce further incrementally over time. It's not necessarily a fully-fledged non-functional requirement with well-defined criteria to meet. We speak to our clients and business owners about budgets and cost appetite; to ensure carbon emissions have the same type of treatment, we should discuss it early and throughout delivery.

Much like cost, it will be important to understand the priority of carbon emissions from the off. To some, cost will be less of a priority than other factors and the same goes for emissions – knowing the value of it will help decision-making throughout delivery. In those cases where it is a high priority, we can balance other requirements around this, potentially reducing availability, scalability, or performance, or changing how we apply existing patterns (for example, ramping down auto-scaling more quickly after a peak in throughput). Where it is a lower priority, we may simply have to optimise it within greater constraints, though I suspect there is still a lot that can be done.

Greener Approaches to Architecture  

The way solutions and software are architected can significantly impact the carbon emissions produced. Network transfer, PaaS vs IaaS, resource utilisation, among many other things, have a part to play.

The impact of our architectural decisions on cost is well understood and architects excel at understanding the cost implications of their designs. I expect in five years’ time the same will be said about emissions impact, but it's certainly not the case yet. And for web-based solutions, there's a whole side of the equation that we can't easily monitor: end-user energy use.

It's not easy to know what your decisions may mean in the context of environmental impact, and it's certainly not simple (or possibly even feasible) to calculate hard numbers outside of those provided by cloud tools. There isn't really a framework to guide us, shared knowledge is limited, and this seems to be backed up by the views of those I've spoken to. I did come across a few things that I felt could help architects (or anyone else) wanting to think about the emissions impact of their decisions.

First is this snippet from the Green Software Foundation's Software Carbon Intensity Specification, which provides three categories that all actions to reduce emissions of a piece of software will fall into:

• Energy Efficiency - Actions taken to make software use less electricity to perform the same function.
• Hardware Efficiency - Actions taken to make software use fewer physical resources to perform the same function.
• Carbon Awareness - Actions taken to time or region-shift software computation to take advantage of clean, renewable, or low-carbon sources of electricity.

I personally find this a simple mechanism to consider, at a high-level, how specific architectural decisions might impact emissions, especially when combined with information from cloud providers about the granular emissions impact of different services.

Secondly, I came across Principles of Green Software Engineering. This provides a starting place for some high-level principles, as well as a few examples of how to apply them (click through each one to see a more detailed description, it’s not immediately obvious you can do this!).

The eight principles within look to be a reasonable starting point for making greener architecture and design decisions, though I can't claim to have had the chance to see them in action. A concern I have is that they could be quite hard to apply; I find a good principle is easy to understand, providing a simple decision-making framework – I’m not sure how true that is here. The principles are not all immediately obvious and on the surface feel like they overlap. However, I do think the examples demonstrating the application of the principles are useful. It occurs to me that open sharing of more of these tangible, by-example implementation patterns, considerations and guidance would be incredibly useful to the technology delivery community.

Finally, I also came across the Green Software Foundation projects page, which, in addition to a number of other interesting projects, has a project to create and share “research, tools, code, libraries and training for building applications that emit less carbon”, which you can find here. This looks to provide a curated list of available tools as well as articles and research in this area. Unfortunately, much like the Principles of Green Software Engineering, I feel this is lacking tangible implementation details. There is no easily consumable list of specific things you might apply to your design or development approach to reduce carbon emissions. Additionally, the list has had few updates, with none in the last six months. While a useful point-in-time view, it doesn’t appear to be a living list.

Sustainability and Continuous Delivery

Many of the things we do as part of the development and release process could have an environmental impact: automated tests running on every change, repeatedly rebuilding assets that have had no changes, intense scale and performance tests, non-production environments sitting around under-utilised. It feels like some of the ideals of continuous delivery could even run counter to the ideals of green software delivery.

I expect several environmentally conscious things could be implemented in the development and release processes, though some will come with a considerable implementation cost and most will need factoring into plans early to avoid costly changes down the line. Change-aware automated testing and asset build, well-managed ephemeral environments, delaying build activities to reduce carbon intensity – these are just a few things that came to mind, but none are simple, iterative changes, they would all require being designed early.

Another thought that came to mind was Environmental Debt, when, in a similar way to technical debt, we know we could do something in a way that has less carbon impact but chose not to, instead of expediting delivery. We could log these instances as items of Environmental Debt, which would be refactored in a later release or as part of continuous improvement time. While this risks creating a dumping ground of tickets that are never revisited, in a team that is bought into this approach and has non-functional requirements of sustainability, it may provide a continuous improvement mechanism that is well understood by engineering teams today.

Conclusion

It feels like the time is right to start widening the environmental lens to software development, share experiences, and raise awareness. The drive to improve the sustainability of technology solutions is a real thing and this article has considered some areas that could support this drive during the development of software: considering sustainability as a non-functional need, discussing sustainability goals with clients and business owners, architecting solutions to reduce carbon emissions, and developing software approaches that give due consideration to environmental impact, such as Environmental Debt. Even where these things may not be possible, considering cost as a reasonable analogue for carbon emissions may aid those delivering software by providing an easily accessible lever to achieve greener solutions.

I’d be keen to hear from anyone who has applied green software principles to software delivery, especially those who may have experience of those implementation patterns and thoughts on which provided the greatest benefits. You can find me on LinkedIn here.