Chapter 6: Energy Efficiency – Designing Green Software

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement not replaced the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome back to the Deep Dive.

Today we're diving into something that often runs silently in the background but has huge implications, energy efficiency and software systems.

Right, it's a critical topic.

And I love this quote from Stephen Hawking to kind of set the stage.

He said,

energy is a bit like money.

Yeah.

You weren't allowed to be overdrawn.

That's a perfect analogy because honestly for decades in computing, we sort of acted like we had unlimited funds, didn't we?

Yeah, like power was just free, endless.

Exactly, we designed assuming that.

But those days are definitely over, energy efficiency.

It's now what we call a first class quality attribute.

Meaning you have to plan for it right from the start.

Absolutely, you have to architect for it.

And this shift, it's really being pushed by, well, three massive trends in tech today.

Okay, let's hear them.

I bet I can guess the first one.

Mobile.

You got it.

Mobile devices, the battery, everyone feels that constraint every single day.

It's not just nice to have, it's make or break for usability.

Totally.

Then second, you've got the internet of things, IoT, the sheer explosion in the number of devices.

Billions of tiny things everywhere.

Billions.

And with these tiny devices, suddenly their individual power draw, the heat they generate, their small size, it all adds up.

Micro optimizations suddenly matter on a planetary scale.

Okay, mobile IoT, what's the third?

The giant in the room.

Yeah.

Cloud services, the server farms powering everything, their energy consumption is, well, it's staggering.

Staggering is the right word.

I saw a stat that seemed almost unbelievable.

Which one?

There are a few scary ones out there.

That back in 2016, data centers used 40 % more energy than the entire UK.

Yeah, that's a well -known one.

And more recent estimates, they're pushing that figure maybe as high as 10 % of all global electricity consumption.

We're talking about a massive slice of the pie.

That's why, wow, it explains why we hear these, frankly,

kind of wild ideas.

Like putting data centers where?

Underwater in the Arctic.

I even read something about space, all just to handle cooling and power costs.

Right.

It shows how critical managing power has become.

It's a defining operational cost now.

So that brings us to our mission for this deep dive.

We need to really get into the architectural side of this.

Exactly.

Why does energy efficiency need architecture?

What are the inevitable trade -offs you have to make?

And critically, what are the specific design tools, the scenarios, the tactics, the patterns that architects use to actually manage this?

Okay, let's tackle that first question.

It seems obvious why performance needs an architect, but why energy?

Can't developers just write, you know, efficient code?

Ah, if only it were that simple.

It really boils down to three things.

Coordination,

expertise,

and maturity.

Coordination.

Yeah.

Getting real, predictable energy savings usually requires system -wide approaches.

You need to monitor and control things across the whole stack servers, VMs, network gear.

Right.

If the architecture doesn't provide the hooks, the interfaces for that kind of monitoring and control, then individual developers might do their own thing, but it'll be fragmented.

It won't achieve those big system level goals.

Now, the architecture needs to enable that coordination.

Got it.

What's next?

Expertise, or rather the lack of it currently.

Most architects and developers, frankly, haven't been trained to specifically engineer for energy efficiency.

It's not really standard curriculum, is it?

Not yet, no.

So there's often a knowledge gap.

People don't necessarily have the vocabulary or the frameworks to even think about it systematically.

Okay.

Coordination, expertise,

and maturity.

Right.

The design concepts themselves, the specific patterns and tactics for managing energy, they're still relatively new compared to, say, patterns for performance or availability.

Still evolving?

Exactly.

So they need deliberate, conscious application at the architectural level.

We need architects to actively use and refine these ideas.

That makes a lot of sense.

Okay.

So architecture is key.

Now, let's talk about those trade -offs you mentioned.

This sounds like a classic balancing act.

If I push hard on energy efficiency, what am I likely giving up?

It's the fundamental challenge of architecture, isn't it?

You're always balancing competing qualities.

For energy, the main ones you treat against are usually performance, availability, maybe modifiability, and definitely time to market.

Can you give us an example, maybe contrast cloud and mobile?

Sure.

So in the cloud,

if your absolute top priorities are performance and availability, like lightning fast responses,

