.NET, Silverlight, and Prism

By George Stevens, Software Architect and Senior Software Engineer at Solid Value Software

The Case for Sustainable Software Engineering

Stepping back from software, “sustainability” is about the long term sustainability of industrialized societies like ours which are dependent on the current natural systems and processes of planet earth.   Sustainability is concerned with the things we have to do to prevent the irreversible degradation and possible subsequent collapse of some of earth’s natural systems and processes that support “life as we know it” in our industrial societies.  If some key natural systems and processes of planet earth become degraded to the extent they are no longer able to support industrial societies, then humanity will face a lot of self-made trouble as the “goldilocks” environment that has nurtured us thus far fades away.

“For over two centuries and into modern times human ingenuity and the ongoing industrial revolution has led to great advancements, although with significant negative impact on our world’s climate.  Greenhouse gas emissions due to our industrious achievements have contributed to an increase in the earth’s temperature, such that an additional increase of 1.5 degrees Celsius could result in catastrophic outcomes.”  Ref 1. 

Climate change, aka global warming, is a key disruptor here since it has the potential to disrupt multiple natural systems and processes that we depend on.  A central cause of climate change is the increasing amount of “greenhouse gasses” (mostly CO2) in the atmosphere that is emitted by our industrial societies.  The elevated levels of CO2 gas traps heat in the atmosphere, preventing significant quantities of it from naturally radiating back out into space as it did back in the “goldilocks” days.  In turn, the trapped heat increases the temperature of the earth, its atmosphere and its oceans, disrupting many natural systems and processes we depend upon.  Thus, reducing the “carbon footprint” of industrial societies is the antidote to climate change and its disruptions since the carbon it refers to is the C in CO2 gas. I hope the above section provides a useful frame of reference to readers of this paper.  A more detailed, and highly readable, explanation of climate change can be found in Saving Us by Katharine Hayhoe, a well-known climate scientist.  Ref 14.

Throughout this paper I use the term “workload” to mean “some kind of software running on some sort of computer”.  A workload is a software application, a software service, or a database system running on a computer or server.  The total carbon footprint of a workload is the sum of:

1. Carbon emissions created by the generation of the electricity required to run a computer hosting a workload.
2. Plus carbon emissions resulting from manufacturing the computer which hosts a workload.  This is known as embodied carbon. 

In this paper the focus is on ways to reduce the carbon emissions caused by generating the electric power used to run computers hosting workloads.  Ways to reduce the embodied carbon footprint is out of scope of this paper.

The information contained herein comes from various sources including my own education in environmental science (BS) and computer science (MS), plus my decades-long professional experience in software engineering and software architecture.  I explicitly cite all sources from outside my direct experience.  Please see the References section at the end of the paper for sources I reference in the text.  And I thank all the individuals and organizations that contributed to the references cited in this paper.

The goal of this paper is to enable software architects and developers to more easily and effectively decrease the carbon footprint of the workloads they design, implement, and use, so as to reduce the impact of these workloads in driving climate change. Often we use, build, or are responsible for workloads that run 24/7 in data centers and clouds across the globe.  Taken as a whole this consumes a lot of electric power, resulting in a significant carbon foot print. 

The Value Proposition of Sustainable Software Engineering

How big is the carbon foot print of our software workloads?  As of 3/2020 “The carbon footprint of our gadgets, the internet and the systems supporting them account for about 3.7% of global greenhouse emissions…. It is similar to the amount produced by the airline industry globally….  And these emissions are predicted to double by 2025”, Ref 2.  The preceding refers to what is known as the ICT industry:  Information and Communications Technology.  This includes cloud computing which is projected to continue to grow rapidly each year (double digits per year).

Thus, applying sustainable software engineering practices to workloads running on servers around the globe, i.e. converting them to “sustainable, green workloads”, can have a significant impact in reducing global carbon emissions now, and even more so in the future.  Doing so is indeed worth the effort, given the negative disruptive consequences of doing nothing.  And, as you will see in detail later, the effort required to produce “sustainable, green workload” designs and implementations is not really that large, nor that difficult, when compared with the “traditional” unsustainable techniques in widespread use today.  Indeed, a number of the sustainable software engineering strategies, tactics, and techniques discussed herein also can potentially provide other valuable benefits like reducing operating costs by saving energy, plus reducing the lifetime costs of maintaining and evolving a software code base by reducing its complexity.

