GreenOps & FinOps series brief, counting the cost of cloud

GreenOps is a growing movement… and its proliferation has sprouted a corresponding and commensurate increase in focus on FinOps.

Another portmanteau in the DevOps style, GreenOps can be defined as a set of workflow practices and principles designed to execute operations at the optimum cost, but also at the lowest possible level of environmental impact.

Because FinOps drives business sustainability in terms of its ability to keep an organisation cost-effective, it also helps address sustainability from the point of view of resource consumption and wastage.

As such, FinOps and GreenOps often go hand in hand.

As a key facilitating factor in successful GreenOps, FinOps operations methodologies are aligned to deliver better financial cost performance with key considerations for regulatory compliance, competitive advantage, innovation and efficiency – and that’s efficiency from a sustainable GreenOps perspective as much as (if not before) any question of business efficiency is considered.

As GreenOps now becomes a core requirement of IT operations alongside security, maintainability, performance and scale, now is a key time to uncover as many of the influencing factors in this space as possible. 

On the green verge

There’s currently something of a convergence between FinOps and GreenOps.

Certainly, the formalisation of best practices as advocated by the FinOps Foundation (a non-profit trade organisation under the Linux Foundation) have helped codify the difference between right and wrong, between good and bad… and between cost-prohibitively foolish and downright on the money (pun accidental, but appropriate) prudent.

FinOps in the GreenOps universe is not operations for finance teams in the first instance (although it can be inferred that all operations efficiencies are also experienced in the financial department of any given business); it is operations focused on the bottom line(s), plural, that underwrite the extent to which an organisation’s IT footprint impacts its profitability and sustainability.

As the Computer Weekly Developer Network blog embarks upon a series of guest contributions designed to thoroughly analyse and unpack GreenOps and its FinOps support mechanisms, key questions relating to regulatory compliance will surface. We need to ensure application and data processing resource consumption is not only cost-optimised, but we also need to work to make sure it is aligned with corporate environmental, social and governance (ESG) goals. 

This is a sensitive subject in some regards and we will naturally expect to see regional differences in terms of the way regulatory compliance is mandated. Many world nations and regions have implemented regulations and standards related to environmental sustainability, but not all are the same.

Cost & carbon, two sides of 1 coin

We encourage commentary on just how far we can now say that, in the cloud, cost and carbon are two sides of the same coin; they can not be separated as two independent issues because they are so deeply rooted in each other’s domain.

Key factors in this market to discuss will include visibility (of compute, storage and analytics service resources used) and attribution (the confirmed alignment of any given element of IT to its department, company division or indeed individual users), because of course we cannot manage what we don’t measure. 

Companies will use tagging and labelling strategies to map cloud costs and carbon footprints to specific departments, teams, individuals or final products. 

What monitoring tools will companies now use to identify over-provisioned instances so that they can perform so-called “rightsizing” to get their FinOps and GreenOps credentials on track?

Zombies in the shadows

With the spectre of shadow IT now coming into focus, where resources are being consumed without a higher level of organisational approval or sanctioning, firms will want to look for “zombie assets” too i.e. unused or unattached storage volumes and idle load balancers, which are clearly identifiable areas of waste.

Other areas for discussion include the need to architect for elasticity. This is the shift from cloud computing being regarded as an always-on infrastructure to one that is more on-demand, so this would logically include techniques such as serverless and auto-scaling.

Always a thorny subject, but commitment-based discounts and the adoption of Reserved Instances (RIs) comes into question here, especially from the FinOps (if not so much the GreenOp) perspective. We must also mention spot instance utilisation, where “spare capacity” (also known as spot instances) are significantly cheaper.

A consideration for both FinOps and GreenOps, the approach is argued to maximise the utility of existing hardware that is already powered on and “idling” in a state of non-functional languish.

Start with sustainable software 

With all the system-level optimisation in focus here, it’s important to remember that sustainable systems start with sustainable software. That means efficient coding practices to avoid so-called “code bloat” that will help reduce CPU (and indeed GPU and TPU) compute cycles and memory usage. 

This efficiency is also reflected in how much data transfer (and initial data ingestion) is required for any given application to operate. At this point, firms will need to think about data prioritisation efficiencies and identify which information resources can move to more infrequently accessed “cold” storage repositories, as this reduces the power requirement needed for high-performance disks.

Overall, we’re also looking to hear about the rise of a new shared accountability culture as both the software application development, finance and dedicated sustainability teams all start to work together more closely to develop a culture where software engineers understand the financial and environmental impact of every line of code they deploy… and where the business function understands more directly the needs of the IT function as a whole.

Wind affects clouds

Not all datacentres are created equal, so (depending on how much choice an organisation has) firms will need to examine how much of their workloads they put in regions with lower grid carbon intensity. 

As hydroelectric power and wind power now come to the fore, we can fortuitously say that wind does affect clouds after all.