always on what do you do?

You throw hardware at it, over -provision.

Exactly.

You run more servers, more instances than you strictly need at any given moment.

That gives you speed.

It gives you redundancy if something fails, but it burns a lot more power.

So you're trading energy, and therefore money, for speed and uptime.

Precisely.

Now, flip to a mobile device or an IoT sensor, you often don't have the luxury of just adding more power.

The battery is finite.

Right.

The trade -off must shift them.

It does.

It often becomes energy efficiency versus, say, user experience or features.

If I make my app super energy efficient by turning off the GPS constantly.

Your navigation feature becomes useless.

Exactly.

Or if I dim the screen too much or reduce the network pulling rate too low, you save battery, but you might frustrate the user or break functionality.

Finding that sweet spot is crucial.

Okay.

So finding that sweet spot requires defining what good enough looks like for everything else while maximizing energy savings.

How do we formally define that?

That's where the idea of an energy efficiency general scenario comes in.

It's basically a structured way to state your requirement, covering all the key aspects.

Think of it like a template.

Like a fill -in -the -blanks for requirement.

Sort of, yeah.

It helps make sure you consider everything.

It has six parts.

Source,

stimulus, artifact, environment response, and response measure.

Let's walk through an example.

Maybe that cloud scenario again.

Okay.

Imagine a manager at a cloud provider wants to cut costs.

That manager is the source.

Got it.

The person making the request.

Right.

The stimulus is what they want.

Reduce average total energy usage.

The specific goal.

Yep.

The artifacts are the things being managed, let's say a specific cluster of servers and virtual machines.

Target system.

And the environment is the condition under which this happens maybe during non -peak periods or at runtime.

Okay.

Makes sense.

Now the action part.

The response is what the system actually does.

In this case, maybe it's De -allocate unused resources and consolidate VMs.

And the crucial part,

the measurement and constraints.

That's the response measure.

It's not just energy saved.

It has to include the constraints.

So it might be.

Achieve a 50 % average reduction in total energy used while maintaining a worst -case latency of two seconds on database queries.

Ah, okay.

So that ties the energy goal directly to an acceptable level of performance.

You can't save energy by making the database unusable.

Exactly.

It defines success holistically.

Considering the other critical qualities, it gives you that concrete target.

That's much clearer than just listing abstract components.

Okay.

We know how to define the goal.

Now how do we actually achieve it?

Let's talk tactics.

You said they fall into roughly three groups.

That's right.

The framework groups them into tactics for monitor resources, tactics for allocate resources, and then a related group, reduce resource demand.

The first two are about using resources wisely.

Let's start with monitoring.

The old saying, you can't manage what you can't measure.

Precisely.

So the first tactic under monitoring is metering.

Like putting an electricity meter on the server rack.

Essentially, yes.

It's about collecting real -time or near real -time power consumption data using actual sensor infrastructure.

That could be power meters for a whole data center,

specialized chips, ASICs inside a component,

metered power distribution units, PDUs, for server racks.

Or the battery management system in my phone.

Exactly.

Direct measurement.

But what if you can't directly measure?

Like you're using a public cloud service you don't physically control.

Right.

I can't plug my own meter into AWS's servers.

No, you can't.

That's where the second tactic comes in.

Static classification.

Static, meaning based on known information.

Yeah.

You estimate the energy consumption based on known characteristics.

Manufacturer data sheets, published benchmarks, maybe historical data for similar workloads.

It's an educated guess when direct measurement isn't feasible.

Okay.

But workloads change, right?

What if consumption varies a lot?

Good point.

That leads to the third monitoring tactic.

Dynamic classification.

So estimating based on current conditions.

Correct.

You estimate consumption based on transient factors like the current CPU load, network traffic, things like that.

This could be as simple as a lookup table.

If CPU is at 50%, estimate X watts.

Or it could involve more complex regression models trained on past data or even system simulations.

So, metering for direct data.

Static classification for estimates based on specs.

Dynamic classification for estimates based on current load.

Makes sense.

Those give you the visibility.

Now you need tactics to act on that information.

That's the second group.