This line of thinking reveals the Sustainable Software Engineering Value Proposition.  Effectively using Sustainable Software Engineering (SSE) practices typically produces two kinds of value:

1. Survival Value — The decrease in the carbon emissions achieved via “sustainable, green workloads”. Please note that the elapsed time to convert existing workloads to “sustainable, green workloads”, or to build new ones, is on the order of a few months to a few years.  This is a typically a much faster time to realizing the survival value of decreasing carbon emissions than the time it usually takes to build or modify physical infrastructure like transportation systems, sustainable power systems, supply chains, water systems, agricultural systems, etc.  Thus, the widespread use of SSE practices can be a key way to buy time while other sectors with longer time-to-value are ramping up their contribution to other significant reductions in carbon emissions.
2. Economic Value — The potential decrease in the operating costs, plus perhaps also reductions in future software development costs, of workloads that may result as a side effect of using SSE practices to decrease the carbon emissions.  Where they exist (and some projects will not have them) such cost reductions result from many of the SSE practices outlined herein decreasing the energy wasted by a workload as the main way of reducing the carbon footprint.  And reducing wasted energy often acts to reduce cost.  For example, after an SSE “greening” project the number of Virtual Machines (VMs) required to host multiple workloads will likely be reduced since the VMs should now be running workloads at a much higher workload density on each VM. This reduces the cost of the VMs and prevents high levels of unused capacity (waste). Exactly where this applies is outlined in the section “Strategies with their Tactics, and Techniques” below.

This is a really good win/win value proposition — The environment and our society wins, and the individual business wins!  And, some workload “greening” projects have the potential of eventually paying for themselves over time due to cost savings.  I expect that many projects aimed at producing “sustainable, green workloads” by using the SSE practices will have an excellent return on investment (ROI).   That alone is often enough to put an SSE project near the top of an organization’s Todo list.  And this, in turn, acts to increase the pace of counteracting climate change — A virtuous feedback loop.

Another definition of sustainability worth mentioning is broader, “Microsoft has made bold sustainability commitments to be carbon negative, zero waste, and water positive by 2030.”  Ref 3.  These are excellent areas with which to measure and manage sustainability. Combined, they encompass most of the key areas that contribute to long term sustainability of industrialized societies like ours.  Note, however, this paper is solely focused on sustainability via carbon negativity since that falls directly within the realm of software engineering.

Strategies, Tactics, and Techniques of Sustainable Software Engineering

Here are the software architecture and engineering strategies, tactics, and techniques that reduce the carbon footprint of local and global workloads, realizing the SSE Value Proposition. The following eight Principles of Green Software Engineering by Asim Hussain provide an excellent high level overview of what must be done to build software systems and workloads with a reduced carbon footprint, Ref 4.  However, here in this paper we are focused on subsets of these eight principles so that it can directly state the specific techniques that software architecture and software engineering contribute, without going into many of the details of energy, carbon, sustainability, etc.  Please examine the below links for a detailed definition of terms used within the principles SSE, plus how they impact sustainable software systems.

Here are the Principles of Green Software Engineering, quoted from Ref 4.

1. “Carbon: Build applications that are carbon efficient.”
2. “Electricity: Build applications that are energy efficient.”
3. “Carbon Intensity: Consume electricity with the lowest carbon intensity.”
4. “Embodied Carbon: Build applications that are hardware efficient.”
5. “Energy Proportionality: Maximize the energy efficiency of hardware.”
6. “Networking: Reduce the amount of data and distance it must travel across the network.”
7. “Demand Shaping: Build carbon-aware applications.”
8. “Measurement & Optimization: Focus on step-by-step optimizations that increase the overall carbon efficiency.”

