GreenOps - Cycloid: Cost & carbon, build it in now (or pay for it later)

AI fuels the fire

Cloud spend is now measured in the billions and AI has poured fuel on that fire. Training models, running inference and moving data at scale are driving compute usage to levels most organisations were never architected to control.

Yet sustainability is still treated like a compliance checkbox, something reviewed after the fact in a quarterly report. That is like trying to fix a leaking engine by waiting for your next fuel bill. The waste is already baked in and no amount of reporting will undo it.

Treating sustainability as a separate reporting line only makes the problem worse. When GreenOps lives in dashboards disconnected from developer workflows, organisations effectively hard-code a silo of waste into their infrastructure. Unless a company is willing to staff, fund and operationalise that silo continuously (and most are not), it becomes theatre rather than control. Real sustainability only works when cost and carbon signals are part of the same platforms developers use to build, deploy and scale software. Otherwise, inefficiency is not an accident. It is an architectural choice.

So what’s the answer? 

It shouldn’t start with slowing AI adoption or restricting experimentation, but giving teams platforms that make consumption visible and manageable from the start. Without that foundation, AI simply magnifies inefficiency. With it, teams can innovate confidently, knowing the impact of their choices before they commit to them.

A platform perspective

From a platform engineering perspective, GreenOps and FinOps are converging and will continue to do so, for a simple reason. Cost and carbon are driven by the same infrastructure decisions made every day by development teams. In the cloud, financial and environmental impact cannot be separated. Instance sizing, storage choices, data movement and how long services are left running all influence both spend and emissions.

Cycloid founder Brial: Developers (and platform engineering teams), please take note, you cannot optimise what your platform hides.

These are not strategic decisions made once a year. They are small, frequent choices made at build and deploy time. When teams lack visibility into those impacts at the moment the decisions are made, optimisation becomes slow, frustrating and often ignored as it becomes a blocker due to the initial bad implementation.

But remember, you cannot optimise what your platform hides.

The truth is, developers want more oversight into their environmental impacts – if only for purely fiscal reasons. They already optimise for performance, reliability and delivery speed because those signals are visible and immediate, but cost and carbon are usually more opaque until weeks later, buried in reports that arrive long after the code is in production.

The challenge is amplified in multi-cloud environments. Many organisations operate across regions, providers and business units, each with their own tools and processes. Fragmentation makes it almost impossible to optimise at scale. Disconnected FinOps tools, sustainability dashboards and cloud-native reports create blind spots and slow down action. This is when you need a unifying orchestration layer, or else policies are inconsistent and optimisation depends on manual intervention. Orchestration and centralisation at this level is about creating coherence, not removing autonomy.

Building it in, not bolting it on

Sustainability is often misunderstood as doing less. In reality, it is about consuming better. Rightsizing, elasticity and automation reduce idle resources and unnecessary workloads. That improves delivery speed and reliability as much as it reduces waste and it allows more money to be spent on initiatives that work or deliver more. So it really isn’t about squeezing innovation but making it delivery-focused. When platforms handle optimisation continuously, developers spend less time firefighting and more time building.

The most effective organisations treat GreenOps and FinOps as outcomes of good product design, not as standalone initiatives. When cost and carbon are signals inside developer platforms, sustainability stops being a clean-up exercise and becomes part of how software is delivered every day.

Teams that invest in this approach will move faster, waste less and scale responsibly, not because they were told to, but because the platform makes it the easiest path forward.