Today, sustainability is an afterthought for most software applications.

Long after an application is deployed in production, a specialized team may be asked to measure the application’s carbon emissions and identify the actions to reduce them.

It reminds us of how security was handled some years ago when developers were not responsible for application security. It was the job of a security team to assess the application and report any security findings. The overall process typically resulted in delays until developers addressed the reported security issues; in the meantime, the application would be exposed to security threats.

To address security issues before deploying applications to production, our industry adopted security practices earlier in the software development lifecycle, checking the code for vulnerabilities during the build stage, a practice known as shifting security left or DevSecOps.

How could we embed sustainability practices early in software development rather than treating sustainability as an afterthought?

While this is an evolving space, developers can adopt the following practices to build greener software applications, shifting sustainability left in the Software Development Life Cycle (SDLC).

Run static code analysis to find energy-inefficient code

When a developer commits new source code, it is common for the Continuous Integration pipeline to automatically trigger a static code analysis of that code using a tool like SonarQube.

Static code analysis tools can identify opportunities to optimize source code to consume less power and emit less carbon.

These tools may recommend changing the code to complete the same computing task in fewer CPU cycles, hence consuming less energy.

For example, SQL queries like “SELECT * FROM dbTable” should be avoided because they unnecessarily read data from all the database columns, thus:

• Consuming more CPU cycles to process the SQL query,
• Allocating more memory while loading data, and
• Transferring higher data volumes over the network. The greener approach would be to select only the columns needed when executing SQL queries, such as: “SELECT columnA, columnB, columnC FROM dbTable.”

If you use a static code analysis tool like SonarQube, you are already building greener code because it recognizes several energy-inefficient coding patterns, like the SQL queries that retrieve unnecessary columns.

Nevertheless, you can take sustainable software development to the next level by using tools specialized in green static code analysis.

Creedengo is a free, open-source tool that identifies energy-inefficient coding patterns in various languages, like Java, JavaScript, C#, PHP, and Python. This tool consists of SonarQube plugins that augment SonarQube’s default coding rules with ones focused on green code.

Similarly, CAST Highlight is an enterprise tool that finds green software deficiencies in the source code based on a published set of coding rules that cover a broader range of programming languages, like COBOL, PL/1, and SAP ABAP.

These static code analysis tools enable developers to write greener code, reducing the software’s environmental impact early in the Software Development Life Cycle before deploying to production.

Quantify the impact of Infrastructure as Code (IaC) on carbon emissions

Nowadays, developers write code to automate the deployment of infrastructure, using tools such as Terraform, Ansible, and AWS CloudFormation, broadly known as “Infrastructure as Code (IaC).”

Thanks to the adoption of IaC, we can use static code analysis tools to assess the infrastructure and provide recommendations to make it greener, reducing its energy consumption.

For example, we can integrate Infracost with a CI/CD pipeline and get recommendations for improving Terraform templates. While Infracost focuses on reducing operating costs, many of its recommendations will also lessen energy consumption and carbon emissions.

When a Terraform template deploys AWS RDS (a managed database service supporting databases like PostgreSQL and MySQL), Infracost will automatically recommend using AWS Graviton-based computing instances because these consume up to 60% less energy and cost 20% less than x86-based instances with similar performance.

Similarly, when a Terraform template deploys observability and monitoring services like AWS CloudWatch and Azure Monitor, Infracost suggests setting data retention policies to automatically delete the logs saved by these services. The default setting in AWS CloudWatch is to keep logs indefinitely; if this setting were left unchanged, the logs would increasingly occupy more storage. Thus, this policy can reduce energy consumption and carbon emissions related to data storage.

Infracost allows setting custom policies to enforce the use of preferred cloud regions in Terraform templates. One could create policies to allow deploying cloud resources only in regions powered by the greenest electricity and with the lowest operating costs, thus combining GreenOps with FinOps.

AWS Sustainability Scanner is a similar tool that analyzes AWS CloudFormation templates and AWS CDK stacks, providing a sustainability score along with recommendations to improve it. These recommendations come from the AWS Well-Architected Pillar for Sustainability; hence, developers can use the AWS Sustainability Scanner to automatically check how their infrastructure complies with the AWS Well-Architected Pillar for Sustainability.

For instance, when deploying an Amazon API Gateway, that tool will check if payload compression is enabled for REST APIs, a practice that reduces the data sent over the network and thus lowers the energy consumption of data networks.

Quantifying savings before deploying to production

What savings should we expect if we apply one or more of the suggested practices to the IT infrastructure? Could we somehow quantify the reduction in carbon emissions before deploying any changes to production?

Carbonifer is a command-line tool that reads Terraform templates and estimates the carbon emissions of the infrastructure to be deployed by these templates. Although it’s not actively maintained (last commit was in 2023), it sets an excellent example of shifting sustainability left, calculating carbon emissions for compute instances in AWS and Google Cloud.

Infracost has taken this a step further. When a developer commits a change to a Terraform template, it adds a comment to the Pull Request, informing the developer about the decrease (or increase) in the carbon emissions caused by this change.

In the below Pull Request, Infracost provides the following hints to developers:

• Monthly operating costs will be reduced by $141,
• Monthly carbon emissions will decrease by 6.3kg CO₂e – that’s like driving a car 25.03 km.

These tools shift sustainability left by allowing developers to identify energy-efficient and cost-effective options for their IT infrastructure before it is deployed.

Building green software by design

Green Software isn’t theoretical – it’s actionable with the tools suggested. Instead of retrofitting software applications already deployed in production, you can provide feedback to developers while they can still act on it, directly in CI (Continuous Integration) and PRs (Pull Requests).

There is no need to introduce new processes that would burden developers with additional effort.

You can bring sustainability earlier in software development by introducing the following in your project:

• Code: Run static code analysis to discover and fix energy-inefficient code patterns.
• Infrastructure as Code: Scan IaC templates, such as Terraform, to estimate cost and carbon impacts.

Further reading

• Did you find this article helpful? If yes, you may like reading my book on Green Software.

Disclaimer: All opinions expressed in this blog are solely my own. References to specific products or tools are for informational purposes only, and I have no affiliation with the vendors mentioned.