Working with software engineering teams at Microsoft, and being involved with the Green Software Foundation, I spend a considerable amount of time thinking about the concept of how we operationalise our teams to be greener. This isn’t just a tool, or a process, or a checklist, but a culture shift in the way that developers think about the decisions they make when building software and it’s impact as it relates to sustainability, and this in turn creates the team environment where green software is developed.

The term GreenOps isn’t just a greener CI/CD pipeline. Just how DevOps relates broadly to the implementation of culture change, practices, and tools, GreenOps can be a label applied to these aspects and how they relate to green software engineering.

In this post I’m going to talk briefly on exactly that, the culture change, practices, and tools that I have seen to date, and are yet to come that will help create what form GreenOps.

And a big disclaimer – this is not intended to be comprehensive or final. In 12 months times I’ll look back at this and see gaps, just as I will the moment I post it. Such is the nature of a rapidly evolving domain.

Culture Change

Culture change is the most critical and complex piece of having sustainability conversations and how they relate to software development. If someone does not care about sustainability, or understand how they can have a role in sustainability, nothing will change.

This isn’t as straight forward as running a 1 hour presentation, it takes time. With some teams I have seen it take weeks, with others I have seen it take months.

The key here is to be persistent. A team would do a quick assessment of sustainability on engagements with a quick survey during retro’s at the end of every sprint. Then over time, the conversation continues and starts to shift perspectives and discussion. With a greater understanding teams can come to working agreements where measurement is more formal, and then from that measurement processes and practices can evolve, and eventually tools can evolve to assist facilitate the desired outcomes.

A great place to start is with a team discussion, walking through the principles of green software and openly discussing what might be some steps the team can take. A broader discussion of sustainability often helps too, with people making efforts to use keep cups, or walk into work on certain days if possible, and measuring these to create a culture of sustainability, not just targeting software development. And most importantly is our teams are diverse, and as such we need to acknowledge that different people will be invested at different levels, and that everyone needs to be brought along, not only those that are passionate.

Practices

There are a large number of practices that relate to software engineering and sustainability. Here I’ll go through just a few of what is and will be a growing list. The practicse I will cover in this post are Design, Architecture Decisions, and Measurement.

Design

What design principles help drive sustainability from the inception of a software system?

There are some basic principles with some relating directly to design. The high level princiles of green software engineering are…

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.

I won’t go into detail here as this is all covered off at Principles of Green Software Engineering in detail and forever evolving and maintained.

From the core Principles of Green Software Engineering teams need to form their own principles. These team adopted principles relate more to how a team agrees to deliver against the 8 core princples.

An example principle might be to always use elastic scaling cloud infrastructure to reduce excess compute, in turn reducing carbon emissions (principle 1, 2, and 5). Similarly, there may be visual design principles such as all images below X kb and usage of css image sprites to reduce page weight (1, 6), in turn reducing carbon emissions per page request.

This style of principle adopted by the team helps to bridge the gap between the 8 core principles and the engineering and architectural decisions required when building software. A designer may not understand how file size relates to the 8 core principles, but a team/project’s own principles help create focus and impact without having to review the 8 core principles each time. These agreed principles can also have automated tests to ensure adherence without manual overhead.

Architecture Decisions

While the design principles help us think about an ideal system, architectural decisions lay the path to deliver against the princples. Ensuring sustainability is considered in these decicions throughout a project is critical.

At times however architectural decisions will be made with trade-offs, and similar to flexibility, performance, or scalability, sustainability may be prioritised or deprioritised to deliver certain functionality. Regardless of this decision, it’s critical to capture the rationale.

A common way to capture architectural decisions is with Architecture Decision Records (or ADRs). These are a basic template that captures the rationale of a key architectural decision on a project, such that it can be reviewed, and in many cases to revisit the decision in the future. The ADR’s are checked into source control and over time can be revised.

By adding the sustainable aspects to all architecture decisions, it not only helps influence decisions to be greener – where at times there may be no other downside – but it also helps create awareness and a culture of sustainability. It may be there are no sustainability aspects to an architectural decision, but recording that understanding helps be intentional about sustainability. With new knowledge over time these can be reviewed that contradict the original understanding, and as such changes can be recommended to enhance the sustainability of the system, knowing that at the original point in time the best decision was made with the information at hand.

Measurement

Measurement relates primarily to the ability to measure or observe the sustainability actions you have taken. It does not only relate to the measurement of C02 emissions.

Observability of a systems CO2 emissions is an important place to start, but it is the result of the sustainability actions to reduce the CO2 emissions over time that is critical. Understanding the action that relates to the emissions reduction is critical so there is recorded causation between the action the reduction. It may be that the assumed benefits result in an increase of emissions, and the changes can be reverted. And if the emissions are reduced, the change can be identified as practice to be reused across other software, both legacy and in the future.

Tools

Tooling is the area that in Green Software Engineering is sitll lacking. The Green Software Foundation has many initiatives looking for contributors and there are others across the industry, with the tooling itself still fragmented. Until there are standardized tools for analysis, profiling, and simply guidance.

A place I would definitely recommend for starting is over at awesome green software. It is a collated list by the Green Software Foundation, including early stage tools and articles on measuring carbon across cloud, data science, programming languages and more.

If you are looking at what tools you can build yourself, I suggest starting simple. Calculating total emissions is very complex, and multidimensional. An application running in a cluster, on a VM, on bare metal replaced every 4 years, in a datacentre, using redundant storage replaced every 2 years, and lighting, and air-conditioning, and water… these are complex calculations that eventually will be possible with industry tooling.

BUT! – there are some quick wins. Reducing file sizes, such as images on a web page and redundant JavaScript libraries can dramatically reduce CO2 overheads of a website dramatically. Stopping running nightly builds on CICD pipelines that run on commit already. Shutting down or scaling down development servers out of hours and on the weekends to reduce wasted resources.

And if you want to start tracking emissions in the energy you are using for audit, and for understanding when to run workloads to reduce emissions I can happily recommend the Carbon Aware SDK. I’m currently the lead for the project as part of the Green Software Foundation and there is plenty of industry support from Fortune 500 companies and more leveraging it, and it will only continue to grow.

And for reference, at the time of writing this page is greener than 97% of web pages on the internet.