Allocate resources.

This is about deciding where the work happens.

With energy in mind.

Exactly.

Mindful assignment of work.

The first and maybe most obvious tactic here is reduce usage.

Just use less stuff.

Pretty much.

At a device level, this could mean dimming the screen, lowering the refresh rate.

At a system level, it's things like spinning down hard drives that aren't being accessed, powering down idle CPU cores or entire servers.

The going dark idea.

Right.

Or consolidating virtual machines onto fewer physical servers during low load periods.

And for mobile, you mentioned offloading computation earlier.

Sending work to the cloud.

Yes.

Computation offloading is a key reduce usage tactic for mobile.

But it's tricky.

Because sending the data takes energy too, right?

Exactly.

You only save energy if the computation itself is significantly more power hungry than the energy needed to transmit the data, wait for the result, and receive it back.

Architects have to do that calculation carefully.

A critical calculation.

Okay, what other allocation tactics are there?

There's discovery.

Think about how service discovery normally works finding a service based on location or capability.

Okay.

While energy aware discovery annotates services or requests with energy information.

So a component needing a task done could ask, find me a provider that can do this with the lowest current energy cost.

Ah, like a green service directory.

So you could route work to the least loaded, most efficient server cluster.

Precisely.

It allows for dynamic energy optimized routing of tasks, especially in cloud or distributed environments.

Clever.

And the last allocation tactic.

Schedule resources.

This builds on monitoring and discovery.

It's about actively scheduling tasks onto resources based on energy efficiency and potentially costs.

So the system might decide, okay, core three is less loaded right now.

Run this task there.

Or even switch this workload to a different cloud provider that's currently cheaper or greener.

Exactly.

It's dynamic allocation based on efficiency metrics.

Okay.

Monitor, allocate.

What was the third group?

Reduce resource demand.

It's slightly different.

Instead of managing how resources are used, it focuses on reducing the amount of work the system needs to do in the first place.

How does that work?

Examples might be things like limiting how often the system responds to certain events, maybe dropping low priority events entirely if the system is under strain or throttling the rate at which events can even arrive.

Basically ensuring the system isn't wasting energy on unnecessary processing.

Got it.

Making the system do less work overall.

Right.

And architects can use all these tactics, the monitoring ones, the allocation ones, to form a kind of checklist.

There's actually a tactics -based questionnaire based on this framework.

Oh, neat.

How does that work?

It turns the tactics into direct questions you can ask about an architecture.

Like, does the system use metering to track server power?

Or does the system employ dynamic classification for workload estimation?

It's a quick way to assess how well an architecture supports energy efficiency.

That sounds really practical.

Okay, we've got the definitions, the requirements framework, the specific tactics.

Now let's talk about putting these together into reusable solutions.

Architectural patterns.

Yes.

Patterns package these ideas into common repeatable structures.

Let's look at three key ones for energy efficiency.

First up, sensor fusion.

Sensor fusion.

Sounds like something from sci -fi.

Huh.

Maybe a little, but it's very practical, especially for battery -powered devices with multiple sensors, like smartphones or wearables.

Okay, what's the core idea?

You use a low -power sensor to make an intelligent guess about whether a high -power sensor is actually needed right now.

Give me an example.

Think about a fitness tracker.

It might have a very low -power accelerometer that's always on, just detecting basic movement.

Only when the accelerometer data suggests the user has started running or cycling does the system power up the much more energy -hungry GPS sensor to get an accurate track.

So the cheap sensor acts like a gatekeeper for the expensive one.

Exactly.

The benefit is you minimize how long that power -hungry GPS is actually running.

You save significant battery life.

Makes sense.

What's the downside?

The trade -off.

Well, complexity, for one.

You need good algorithms to make reliable inferences from that low -power sensor data.

And there's latency.

Latency.

Yeah, if the user starts running, it takes a moment for the accelerometer to detect it, then for the GPS to power up and get a fix.

The user might notice that delay.

Or if the inference is wrong, often.

Even worse, if your algorithm keeps thinking you're running when you're not and keeps firing up the GPS unnecessarily, you could actually end up using more power than just leaving the GPS on low -power mode.

