As we discussed in the first part of this series, at the end of 2021, AWS added sustainability to the well-architected pillars that define their “key concepts, design principles, and architectural best practices for designing and running workloads in the cloud.” A year earlier, Azure had posted their sustainable architecture guide, written by our own GSF chair, Asim Hussain. Their cloud recommendations are covered in a new whitepaper on sustainable architecture for the cloud from the Coed:Ethics community in London, which the GSF is closely connected to.
What it Means for Us
In the first article, we outlined the four main approaches to tech sustainability:
Operational efficiency, that is, improving how software is run was covered in the last post.
Architecting for minimal carbon is about improving how software is designed.
Hardware efficiency, in particular, improving how end user devices are managed.
Energy efficiency, in terms of minimising CPU/GPU and network use.
In this post we will focus on the second, how to improve the way your software is designed.
What is Green Software?
Sustainable or green software is designed and coded to require less power and fewer machines to perform the same tasks. This is also known as carbon efficiency. It also aims to draw power at times and in places where the available electricity is from low carbon sources like wind, solar, geothermal, hydro, or nuclear. This is called carbon awareness and is a fundamental concept of sustainable computing.
Architecting for Minimum Carbon
Software applications can be designed in ways that are more carbon aware and energy efficient, and some architectures are easier to run at low or zero carbon than others.
Carbon Awareness
This is all about running on carbon free electricity (CFE), which unless you operate in France (nuclear) or Iceland (geothermal) is likely to be highly variable in its availability. The tech industry, therefore, needs to be flexible in its electricity demand.
Markers of sustainability
Markers of a good architecture from a sustainable perspective are:
Little or nothing is “always on”, because that means it will almost inevitably have to draw power when the only electricity available was generated using fossil fuels.
Jobs that are not time critical—for example, machine learning or batch jobs—are split out and computed asynchronously so they can run at times when there is low carbon electricity available. For example at times when the sun is shining and there isn’t a heavy demand on the grid.
The techniques involved are often referred to as demand shifting or demand shaping. Tools like Microsoft’s Azure Machine Learning resource metrics can help understand the energetic costs of AI workloads across their lifecycle or AWS’ CloudWatch provides similar data. Demand shaping can also mean changing the offering of a service based on the carbon intensity of the electricity currently available on the local grid. In times of 100% carbon-free electricity (CFE), full functionality can be offered. In times of CFE scarcity, service can be gracefully degraded.
Genuinely time critical, on demand, tasks that will draw on high carbon electricity are designed efficiently so as to use as little of it as possible.
Jobs are not run at higher urgency than they need, so that if they can wait for cleaner electricity they will.
Where possible, calculations are pushed to the client and the edge or data is cached in Content Delivery Networks (CDNs) to minimise network traffic, reduce the need to run on demand processes in data centres, and take full advantage of the energy stored in client batteries (which as time goes on is increasingly likely to be renewably sourced). Patrick Ferris of OCamlLabs says, “p2p, offline-first applications have a role to play in this space. Both aspects work together to remove the need for a centralised service with a high percentage uptime.”
Data storage policies are frugal. Databases are optimised; that is data stored is minimised and queries are tuned. Data is compressed before storage, especially when it is for long term storage, and data isn’t stored unless absolutely necessary.
The above often relies on a microservice or a distributed systems architecture.
Johnston states, “In many systems, the only thing that needs to be always on is the interface e.g. the API Gateway or the pub/sub system. Everything else could be rewritten as an event driven system.”
Use Managed Services
There is a real efficiency advantage in high compute density via managed cloud services. Such services, which can share resources between thousands or millions of users, achieve extremely high utilisation.
Serverless services like Lambda functions or Azure functions are particularly helpful in minimising the hardware footprint needed upfront and helping directly in capabilities like autoscaling, rightsizing, and pay as you go.
Enterprises may sometimes fear data security in these shared environments. However, since these are likely to play a major role in the future of sustainable software, cloud providers need to address these fears.
Doing Less
The most efficient code is no code at all, and the best time to spot unnecessary work is as early as possible in the design process.
According to Adrian Cockcroft, VP of Sustainable Architecture at AWS, “The biggest win is often changing requirements or SLAs. Reduce retention time for log files. Relax overspecified goals.”
Sometimes overspecified goals are unavoidable, out of date regulations for example. But, often they are internally driven, rather than in response to external pressures or genuine user needs. If that is the case, drop them until you know you require them.
Conclusion
When it comes to sustainability, architecture matters. An interesting thought experiment is: could you run 90% of your system’s CPU load on a spot instance? How about in a managed service?
What service brownout options are available to you to operate with a lower electricity draw? Could you reduce response time targets or encoding quality? What else? Google is working on how to run fewer machines at times of high carbon electricity. How could you do the same?
This article is licenced under Creative Commons (CC BY 4.0)
