Stop green washing: optimize your code, not your bios
Is sustainable IT important to you? Or do you simply want to save more money {???}. Let's agree on this: sustainability is not a BIOS checkbox. I explain it all in this blog.
Companies are busy with sustainability reports. CSRD, ESG, assurance. It has to be in order.
And so all attention goes to... BIOS settings. C-states on. Turbo off. Power profiles set to “balanced.” Done!
Sounds technical. Feels green. Fact: it yields almost nothing.
Why not? Because your biggest consumer is not the motherboard, but the software you run on it. Inefficient code drives CPU cycles, memory, and I/O through the roof. Chatting microservices. N+1 queries. Polling instead of events. Too much logging. Unnecessary serializations. Stop!
All those “small” losses add up to megawatts and euros. And your BIOS can't just “fix” that.
Real sustainability gains are found in the application layer in combination with your architecture. In short: doing less work for the same result. Who wouldn't want that? And that's what's really green. How?
It starts with measurement. Not “server idle,” but “euros per business transaction.” What does one order, ticket, or API call cost in terms of CPU time, network, and storage? Add a CO₂ factor and kWh price to that, and you'll see exactly where the leaks are. Sounds simple? It is. We perform these kinds of measurements weekly.
Then optimize. Remove chatty calls. Batch where possible. Cache smartly. Choose more efficient data structures. Use asynchronous where synchronous adds no value. Eliminate noise: redundant agents, verbose logs, zombie containers. Only then should you right-size your platform. In that order. Otherwise, you'll cut capacity while waste remains.
The result? Fewer resources, lower bills, and lower emissions. Plus, demonstrable figures for your auditor. That's “lean & mean” IT: not reporting greener, but running greener. BIOS settings are fine, of course, but as a finishing touch. Not as a strategy.
In short: if you take sustainability seriously, first optimize the software and then adjust the hardware. Anything else is window dressing with a green sticker.
Halve your CO₂ emissions in weeks: optimize before you rightsize
Halving is often not an ambition, but the minimum. In modern stacks, there is so much waste that halving CPU time, I/O, and memory is usually achievable within 1-2 weeks. And yes: a factor of 10–100 is common. Not through magic, but through technology that you can apply today. I'd be happy to explain it to you. And that starts with this question:
Where are the gains?
- Measurements that matter
Don't just measure consumption (CPU/RAM/I/O), but also where and why it happens. Link hotspots to specific user flows and transactions. - Reveal inefficiencies
Identify three types of waste: repeatedly calculating the same thing, retrieving data you don't use, and fetching data in too small portions (chattiness). - Apply the principle of locality
Process data where it already is; only send what is really necessary between systems. Fewer hops = less latency, less energy, lower costs. - Scalable algorithms
Choose and tune algorithms for your current scale—and let them grow as the load increases. Efficiency as a feature, not an afterthought. - Smart feedback to users
Show progress and status so people don't keep refreshing. This saves unnecessary calls, load spikes, and energy... and prevents frustration.
The approach:
-
Measure what matters: joules and euros per business transaction (order, invoice, API call). Not “CPU 70%,” but “€0.003 and 0.4 Wh per order.”
-
Profile in production conditions: Heavy queries, long URLs, intensive I/O. Find the three hot-spots that consume 80%.
-
Fix in the right order: first eliminate waste, then rightsize. Otherwise, you'll squeeze capacity while the leaks remain.
-
Prove it with numbers: before/after with identical workload, SLOs, kWh, and CO₂ factor. Auditors love graphs, finance loves declining OPEX.
-
Keep monitoring: sustainability is not a one-time exercise.
Why this is urgent now:
The 1990s traded efficient programming for fast shipping. Hardware became faster. And ‘thirstier’. The result: software that guzzles more cycles than ever, while you pay per vCPU hour and per I/O. ‘Faster servers’ don't solve anything if your code remains slow. Every unnecessary millisecond is energy loss, cost loss, and CO₂ that you don't need to emit.
Sustainable IT starts with doing less work for the same value. Optimize the software, measure per transaction, cut out noise, and only then look at BIOS and platform. Anything beyond that is green washing.
From window dressing to profit: sustainable IT that counts
Sustainable IT is not a PR project or a BIOS tune-up. It is a choice for discipline: letting your software do less work for the same business value. Not because CSRD says you “have to,” but because it improves your balance sheet. The rest is a bonus: fewer emissions, less peak load, fewer fires.
What matters now for ambitious CIOs/CFOs/CTOs is this: can you demonstrate that a single order, invoice, or API call requires less CPU time, less I/O, and less network than last month? Can you show that tail latency is decreasing while capacity is going down? Can you give your auditor hard, reproducible figures and your finance team a lower, predictable bill? That's where maturity lies. That's where greenwashing ends.
The pitfall is tempting: “We've set the BIOS to balanced, so we're doing well.” That's window dressing, and it doesn't really save anything. Or rather... it really doesn't. If your applications are unnecessarily calculating, logging, and communicating, every clock tick wastes energy, both in your own data center and in the cloud. Then every “green” report is a nice story on paper, but you don't see it reflected in your invoice. And not in your CO₂ accounting.
The reward for real efficiency is cumulative. Fewer cycles per transaction scale with growth. You pay less for the same turnover. Your SLOs become more stable. Your platform becomes much easier to manage. And yes: your CSRD paragraph becomes stronger, because you substantiate it with measurement series in joules and euros, not with separate check marks.
Does culture play a role in this? Yes. KPIs that focus on “energy and costs per transaction,” not on “servers occupied.” Governance that makes optimization structural (definition of done, performance budgets, logging standards). And reporting that understands the business: what does an order cost, what does optimization deliver, when is something “green enough”?
In short: sustainable IT starts where value is created – in your software – and ends with hardware as the final piece. Everything in between is management, discipline, and proof.
Sounds good? It is. That's what we think, and more importantly, that's what our customers think.
Would you also like to know what your applications really cost in kWh, CO₂, and euros per transaction? And what you can gain in weeks?
Request the no-obligation Sustainable IT Quick Scan now. We measure your environment, show you the hotspots, and provide before/after figures with hard numbers. No green stickers, just green results.
👉 informatie [at] sciante [dot] nl (subject: I%20want%20to%20have%20green%20code) (Send us a message to make an appointment.)