Much the same information as above can also be obtained from the highly useful online Microsoft Learn course https://docs.microsoft.com/en-us/learn/modules/sustainable-software-engineering-overview/.  Ref 5.

The newly formed (2020) discipline of Sustainable Software Engineering, aka Green Software Engineering, in part seeks to reduce the carbon footprint of workloads.  There are several strategies for doing this, accompanied by a number of tactics and techniques for each strategy, presented below.  Breaking up the information into strategies, tactics, and techniques provides for using both a large and small granularity of thought and action in the quest to identify areas to change that will reduce the carbon footprint of workloads.  And then to design, plan, and make the required changes as well.

• Strategies are a few high level broad scope actions that can reduce a workload’s carbon foot print.
• Tactics are important focus points and general actions for implementing one or more strategies.
• Techniques are quite specific actions that can be taken to reduce the carbon footprint of workloads.

Strategies

There are at least four clear high level strategies for reducing the carbon foot print of a workload, listed below.  And, they are not mutually exclusive!  Indeed, they can all be applied to suitable workloads so as to compound the sustainability gains achieved.  Or, when necessary, a strategy may be applied individually as well.  These are from the main categories in Ref 8.

• Measure the energy efficiency and carbon foot print of a workload, before and after any optimizations.
• Shape the energy demand and mix of a workload, without changing the workload’s software or data, resulting in a lower carbon footprint.   This is done by shifting the demand for the workload to times and regions having excess capacity.
• Reduce network load and the distance data travels resulting in a lower carbon footprint.  This may or may not require software or data changes.
• Increase resource utilization and decrease waste resulting in a lower carbon footprint regardless of where the workload runs. This may or may not require software or data changes.  This is done mainly by reducing idle time.

Strategies with their Tactics and Techniques

Tactics and Techniques that have references were obtained from documents and links cited in the References section below.  They are cited in the following text by the reference number in the References section, e.g. Ref 3.  In a few cases below, the same Technique can be applied to more than one Tactic.  Thus, I mostly duplicate the text describing such a tactic so that the reader does not have to page back and forth when reading the tactics and their related techniques.

For each item listed below, be sure to check with your cloud provider’s documentation and guidance for ways that you can reduce costs while at the same time building “sustainable, green workloads”.

Strategy — Measure the energy efficiency and carbon foot print of a workload, before and after any optimizations.

The whole area of SSE, aka Green Software Engineering, is quite new.  Articles, blogs, and tools have just started widely appearing since mid-2020 or so.  The terms, measurements, and tools of SSE are now just being defined and produced.

1. Tactic — Use the emerging standard terms and measurements of the Green Software Engineering industry.
   1. Technique — Standard terminology: Use the standard terminology that has emerged, shown above and at this link Principles of Green Software Engineering, Ref 4.
   2. Technique — Standard measurements: Use the standard measurements. However, currently there are few standardized measurements, and fewer tools.  The Green Software Foundation has committed to provide open source tools in the future, as well as standard measurements, and is doing just that, Ref 10.
2. Tactic — Use the emerging measuring tools of the Green Software Engineering industry.
   1. Technique — Measuring tools: Use green software measuring tools.  Currently the only Workload Energy Efficiency oriented tool that I have found (having done a little looking around, but not much) is Microsoft’s free Emissions Impact Dashboard, Ref 6.  I have not yet investigated it.  It measures the carbon footprint of Microsoft Azure resources.

Strategy — Shape the Energy Demand and Mix of a Workload without changing the workload’s software or data, resulting in a lower carbon footprint.

The carbon footprint of a running workload can be decreased by adjusting when, where and upon what compute resources it runs, as follows:

1. Tactic — Utilize a data center’s “excess capacity” so as to increase the utilization of idle resources by a workload. Potential operations cost reduction.
   1. Technique — Change run time or region: “Changing the time or regions for a batch job to run” so they use the excess capacity available during that time or in that region. Ref 8.
   2. Technique — Use “spot pools”. Ref 8. “A spot node pool is a node pool backed by a spot virtual machine scale set. Using spot VMs for nodes with your AKS cluster allows you to take advantage of unutilized capacity in Azure at a significant cost savings. The amount of available unutilized capacity will vary based on many factors, including node size, region, and time of day.”  https://docs.microsoft.com/en-us/azure/aks/spot-node-pool