Tricky balance.

Okay, pattern one.

Sensor fusion.

What's next?

Pattern two is kill abnormal tasks.

This one is really important in environments where you might have software you don't fully trust.

Like apps on a smartphone.

Or maybe different tenants in a cloud system.

Exactly.

The idea is the system monitors running processes or tasks, looking for behavior that's energy -greedy or abnormal.

What counts as abnormal?

Like a background app that's suddenly using 100 % CPU for minutes on end or constantly accessing the network or sensors when it shouldn't be.

Okay.

And what does the pattern do?

It interrupts or just outright kills that misbehaving task after some threshold or timeout.

So if my weather app gets stuck in some weird loop trying to update, the OS might eventually shut it down to save my battery.

Precisely.

It's a failsafe.

It protects the system and the battery from runaway processes, whether they're buggy or even malicious, like some hidden crypto mining malware.

That seems essential.

What's the trade -off there?

Monitoring must take some energy.

It does, but usually it's very small overhead.

The bigger concern is usability.

How so?

If the system is too aggressive with its definition of abnormal, it might kill a task the user actually wanted to keep running, even if it was using a lot of power for a while.

Like a big file download or a video encode.

Right.

Killing that could be really frustrating.

So tuning the detection and potentially involving the user.

This app is using a lot of power.

Do you want to close it?

Is key.

Right.

User control is important.

Okay.

Sensor fusion kill abnormal tasks.

What's the third pattern?

Power monitor.

This one is often implemented at a lower level, maybe in the operating system or even down in the hardware drivers or firmware.

Okay.

What's its job?

It automatically disables or powers down hardware components, interfaces, peripherals, things like Wi -Fi radios, Bluetooth, GPS, even specific blocks within a chip when they aren't actively being used by any running application.

So if no app is currently asking for location data, the power monitor shuts down the GPS chip completely.

Exactly.

Or if you're connected via ethernet, it might power down the Wi -Fi radio.

It minimizes the idle power draw of components that aren't needed right now.

The benefit seems clear.

Saves power intelligently without the application necessarily even knowing.

What are the catches?

Latency is the big one again.

When an application does need that component, it takes time to power it back on.

Turning Wi -Fi back on isn't instantaneous.

Right.

There's a delay.

And there's a more subtle issue too.

Sometimes the energy surge required to power component up can actually be more than the energy saved by having it off for a very short period.

Oh, interesting.

So flicking it off and on rapidly could be worse than leaving it in a low power idle state.

It can be.

Yes.

So an effective power monitor pattern needs really detailed knowledge of the characteristics of each individual component.

It manages the costs of startup versus idle, the time thresholds.

It's not trivial to implement well.

Wow.

Okay.

These patterns really illustrate how managing energy involves deep system knowledge and careful trade -offs.

Absolutely.

It really drives home that energy efficiency isn't some simple add -on.

It's a core architectural concern.

So wrapping this up, it's clear that energy efficiency has moved from being an afterthought, if it was thought of at all, to a fundamental quality attribute.

Definitely.

And it demands architects make conscious decisions, use specific techniques like monitoring and allocation,

manage those difficult trade -offs, and leverage patterns like the ones we discussed.

Whether you're trying to optimize massive cloud data centers or just squeeze another hour out of a smartphone battery.

Exactly.

It requires applying the structured architectural concepts, the scenarios, the tactics, the patterns to tackle what's become a really critical issue, both technically and frankly, globally.

Well, thank you.

This has been a fascinating deep dive into a

really vital area of modern software architecture.

My pleasure.

It's complex, but super important stuff.

And for you, our listener, we want to leave you with a final thought to chew on, inspired by the source material for today's dive.

Consider this.

If a company like Google managed to reduce the energy used for each search by just 1%, how much energy would that save globally in a year?

It's a mind -boggling number to even estimate.

Right.

And then maybe compare that massive potential saving to the tiny amount of energy your brain just used thinking about that question.

It puts the scale into perspective, doesn't it?

It certainly does.

Keep thinking about efficiency.

Keep diving deep.

Thanks for joining us on the deep dive.

We'll catch you next time.