Reduced Infrastructure Requirements

Reduced infrastructure requirements: poster for the GreenCode film
Video created by explainapaper.com

Most servers spend most of their time idle, and inefficient software is why more of them get bought. GreenCode maps a running estate, finds where the energy goes, and rebuilds it smaller.

Why this matters

A rack of servers mostly idle, with the surplus crossed out after optimisationView full size
Bought for the worst moment, mostly idle, and still growing.

Infrastructure is bought to run software, and the amount bought is set by what the software demands at its worst moment. When code is inefficient, the response is rarely to fix the code. It is to add nodes or raise the instance size, and the cost lands on the cloud bill every month after.

GreenCode's state of the art review cites studies showing that cloud servers in data centres are active only 10 to 30 per cent of the time and idle for around 70 per cent of it. Citing International Energy Agency figures, it puts data-centre electricity use at 240 to 340 TWh in 2022, around 1 to 1.3 per cent of global electricity, and notes that as hardware efficiency gains plateau, growing software complexity cancels them out.

For a CTO the case is financial before it is environmental. GreenCode puts it plainly: the total cost of ownership of a software system tracks with its quality, and both track with its operational efficiency and carbon footprint. Reduce the demand and the infrastructure, its cost and its emissions shrink together.

How GreenCode produces this benefit

GreenCode approaches infrastructure from the software side. Rather than tuning a data centre around a fixed workload, it reduces the workload and then right-sizes what runs it, in a loop: measure under load, attribute energy to specific code and components, optimise, and measure again until the improvement stops or a target is met.

The infrastructure part starts with discovery. Building on earlier infrastructure-mining research, GreenCode reconstructs a running estate and its dependencies, at a scale of tens of thousands of services. That map is used to find three kinds of waste: energy hotspots, services that are partly or wholly unused and could be shut down or moved to serverless functions, and unnecessary communication between components. The application is then deployed to a reconstructed, instrumented version of its environment and stress-tested, so that code and infrastructure changes are benchmarked in the same controlled setting.

What the project is building and measuring

The components, all in the green DevOps and infrastructure assessment work package, are:

  • Tools that mine a running deployment and reconstruct a representative environment through infrastructure-as-code.
  • A toolkit that monitors the energy use of IT infrastructure and identifies hotspots, with virtual-machine and process-level monitors that map consumption back to application metrics.
  • Energy-aware resource management that scales applications or microservices in line with demand and grid carbon intensity.
  • A recommender that proposes infrastructure changes to reduce energy without loss of performance.
  • Predictive models of resource use for database services, a significant hotspot in most estates.
  • Management of computing jobs across idle or redundant devices so existing hardware is used before new hardware is bought.

The target, set in the project vision statement, is a net energy reduction of at least 15 per cent from start to end of the process, the threshold beyond which the consortium expects users to see significant commercial value.

What it means in practice

Two partner use cases illustrate this. In the cloud infrastructure use case, a research computing cluster running bare-metal servers, Kubernetes and virtual machines has resources that are often idle and no way to see where its energy goes. The goals set there are specific: real-time resource dashboards, reconstruction of part or all of the infrastructure through infrastructure-as-code within an hour, and optimisations that can be carried out within a working day. In an industrial use case, a .NET system in cloud virtual machines is moving to a cloud-native architecture, measured on the provider's bill per customer and the associated CO2e.

The outcome is an estate that is smaller, better understood and easier to rebuild. Capacity is bought against measured demand rather than a safety margin, unused services stop consuming power, and the infrastructure definition is reviewed and versioned like code. GreenCode runs to 2027 and these tools are being validated on partner systems now; the figures above are targets, not results from deployed products.

Where GreenCode is working on this

Infrastructure discovery, reconstruction and energy monitoring sit in the green DevOps and infrastructure assessment work package, which covers infrastructure mining, Green DevOps and the recommender, energy-aware resource management, monitoring and distributed computing across idle devices. Benchmarking, stress-test generation and the optimisation loop sit in the processing pipeline and benchmarking work package.

Organisations that want to take part or trial the infrastructure assessment tools on their own estate can reach the project through the contact page.

  • Benefit area Climate, Financial and Operational
  • Who it is for CTOs and infrastructure owners
  • Headline target At least 15% energy reduction
  • How it is proven Benchmarked on reconstructed infrastructure
  • Delivered through Infrastructure reconstruction toolkit
GreenCode

Want this benefit for your own systems? Talk to the GreenCode team about a trial.

Get in touch