2. Tactic — Significantly increase the percentage of renewable energy used by a workload. Potential operations cost reduction.
   1. Technique — Move to a better region: Move the workload to a location that is powered by a much higher percentage of renewable energy, like solar, wind, or hydroelectric power.  In other words, run a workload in a region with lower carbon intensity, and thus having a lower carbon footprint. Ref 8.
   2. Technique — Run at a better time:  A given data center may have different levels of carbon intensity at different times of the day.  For example, on summer nights a data center may have much lower carbon intensity since a region’s air conditioners will be demanding much less and not requiring “overcapacity generating units” be on line that exclusively use non-renewable resources.  Thus, one can run some workloads in such data centers at night when the carbon intensity is the lowest.  Ref 5.
3. Tactic — Favor running workloads in a public cloud over running them in on-prem data centers.  Ref 3. Potential operations cost reduction.
   1. Technique — The document “The carbon benefits of cloud computing” in Ref 3 shows the results of a 2018 study that found:
      • “the Microsoft Cloud is between 22 and 93 percent more energy efficient than traditional enterprise datacenters.” 
      • And it gets even better “when taking into account (Microsoft’s) renewable energy purchases, the Microsoft Cloud is between 72 and 98 more carbon efficient.”

Strategy — Reduce network load and the distance data travels resulting in a lower carbon footprint.  This may or may not require software or data changes.

The carbon footprint of the Network usage by a workload can be decreased by decreasing the overall load on the Network.  This is done in 2 ways, however, “never reduce network travel at the cost of meeting workload requirements” from Ref 8.

1. Tactic — “Reduce the amount of network traffic your architecture creates per operation”, Ref 5.
2. Tactic — Reduce the distance traveled over the network by each request and response, Ref 5 Paraphrased.
3. For both of the above Tactics — The above reductions in network travel distance and network load can be achieved by the following Techniques.  Most of the following techniques apply to both of the above tactics:
   1. Technique — Use caches: Use caches to store static assets, as a general rule, to both reduce the network traffic per operation and also reduce the distance the data has to travel. Ref 5, paraphrased, above and below.
      • This includes using browser caches and proxy caches via caching headers.
      • It also includes using Content Delivery Networks (CDNs) to move static assets nearer the application that is requesting them.
   2. Technique — Reduce payload size: “Reduce the size and optimize your bundles and static assets.”  Ref 5.
      • “Compression and decompression (of) the data you transmit over the network” typically “takes less overall energy than transmitting uncompressed data.” Ref 5.
   3. Technique — Transmit binary data rather than characters: Use data transfer objects that are serialized into binary formats rather than character data, resulting in reduced amounts of data traveling over the network thus consuming less existing network bandwidth.  From my professional experience and https://particular.net/blog/transport-cost-is-zero, Ref 11.  Potential operations cost reduction.
      • The serialization/deserialization compute work required to use binary wire formats takes less energy than transmitting the more bulky character data.  And XML is even worse than character data.
        • For example the use of Protobuf in gRPC is more energy efficient that using standard HTTP.
      • It is usually far easier and more effective to dynamically scale (based on load) compute resources required for serialization/deserialization into binary payloads than it is to scale network bandwidth to support bulky character or XML payloads.
   4. Technique — Shorten the distance between senders and receivers: Use technology to shorten the distance between the source of most of the requests and the location of the compute that serves the requests.  All below from Ref 8.
      • Create compute machines and clusters near the source of most the of network traffic.
      • Use Azure Traffic Manager to route HTTP traffic to the closest compute.
      • Use “proximity placement groups” to reduce the distance between Azure resources.
   5. Technique — Favor fire-and-forget messaging over RPC (remote procedure calls): Where practical, given the functional and performance requirements of a workload, use fire and forget messaging rather than RPC.  From my own experience, plus Vasters Ref 7.  Potential operations cost reduction.
      • With fire-and-forget messaging (aka queueing or topics) the sender does not have to do a number of send retries when the receiver is too busy or offline.  Thus, using messaging in significant load situations can greatly reduce the amount of network traffic by reducing retry traffic, thereby decreasing the carbon footprint.

Strategy — Increase resource utilization and decrease waste resulting in a lower carbon footprint regardless of where the workload runs. This may or may not require software or data changes.  This is done mainly by reducing idle time.

A key part of the rationale behind increasing resource utilization is that a running compute resource incurs a minimum “up-and-running overhead” carbon cost just due to the fact the resource is powered up and running.  Therefore, it is better to have such resources more highly utilized since that reduces the “up-and-running overhead” carbon cost per workload.  When one has numerous underutilized resources, each workload will have a higher “up-and-running overhead” and therefore a total higher carbon footprint.

Resource utilization can be increased and waste can be decreased by using the following Tactics and Techniques

1. Tactic — Design and implement Software Architectures that have a specific requirement of increasing resource utilization and decreasing waste.  Potential operations cost reduction.
   1. Technique — Favor fire-and-forget messaging over RPC (remote procedure calls): Where practical, given the functional and performance requirements of a workload, use fire and forget messaging rather than RPC.  From my own professional experience, plus Vasters Ref 7.
      • With fire-and-forget messaging (aka queueing or topics) the sender does not have wait for the receiver to respond, all the while occupying memory while doing nothing but waiting.  This gets even worse when the sender has to retry sending the request when the receiver is overloaded, slow, errored, or when networking glitches happen.  Thus, using fire-and-forget messaging in significant load situations greatly reduces the amount memory consumed by code that is doing nothing but waiting for a response.
      • The following quotes from Clemens Vasters in https://vasters.com/blog/use-queues/ make the point:
        • “CPU cycles are short. Computers get a lot work done in little time. Compared, network transfers take forever. Having a program sit around, hogging memory, while it waits milliseconds for a computation “over there” that only takes microseconds to be performed is a huge waste.” Ref 7.
          1. While Vasters does not directly mention this, the waste he identifies consists of wasted energy which directly increases the workload’s carbon footprint over what it could be when using queues (fire-and-forget messaging).
        • “Business processes are long. From placing a purchase order to delivery, days may pass because physical goods must be moved. Having hundreds of program instances compete to rush through processing the accompanying digital steps in microseconds is a waste.” Ref 7.
          • Again, the waste is wasted energy. Why have very fast processing burning up electricity when it is not a business requirement?
   2. Technique — Use asynchronous operations for the backend worker processes to run longer running jobs. Ref 4.
      • This way a web app or WebAPI does not have to wait for the backend worker process to finish processing.  Rather when the processing is done the backend can send an asynchronous notification to the end user via email, text messaging, SignalR, etc.  Memory and CPU is freed up by the front end processes not having to wait in memory for the backend to complete its work.
        • Note that this fits in with the above technique, as well as with many web apps.
   3. Technique — Run backend worker processes at a lower priority than the front end processes. Ref 4.
      • This keeps resource utilization high by running worker processes that are not in high demand by front end processes at a lower priority, rather than having to scale out when both are running at the same priority.
        • Note that this fits in with the above techniques, as well as with many web apps.
   4. Technique — Reduce the number of microservices used by using a level of conceptual abstraction in the high level design that limits overall complexity plus makes it easier to increase resource utilization. Ref 4.
      • “Consider combining services, logically or physically, where similar scale points exist to reduce the footprint of the overall architecture”. Ref 4.
      • “If two or more microservices are highly coupled, consider co-locating to reduce network congestion and latency”.  Ref 4.
      • “Use languages and technology stacks that optimize the efficiency of a specific microservice function.  The independence and abstraction of functionality to an API layer means you are free to make the technical decisions that maximize utilization in your technical stack for each microservice.” Ref 4.
      • Use high level software architecture design techniques like subsystems composed of multiple individual services, systems composed of multiple individual subsystems, and systems-of-systems composed of multiple individual systems to implement conceptual abstractions that greatly reduce complexity plus the work required to implement the above techniques.  From my own professional experience, plus the IDesign Method, Ref 13.
