BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Holly Cummins at Devoxx UK: How Would the Business Benefit from Your Greener Java Application?

Holly Cummins at Devoxx UK: How Would the Business Benefit from Your Greener Java Application?

Bookmarks

At her Devoxx UK presentation, Holly Cummins - senior software principal engineer at Redhat - presented approaches that could make Java applications more cost and energy efficient. Showcasing the work done by her team with quarkus she states that choosing wisely between the JVM or native options in your application can save up to two-times costs and carbon.

Her presentation started by sharing statistics that point out that the IT industry is creating more carbon emissions than aviation. The consumption needed only for running the data centres is similar to the energy required by South Korea. By adding network traffic to the equation, the consumption tops that of the UK or Brazil. 

 

 

 

 

 

 

 

She suggests that instead of taking the "desperation path" and renouncing taking action, we can all be "solutionists" and act in order to decrease the emissions. More than being "the right thing to do" the business will benefit from cost reductions and even improved Environmental, Social and Governance scores.

She further points as a proper place to start the green software foundation’s principles that build on three pillars: carbon awareness, hardware and electricity efficiency.

Carbon awareness: where and when you consume electricity

It all boils down to the source of the electricity; currently, the dirties energy source is coal. Burning it resulting in big quantities of CO2 emissions. Different parts of the world use different means to generate their electricity, depending on the specific area. Choosing a cloud provider that is transparent about where the data centres are making it easier to decide.

Also the time of the day matters, as renewable energy sources are intermittent. She points out that we can schedule heavy batch jobs at appropriate times when the energy is green. More often than not, she points out that it is also cheaper. 

She gives an example Virginia, US: on one side it is close to the place the Atlantic internet cable comes out, meaning that multiple data centres are stacked close by; and on the other hand, the abundance of coal in the area, making it the obvious choice as electricity generation means.

Hardware efficiency: elasticity of the infrastructure proportional to the utilisation

A survey from 2017 states that 16000 servers do no useful work and one from 2014 states that 29% per cent of the servers are not active 5% of the time. She introduces the concept of LightSwitchOps - turning off your infrastructure when the applications are not running. 

Yes, turning applications off is scary

In order to be able to do this, they require fast startup times, resiliency and idempotency. 

Electricity efficiency: the stack that we use and how efficient the algorithms are

Starting from an academic paper that measured various programming languages measuring energy consumption in comparison with time, energy and memory, she states that Java is not that bad, being in the fifth position after C, Rust, C++ and Ada, but overtaking Go which led to the statement that "compiled is not necessarily better".

Further zooming in on Java, she quoted another academic paper focused on running the JVM:

Our results show that some JVM platforms can exhibit up to 100% more energy consumption

Using the popular software development adage "measure, don’t guess" she presents the work done by the team from Red Hat working on Quarkus in order to be more aware of the consumption the framework has. 

Digression: measuring carbon is hard

After listing the options taken into consideration like wall power measurement or RAPLs, she refers back to the paper referred to earlier making the observation that:

Energy consumption (sort of, mostly) is proportional to execution time

and stating further that reducing your infrastructure spend will "(probably) reduce your carbon footprint". Given the presumably smaller computational requirements of quarkus, she points to their tests conclusions:

  • From a density perspective: Compared to classic JVM, Quarkus cuts carbon by approximately 2x, the native version having even a smaller carbon footprint. 
  • From a capacity perspective: Compared to classic JVM, Quarkus cuts carbon by approximately 2x to 3x, the native version consuming more carbon than even the JVM 

In the last part of her presentation, she provides a refresher regarding the use cases for when to use JVM or native Java for your application. If your application is considered for the high workload (lots of throughput), long-lived processes (that can be warmed up), stable workload or very little elasticity in underlying orchestration then it is better suited for JVM. On the other side, the native option is suitable for low workload, resource-constrained/ old hardware, and high re-deploy (applications never get warmed up before being spun down) or serverless. 

She concludes with concrete actions that can be taken to contribute to decreasing the carbon footprint. She encourages you to use your buying power to encourage businesses to make greener choices both for hosting solutions but also for consumer software. Ensure that you "switch off" infrastructure that you are not using. Pick energy-efficient languages and frameworks. She states that besides having a smaller impact on the planet, these actions will ensure also efficient spending: according to her, just in 2021 "zombie servers" wasted $ 26.6 B.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT