Engineers are realising that they have the power to make their cloud architectures more sustainable. This trend is supported by cloud providers AWS, GCP and Azure who are offering tools and guidance on the technical choices we can make to reduce the carbon impact of our technical estates.
We believe that as well as techniques, we also need models to incorporate carbon responsibility into the decision-making of our organisations. It’s not enough to implement one-off optimisations – we have to put them into practice over and over again.
Our experience tells us that lessons learned from Team Topologies and FinOps can be applied to create carbon responsible technology organisations that make sustainability part of their day-to-day.
Stream-aligned teams
In a technology organisation optimising for fast flow of feature development, design decisions are delegated to teams as close to the customer as possible. Team Topologies refers to these teams as “stream-aligned”. If we want to develop and sustain carbon-responsible architectures, then these stream-aligned teams are crucial because they make many significant architectural decisions. Only they have the context to understand which trade-offs are acceptable and which optimisations are possible.
In stream-aligned teams, carbon responsibility takes the form of architecting systems that address customers’ specific needs in a carbon-efficient way and also looking for opportunities to empower customers to make carbon-efficient choices.
Stream-aligned teams should treat carbon-efficiency as a key cross-functional requirement. Teams are used to considering maintainability, scalability and financial cost – energy usage is just one more thing to take into account. The authors of Building Evolutionary Architectures suggest that architectural fitness functions are a good way to manage the trade-offs between these kinds of concerns.
How you go about doing this depends on each team’s context, but you can refer to guidance like this whitepaper from Anne Currie or this checklist from Thoughtworks to find candidate optimisations. Big wins are often found in consolidating hardware in data centres and migrating away from private data centres to a public cloud. However, cloud lift and shift misses much of the cost and carbon saving opportunity. For organisations on the cloud, analysing traffic patterns and Service Level Objectives (SLOs) often yields opportunities to rightsize resources or use serverless solutions. You might even find services or workloads that you can decommission entirely. Your user interface design also matters because heavier pages incur more carbon emissions through energy consumed in data transfer and client side computation.
Stream-aligned teams indirectly influence carbon emissions outside systems they build through their product design choices. They can often help their customers reduce their own emissions. For example, Ecosia is a socially responsible search engine that uses advertising revenue to plant trees and offset carbon. They also enhance the user experience of their product by educating users on sustainable shopping choices.
Ecosia Search Engine
Carbon emission metrics should be visible to engineers and also to other internal stakeholders e.g. product people, engineering managers, and even other Stream-aligned teams. Just as teams keep track of their spending on the cloud, they should analyse trends in their carbon emissions using tools like the cloud providers’ carbon dashboards and the Cloud Carbon Footprint, which also provides recommendations for specific improvement actions.
In mature carbon responsible organisations, teams could go one step further and define SLOs on green indicators such as carbon efficiency. According to a 2019 study by The Shift Project, we could use their 1-byte model to approximate the carbon footprint of transferring 1Gb over a network to 1.22 kg of CO2 being emitted. By making sure a service response uses some compression algorithm to minimise the payload and showing that evolution in real time on a dashboard, teams align and subscribe their products and services towards organisational sustainability goals. Existing mechanisms to alert on SLA breaches can keep carbon awareness top of mind for a team and provide early warning of anomalies or overprovisioning.
Platform teams
Most organisations also have platform teams that provide tools and services to the stream-aligned teams. Platform teams don’t have close customer context, so they cannot implement carbon optimisations that depend on specific features or workloads, but they do have visibility and understanding of cross-cutting infrastructural concerns.
In platform teams, carbon responsibility takes the form of implementing technical optimisations in platform services and also providing visibility and tooling that enable stream-aligned teams to build carbon-efficient systems.
Since platform teams produce services that are used by many teams, they have high-leverage opportunities for carbon optimisation. For example, if a platform team upgrades a compute platform to use a more energy-efficient processor then there is a positive impact on the energy usage of every system built on that platform. If the template used to create new microservices comes with better default settings that embed the principles of Green Software Engineering, then that too will offer a return over and over again.
Platform teams often offer observability capabilities to other teams. That’s great for maintaining high uptimes and it’s also effective for helping teams to understand if they’re using resources efficiently. If a platform team can help stream-aligned teams be aware of when they are overprovisioned, then they enable that stream-aligned team to make optimisations (both financial and carbon).
We can usually think of cost as a proxy metric for carbon efficiency i.e. when you optimise for dollars, you will likely optimise for carbon. This is why platform teams should also detect patterns, and propose improvements in the cloud architecture as a whole. They should be proactive in monitoring recommendations from the cloud provider and keeping a close feedback loop with support engineers to work on those possible optimisation opportunities. Some of these might include:
Making sure that the right type of instance/family is being used
Defining a balanced mix of committed usage, spare capacity, and on-demand capacity, for computing resources
Implementing good storage lifecycle policies
Designing resilient and efficient networks, minimising hops and avoiding unnecessary traffic going out to the Internet
As this type of team provides a service to stream-aligned teams, we also see value in pairing between platform and stream-aligned teams to experiment, prototype, and implement some of these strategies in an agile way.
Enabling teams
These teams are responsible for closing knowledge gaps in stream-aligned teams. Following the example of expert FinOps teams that help engineers to understand complex financial trade-offs, we see value in having GreenOps teams that do the same for cloud sustainability.
In enabling teams, carbon responsibility takes the form of evangelising carbon efficient practices throughout the organisation and also helping colleagues grow the skills to build carbon-efficient systems.
A GreenOps team has accountability not for specific optimisations but for defining a strategy for the organisation and for ensuring that stream-aligned and platform teams have the skills they need to act on it. As reducing cost is usually a good heuristic for reducing the carbon footprint, stream aligned teams should collaborate with FinOps teams to work on best practices about cost visibility and attribution e.g. resource tagging and labelling, shared costs allocation etc.
Both FinOps and GreenOps teams should aim, as their organisation matures, to define a golden metric of unit economics that can be rolled up across the organisation. This could be measured per customer, per transaction or relative to some other fundamental business metric. This means the organisation has clear visibility on how much it costs financially (e.g. $/customer) as well as environmentally (e.g. kgCO2/customer) it takes to operate.
Conclusion
FinOps has given us a model for financial cloud optimisation. Team Topologies has given us a model for team interactions and autonomy. When we combine the two we arrive at a clear division of responsibilities: stream-aligned teams make context-sensitive trade-offs, platform teams make cross-cutting optimisations and enabling teams raise awareness and technical understanding. This is an ideal blueprint to apply to carbon responsibility. Just count carbon rather than dollars. In many cases, even the same optimisations reduce both cost and energy usage.
In our experience, many software engineers are deeply concerned about the climate crisis and how their work impacts it. They don’t need to be told that there is a problem, but they do need to be given clarity as to how they can exercise their professional judgement to make a positive difference. We believe that the model we describe in this article offers a practical approach that organisations can implement to empower their teams to make carbon responsible choices.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
