Apps power up. It’s a term we use quite commonly to describe the moment when we open a software application and start to interact with its user interface in order to engage with the functionalities, connections and services that it offers. But apps also power up in the real sense i.e. the more software “instances” that an enterprise (or indeed an individual) runs, the more power everybody needs to run the devices that applications reside on… and, crucially, the more power we also need at the backend of the cloud computing backbone in the hyperscaler datacenter to serve the user (or smart machine) and make them happy.
As we now embrace our new environmental, social & governance-driven technology epiphany and start to stipulate and mandate for green computing to be a given, software engineering evangelists argue that we might need to move on from discussions around sustainability in technology that focus on simply datacentre power consumption.
Datacenters On The Moon
We know there are standardized measures for power usage effectiveness (or PUE as it is often called) and the industry groups discussing datacenter waste heat recapture have been active for years. We’re past talking about ideas to put heat-pumping datacenters at the North Pole, in deep cold water locations and on the moon. We should perhaps be a little more introspective and look at our software’s internal efficiency factor itself.
“Despite all the focus on efficiency in the industry today, sustainable software is simply not as great a priority as sustainable hardware – but it should be,” said Germain Masse, AI and data team engineer at OVHcloud, a company known for its virtual private server and related cloud computing technologies. “In an ideal world, we’d have nothing but high-performance code, which would run super fast and at the same level of resource consumption across all code bases. But when you start to look into the nuances, there’s a lot of considerations to take into account.”
Beware the Frankencode
One of the main issues is code complexity and it’s a reality that results in what Masse and others refer to as Frankencode. Because we live in an era of low-code compartmentalized automations, software application development professionals are now less likely to write a complete codebase from scratch. Today we accelerate coding development by using libraries and often bring in an amalgam of application programming interfaces to provide additional features.
“In some ways, this makes a lot of sense because it means developers can go fast, re-use existing building blocks and get code out into the wild quickly. In other ways, it’s not so great, because teams and individual engineers usually don’t know the efficiency or performance of the libraries that they are using, so any performance lags or glitches will propagate,” advised Masse.
In reality, software development teams will monitor and benchmark when and where they can and look at the performance of their code and also analyze the CPU and memory usage. However, although DevOps teams will usually monitor resources to get the scaling of the infrastructure right, it’s not at all common to use benchmarks to decide which framework or library to use in the first place, especially from a sustainability point of view.
But the rabbit hole goes deeper.
Down The Rabbit Hole
“It sounds basic, but application energy consumption depends on what’s being done. For example, running a CPU is more energy-intensive than work carried out by RAM or on solid state disks, so CPU- or GPU-intensive tasks should always be run in green energy zones if possible,” advised Masse. “However, you’ve got to look at the combination of factors. You might be tempted to use a facility which has a better PUE score than another, which is in a different country. But some regions have cleaner energy than others – our Canadian facility, for example, is run on green energy predominantly from the hydroelectric dam next door.”
Consequently, says Masse, if any given IT deployment has a less power-efficient facility, but it’s run on purely green energy, it’s better to use that, rather than one which is highly power-efficient, but running on energy from coal. Also he adds, no matter where in the world a computer server is assembled, the carbon footprint of its manufacturing will be approximately the same (computer chips are mostly manufactured in the same factories)… so manufacturing is an important factor in reporting carbon, but it’s generally not important to choosing where the workload runs.”
As a side note, Masse reminds us that the electricity consumption of an application as it runs is usually only thirty to fifty percent of its carbon footprint. The other part comes from the manufacturing of the actual infrastructure itself and in a reversal of the usage trend, manufacturing RAM and SSDs is a very carbon and power-intensive process, compared to making CPUs.
“Some programming languages are intrinsically more efficient and high-performance than others. Rust and C are high-performance, because they run at a more fundamental level than languages like Perl, PHP and Python. At a basic level, they have the power to do impactful things, without fuss. Some languages – looking at you, Java – are more memory intensive, and a lot of places tend to avoid them, even if they can be very good at what they do,” said Masse. “That’s not to say we should all stop using Python and switch back to C, because the lower down the stack you code, the higher the risk. As we all know, mistakes in code can lead to security flaws, and the more fundamental the code, the more fundamental the security risk.”
We Have Redundancy, And We Have Redundancy
Redundancy is also an issue. If we’ve got two sets of active infrastructure running at the same time to ensure good failover, we’ve got twice the carbon impact. We can reduce this by making sure that the backup infrastructure is running in a more passive mode, but that will reduce failover time in the event of a problem.
For critical applications like in the healthcare industry, it’s absolutely worth having systems running in tandem (or more) but for other less critical applications, it’s not. So again, it’s worth considering where your backup applications are, in terms of green power consumption – taking latency into account, obviously.
GreenOps Sprouts Everywhere
“More efficient software and software operations means lower power bills for the users, as well as a smaller carbon impact. Efficient applications benefit everyone – even for startups, who often receive cloud credits and free infrastructure: getting into lean operational habits is good practice, especially when credits run out,” concluded OVHCloud’s Masse.
Ultimately, thinking more sustainably is something we all need to do. The FinOps movement has started to penetrate every layer of corporate business. Now it’s time for GreenOps and sustainable software application development to do the same.
