Is it possible to create a strategy that can be applied to any software infrastructure to enforce that the configuration of that infrastructure is environmentally friendly? This would be really great to have because it would allow for consistent compliance checks to be built that could be applied to any software infrastructure. Any company could apply these checks to benchmark the sustainability of its software infrastructure. Let’s focus on regional sustainability and see if we can come up with such a strategy.
What makes electricity more or less sustainable
When you plug something into an outlet, you are getting a mix of electricity. Some electricity is generated nearby and some is imported from elsewhere. There is no way to decide what electricity comes out of the outlet. In this way, electricity is like water. There are reservoirs nearby, but you don’t get any say in which contributes to the water coming out of your tap.
Also like water, electricity is distributed regionally. Where you consume electricity determines where your electricity comes from. If there is a coal plant and a solar park near you, sometimes you will get mostly coal-generated electricity, sometimes you will get mostly solar-generated electricity and sometimes you will get a mix. Where you consume electricity greatly impacts how much carbon is emitted to generate that electricity and how much carbon emissions you are responsible for.
Sustainability in cloud regions
One big benefit of using a cloud provider like Google Cloud Platform (GCP), Amazon Web Services (AWS), or Microsoft Azure is that you can provision a server anywhere in the world. But where should you provision your servers to minimize environmental impact?
If we are using GCP and need a server on the west coast of the US we have four regional options: us-west1, us-west2, us-west3, and us-west4. According to Google (https://cloud.google.com/sustainability/region-carbon), we can see that the us-west1 GCP region emits the least carbon. This is because that region is supplied by hydroelectric dams in Oregon state.
A potential strategy for sustainable software infrastructure could be “All new software infrastructure must be provisioned in the least carbon-intensive cloud region.” This strategy is not very realistic because carbon intensity is not the only consideration when placing cloud resources.
Latency, compliance, and redundancy
If most of your software’s users are located in Denmark and your software is hosted on the west coast of the USA your users will need to wait for every request to cross the Atlantic ocean. This is not desirable for most software applications, so we need to allow for different geographic regions to be specified based on knowledge about our users’ locations and latency needs.
There can be compliance issues related to the placement of software infrastructure. GDPR is notable in requiring data to be placed near users.
If a meteor strikes your data center, does your application still need to work? If so you probably need to provision infrastructure in multiple regions.
Our strategy becomes “All new software infrastructure must be provisioned in the least carbon-intensive cloud regions that are also in the same geographic areas of the users.” I feel pretty good about this strategy and I think it could be applied to most new software infrastructure. Unfortunately, we also need to consider sustainability for existing software infrastructure.
Sustainable cloud regions are not static
If a new solar plant is built in GCP region us-west2, that could make the average grid carbon intensity in that region lower than us-west1. Or if a coal plant is turned on in us-west1 that could also change which region is best from a carbon emissions standpoint. Just because we place a server in the most sustainable location does not mean that location will maintain that status indefinitely.
A strategy for existing software infrastructure could be “Every time software infrastructure is updated, check if the existing infrastructure meets the same standards as new infrastructure (described above). If the existing infrastructure does not meet the standards, cancel the infrastructure update until the existing infrastructure is migrated to the proper cloud region.” This strategy is a start, but it ignores certain practical considerations.
Migrating software infrastructure over time
Some software infrastructure can be easily relocated to a different region. A server that does not store data can be turned off and a new server turned on in a more sustainable cloud region. But when data is stored in a region, it can be much trickier to move. Regional data migrations often require all data from one region to be copied to the other before deleting the data in the original region. The cost to transfer the data could outweigh the benefit of the migration. And things get tricky if people want to access or update the data while the transfer is happening. Different kinds of software infrastructure require different regional sustainability considerations.
Some software infrastructure is easy to move regionally and some is difficult. We have reached a point where our strategy needs to handle the issue of effort. How much effort is it reasonable to expect? This situation reminds me of those food safety grades you see on restaurant windows.
The more effort a restaurant puts in, the higher grade they can post. Consumers can decide if they think a restaurant with a “B” grade puts in enough effort. And they can make that decision without needing to understand how the grade is given out.
Perhaps a “C” grade means the software infrastructure does not align with environmental best practices. A “B” grade means easy to implement best practices are followed, but difficult to implement best practices are not. And an “A” grade means all best practices are followed.
The final strategy
“All new software infrastructure must be provisioned in the least carbon-intensive cloud regions that are also in the same geographic areas of the users.”
“Every time infrastructure is updated, check if the existing infrastructure meets the same standards as new infrastructure (defined above). If existing infrastructure does not meet the standards, give a rating based on the degree of drift from the desired state and the difficulty in realignment. The rating must be displayed to consumers.”
What do you think? Can this strategy be applied to any software infrastructure? Would it lead to good environmental outcomes for software infrastructure?
Leave a Reply