2. Tactic — Use fewer compute and memory resources at a higher rate of resource utilization.  Note that increased utilization of these resources means decreasing the amount of idle time or unused capacity, Refs 4, 8.  Potential operations cost reduction.
   1. Technique — Use hosts that provide the ability to easily fine tune resource utilization by workloads so as to be able to maximize utilization while having the required performance.   This will provide the highest capability to reduce the carbon footprint by increasing utilization. All below from Ref 8.
      • Use cluster computing hosts like Kubernetes and Service Fabric that excel at providing very high resource utilization, coupled with the ability to automatically scale in and out to meet shifting demand.
        • This involves:
          • Node sizing.
          • Automated cluster scaling.
          • The use of “spot pools”.
          • Setting effective CPU and memory resource requests and limits per workload.
        • Example — Assume you have a cluster with 4 nodes, each of which is runs a given workload at 50% unused capacity.    By increasing the density of the workloads on the cluster you can reduce the node count to 3 nodes which decreases the unused capacity to 33%.  This increased resource utilization reduces the carbon footprint of the workloads. Ref 8.
      • Use PaaS to host your workloads.  PaaS typically has higher resource utilization rates than bare VMs.
      • If you are using VMs, use smaller VMs to increase your rate of resource utilization.
      • In all of the above, use auto-scaling and/or burst mode to keep the rate of resource utilization high rather than relying upon statically provisioned capacity.
3. Tactic — Increase utilization and decrease waste of Data Storage and Databases.  Potential operations cost reduction.
   1. Technique — Optimizing which database you use as well as how the data is stored can reduce the energy used to run the database as well as decrease idle time waiting for queries to complete. Ref 4.
      • “Ensure you are using the best database for interacting with your data set.  For example, if you are running many relational queries on your data set, a relational database is better suited and likely more efficient to use than NoSQL database”. Ref 4.
      • “If no single database is designed to handle all the ways you interact with your data set, consider keeping redundant copies of your data in different databases and using each database for the subset of interactions best suited for that database”. Ref 4.
      • “Consider using an index if your database offers it”. Ref 4.
      • “Consider evaluating and optimizing your queries”. Ref 4.
      • “Consider using a database cache.  In some cases, caching can reduce redundant queries to the database and decrease energy usage by the database, especially for complex or compute-intensive queries”. Ref 4.
      • “Consider running any resource-intensive microservices in a region with a lower carbon intensity” or utilizing more renewable energy. Ref 4.
4. Tactic — Make adjustments to Workload Requirements, if practical, to promote higher resource utilization and decrease waste.  Potential operations cost reduction.
   1. Making adjustments to a workload’s requirements involves 2 areas:
      • Functional Requirements — The functionality provided by a workload.
      • Performance Requirements — Latency, Availability, etc.
   2. A number of the previously covered Tactics and Techniques can be used when adjusting a workload’s requirements.  But here the approach is different, and involves looking closely at the Functional and Performance requirements and asking if there are any that can be relaxed in such a way to still satisfy users, but also significantly decreasing the carbon foot print.  For example:
      • Do all the user/UI/Server interactions really need to have the lowest possible latency?  Perhaps some interactions can still satisfy user needs but be slower or take the form of asynchronous notifications, including push technologies like SignalR, text messaging, or even email.
      • Can some processing that is asynchronous in nature be run at different times or in different regions which have lower carbon intensity processing power available.
   3. It basically comes down to scrubbing the Functional and Performance requirements to find high return ways to decrease the carbon footprint while still creating satisfied users of an app.

I hope this document aids you in reducing the carbon footprint of your workloads, thus moving the world a little farther away from the consequences of climate change.

References

