Background

Sustainability¶

Sustainability, as a pillar, is about the resources your workloads consume: using as few as the job needs, for only as long as it needs them. The choices that matter are the ones you make about what to run, how big, and for how long.

What the pillar covers¶

Every instance, volume and backup runs on physical hardware that uses energy and materials. You don't choose the hardware, but you do choose how much of it your workloads occupy. A workload that runs at the right size, turns off what it isn't using, and keeps data only as long as it's needed asks less of that hardware.

Most of this pillar overlaps with Spend efficiency and Performance efficiency. The difference is the reason: the same habits that trim an invoice also reduce the resources a workload ties up.

Design principles¶

Principle	What it means in practice
Understand what you use	Know which resources each workload holds and how busy they are
Raise utilization	Fewer, well-used instances in place of many lightly used ones
Right-size	Match each flavour to the load; see Performance efficiency
Turn off what's idle	Delete or rebuild-on-demand environments that are only used some of the time
Scale with demand	Add capacity when load rises and remove it when load falls
Keep data only as long as it's needed	Set retention for snapshots, backups and logs, and delete what's past it
Make the software efficient	Efficient code and queries do the same work on fewer resources

Utilization¶

An instance that averages a small fraction of its vCPUs still holds all of them. Consolidating light workloads onto fewer instances, or moving them to smaller flavours, frees capacity without losing anything the workload uses. Measure first; Performance efficiency shows what to look at on Windows and Linux.

Idle resources¶

Development, test and training environments are often busy during working hours and idle the rest of the time. When they're built from code, they can be deleted at the end of a piece of work and rebuilt when the next one starts. See Pets vs cattle.

Data retention¶

Data grows quietly. Snapshots taken before a change, backups from years ago, log files nobody reads: each one occupies storage for as long as it exists. A retention rule for each kind of data, such as how many snapshots to keep and for how long, stops the growth.

Kind of data	A question to settle
Volume and instance snapshots	How many are kept, and when are old ones deleted?
Volume backups	How long must each backup be kept to meet your recovery needs?
Logs	How long are logs needed for troubleshooting or compliance?
Test and temporary data	Is it deleted with the environment that created it?

What it looks like on Breqwatr Cloud¶

Usage shows what each project holds. A project's usage page lists metered resources by type, which is a starting point for finding idle and oversized resources.
Resources go away when you delete them. Deleting an instance removes its root volume by default; data volumes, snapshots and floating IPs stay until you delete or release them.
An instance snapshot can keep a root volume. An instance snapshot of a volume-backed instance also snapshots its volumes, so after the instance is deleted its root volume can remain, holding storage and still billed. It shows in the project's volume list as available. Delete the instance snapshot image, then the volume snapshots made with it, then the volume; see Instance snapshots and the root volume.
Capacity can follow demand. Instances can be added behind a load balancer and removed again, instances can be resized, and BKS clusters can add and remove worker nodes.
Snapshots are listed per project, so old ones can be found and deleted.

Impact¶

Workloads hold the resources they use, and release the rest.
Data that's past its use is deleted on a schedule rather than kept by default.
The same habits reduce spend, so sustainability and spend efficiency improve together.

Common anti-patterns¶

Always on: environments that are only used during working hours, running around the clock.
Many small, mostly idle instances: each holding a full flavour's worth of resources while doing little.
Keep everything forever: snapshots, backups and logs with no retention rule.
Over-provisioned for comfort: headroom far beyond what measurement shows the workload needs.