1. “A new standard for Scope 3 emissions transparency” by Copyright © 2021 Microsoft. https://go.microsoft.com/fwlink/p/?linkid=2161861
2. https://www.bbc.com/future/article/20200305-why-your-internet-habits-are-not-as-clean-as-you-think and for confirmation see https://www.sciencedirect.com/science/article/pii/S2666389921001884 and https://www.upi.com/Science_News/2021/09/10/communications-tech-carbon-emissions/8771631295350/
3. “The carbon benefits of cloud computing” a 2020 Microsoft white paper based on a 2018 study https://download.microsoft.com/download/7/3/9/739BC4AD-A855-436E-961D-9C95EB51DAF9/Microsoft_Cloud_Carbon_Study_2018.pdf“
4. Principles of Green Software Engineering, https://principles.green/ “A personal project by Asim Hussain, Green Cloud Advocacy Lead at Microsoft. Further training based on the Principles of Green Software Engineering is available on the Microsoft Learn platform.”  principles.green material is copyrighted under the MIT License in a GitHub repo that contains the code for the principles.green website, https://github.com/jawache/principles-green.
5. Microsoft Learn’s “Principles of Sustainable Software Engineering” course authored by Asim Hussain.  https://docs.microsoft.com/en-us/learn/modules/sustainable-software-engineering-overview/
6. Microsoft Emissions Impact Dashboard — https://www.microsoft.com/en-us/sustainability/emissions-impact-dashboard
   • Here is an informative blog about this dashboard https://azure.microsoft.com/en-us/blog/empowering-cloud-sustainability-with-the-microsoft-emissions-impact-dashboard/
7. “Queues” by Clemens Vasters, May 15, 2020.  https://vasters.com/blog/use-queues/
8. Sustainable Software Engineering Principles in Azure Kubernetes Service (AKS). https://docs.microsoft.com/en-us/azure/aks/concepts-sustainable-software-engineering  and https://docs.microsoft.com/en-us/azure/aks/concepts-sustainable-software-engineering#reduce-network-travel
9. Advancing reliability through a resilient cloud supply chain.  This blog mentions Microsoft’s sustainability commitments. 
10. The Green Software Foundation — https://greensoftware.foundation/  “The Green Software Foundation is a non-profit with the mission to create a trusted ecosystem of people, standards, tooling and best practices for building green software.”
    • “The Green Software Foundation was born out of a mutual desire and need to collaborate across the software industry. Organizations with a shared commitment to sustainability and an interest in green software development principles are encouraged to join the Foundation to help grow the field of green software engineering, contribute to standards for the industry, and work together to reduce the carbon emissions of software.”
    • “OUR FOCUS AREAS
      • Standards: Agreeing on standards, best practices and patterns for building green software.
      • Innovation: Nurture the creation of trusted open-source and open-data projects and supporting academic research.
      • Community: Facilitate the growth of a diverse and international community of green software ambassadors.”
11. From “Fallacy #7: Transport cost is zero” by David Boike, 3/2/21, in his blog https://particular.net/blog/transport-cost-is-zero.  This article is part of the series “Fallacies of Distributed Computing”, consisting of 8 articles.
12. Microsoft Green Design Principles, https://wxcteam.microsoft.com/download/Microsoft-Green-Design-Principles.pdf .  This reference is not quoted from in this paper, but it is quite useful as a guild of things to consider when starting a software project.  Of great importance it presents some highly useful UX principles that and reduce the carbon footprint of an app, especially when used with the service oriented techniques focused on in this paper.
13. Righting Software: A Method for System and Project Design by Juval Lowy, Copyright © 2020 Pearson Education, Inc.
14. Saving Us:  A Climate Scientist’s Case for Hope and Healing in a Divided World by Katharine Hayhoe. Copyright © 2021 by Kathrine Hayhoe.  Published by Atria Books, New York, NY.

Sustainable Software Engineering’s Technical Strategies, Tactics, and Techniques © 2022 by George Stevens is licensed under CC BY 4.0. You have permission to copy this blog so long as you copy the previous sentence into your copy of it, under the Creative Commons attribution license in the preceeding link.