9.4 Custo, sustentabilidade e software verde

Visão geral e motivação

O software roda em infraestrutura física que consome dinheiro, eletricidade, água e materiais. Durante a maior parte da história da computação, esses custos eram problema de outra pessoa: os orçamentos de capital escondiam o hardware, e a energia era invisível para os engenheiros. A computação em nuvem mudou isso. Tornou o consumo granular, sob demanda e diretamente atribuível, o que transformou o custo, e cada vez mais o carbono, em preocupações de engenharia. Este capítulo cobre duas disciplinas entrelaçadas: o FinOps, a prática de trazer responsabilização financeira ao gasto variável em nuvem, e o software verde, a prática de construir sistemas que fazem o mesmo trabalho com menos energia e menores emissões de carbono. Elas se sobrepõem bastante, porque um software eficiente costuma ser ao mesmo tempo mais barato e mais limpo.

Para grandes equipes, os números são enormes. As contas de nuvem de uma grande empresa podem chegar a dezenas ou centenas de milhões por ano, e alguns pontos de desperdício representam dinheiro real que poderia financiar pessoas ou produtos. A pegada de carbono de grandes patrimônios digitais também é material, e as organizações enfrentam pressão crescente de reguladores, investidores, clientes e dos próprios funcionários para medi-la e reduzi-la. Quando centenas de equipes tomam, cada uma, decisões independentes sobre tamanhos de instâncias, retenção de dados e arquitetura, pequenas ineficiências se compõem em grandes custos e emissões. Uma governança que torne o custo e o carbono visíveis e passíveis de responsabilização é essencial para manter ambos sob controle.

A relevância corporativa e governamental é direta. As organizações do setor público gastam dinheiro dos contribuintes e estão cada vez mais sujeitas a mandatos de sustentabilidade e a compromissos de emissões líquidas zero, de modo que demonstrar uma operação eficiente e de baixo carbono é ao mesmo tempo uma obrigação fiscal e de política. As empresas enfrentam o escrutínio dos investidores sobre o desempenho ambiental e a pressão competitiva sobre as margens. Em ambos os casos, custo e sustentabilidade passaram de reflexões tardias a preocupações de nível de conselho. As escolhas de engenharia são onde essas preocupações são, no fim, realizadas ou perdidas.

Princípios fundamentais

Tornem o consumo visível. Não se otimiza o que não se vê. Custo e carbono precisam ser atribuídos às equipes e serviços que os causam.
A responsabilização fica com os donos. Os engenheiros que provisionam recursos devem ver e assumir o impacto de custo e de carbono.
A eficiência serve ao custo e ao carbono juntos. Fazer o mesmo trabalho com menos recursos costuma economizar dinheiro e emissões ao mesmo tempo.
Dimensionem continuamente. A demanda muda, então o provisionamento precisa ser revisitado, não fixado uma vez e esquecido.
O carbono tem tempo e lugar. A mesma computação emite mais ou menos conforme quando e onde a eletricidade é gerada.
Equilibrem o triângulo. Custo, desempenho e confiabilidade se trocam uns pelos outros. Otimizem deliberadamente, não às cegas.
Projetem para a eficiência cedo. As escolhas arquiteturais dominam o custo e o carbono de longo prazo muito mais que o ajuste tardio.

Recomendações

Estabeleça visibilidade, otimização e responsabilização de FinOps

O FinOps avança em três fases iterativas. Informar: construam visibilidade por meio de etiquetas, alocação e painéis, para que todo custo seja atribuído a uma equipe, serviço e finalidade de negócio, e os custos compartilhados sejam divididos de modo justo. Otimizar: eliminem o desperdício (recursos ociosos e órfãos), dimensionem corretamente os serviços superprovisionados, adotem descontos por compromisso, como reservas ou planos de economia, para a carga-base estável, e usem capacidade spot ou preemptível para o trabalho interrompível. Operar: embutam o custo na prática normal de engenharia com orçamentos, alertas de anomalia, previsões e revisões regulares. Acima de tudo, ponham os dados de custo diante dos engenheiros que os criam. Façam da eficiência um objetivo compartilhado de engenharia, finanças e produto, não uma preocupação só das finanças.

Construa software consciente de carbono e eficiente em energia

Reduzir o carbono tem três alavancas. Eficiência energética: escrevam e configurem o software para fazer o mesmo trabalho com menos ciclos de CPU, menos memória e menos movimentação de dados, com melhores algoritmos, cache e evitando computação desnecessária. Eficiência de hardware: usem os recursos por completo com maior utilização, consolidação e hardware moderno e eficiente, já que a capacidade ociosa ainda consome energia e incorpora o carbono da fabricação. Consciência de carbono: desloquem as cargas flexíveis no tempo e no espaço para quando e onde a rede elétrica é mais limpa, por exemplo rodando jobs em lote quando a geração renovável é alta, ou em regiões de eletricidade de baixo carbono. Meçam usando abordagens reconhecidas como a especificação de Intensidade de Carbono do Software (Software Carbon Intensity). Prefiram provedores e regiões com fortes compromissos renováveis e relatórios transparentes.

Projete arquiteturas sustentáveis e dimensione corretamente

A arquitetura determina o piso de custo e de carbono. Favoreçam desenhos elásticos que escalam à demanda real e escalam a zero quando ociosos, para nunca pagar por manter capacidade sem uso funcionando. O serverless e o autoescalonamento reduzem o desperdício em cargas com picos, e os serviços gerenciados podem melhorar a utilização por meio da multilocação. Dimensionem corretamente computação, armazenamento e bancos de dados contra o uso real e não contra um superprovisionamento temeroso. Definam políticas de ciclo de vida dos dados para que os dados frios passem para camadas mais baratas e de menor energia ou sejam apagados. Reduzir o volume de dados e a transferência de rede corta tanto o custo de armazenamento quanto a energia de mover bits. Tratem a eficiência como um requisito de projeto, revisado ao lado do desempenho e da confiabilidade.

Equilibre custo, desempenho e confiabilidade deliberadamente

Custo, desempenho e confiabilidade formam um triângulo. Empurrem um com força e vocês em geral tributam os outros: mais redundância e menor latência custam mais e muitas vezes consomem mais energia. Tornem esses compromissos explícitos e liguem-nos ao valor de negócio. Usem SLOs (objetivos de nível de serviço) para definir quanta confiabilidade e desempenho o serviço de fato precisa e provisionem para essa meta em vez de dourar tudo de modo uniforme. As cargas não críticas e internas podem aceitar configurações mais baratas, menos redundantes e mais flexíveis quanto ao carbono. Reservem o provisionamento premium para o que genuinamente o justifica.

Governe sem sufocar

Ofereçam guardrails, não portões. As equipes centrais de plataforma podem oferecer padrões eficientes, imposição de etiquetas, alertas de orçamento e painéis de autoatendimento, deixando as decisões do dia a dia com as equipes donas das cargas. Definam metas organizacionais de eficiência de custo e de redução de carbono, relatem o progresso com transparência e celebrem as economias. Evitem a burocracia pesada de aprovação que atrasa a entrega. O objetivo é fazer da escolha eficiente o padrão fácil.

Compromissos: prós e contras

Decisão	Prós	Contras
Descontos por compromisso	Grande economia na carga-base	Aprisionamento (lock-in), risco se a demanda mudar
Capacidade spot/preemptível	Computação mais barata, usa a sobra da rede	Interrupções, complexidade adicional
Dimensionamento agressivo	Menor custo e carbono	Risco de subprovisionamento em picos
Agendamento consciente de carbono	Menores emissões	Jobs atrasados, esforço de engenharia
Redundância multirregião	Maior confiabilidade	Mais custo, energia e carbono

O compromisso unificador é que a confiabilidade e o desempenho máximos raramente coincidem com o custo e o carbono mínimos. Sistemas redundantes, sempre ligados e de baixa latência são caros e famintos de energia, de modo que dourar tudo de modo uniforme desperdiça dinheiro e emissões em cargas que não precisam. A disciplina é dimensionar a ambição ao valor de negócio usando SLOs, gastando recursos premium só onde importam. Os descontos por compromisso e a capacidade spot oferecem economia real, mas introduzem aprisionamento e risco de interrupção que vocês precisam gerenciar. O agendamento consciente de carbono economiza emissões, mas só serve a cargas que toleram atraso ou realocação.

Perguntas para discutir com sua equipe

Que parcela do seu gasto em nuvem está de fato etiquetada e atribuída a uma equipe hoje? A fase de informar do FinOps é a fundação: não se otimiza o que não se vê, e o gasto sem etiqueta e sem alocação significa que ninguém é dono do desperdício. Levem o número real de cobertura à discussão, não uma aspiração, e a lista dos maiores itens sem etiqueta. Para uma grande organização em que centenas de equipes provisionam de forma independente, uma baixa taxa de atribuição significa que ineficiências compartilhadas se compõem de forma invisível até milhões. Em contextos governamentais e corporativos, a atribuição é também como vocês defendem o gasto dos contribuintes ou dos acionistas e como alocam a parcela justa dos custos de plataformas compartilhadas. A resposta define o seu primeiro movimento: se a cobertura é baixa, a imposição de etiquetas e a alocação vêm antes de qualquer dimensionamento, porque otimizar sem visibilidade é chutar.
Quanto da sua carga-base é coberta por descontos por compromisso, e o que acontece com esses compromissos se a demanda mudar? As reservas e os planos de economia entregam grande economia na carga-base estável, mas introduzem aprisionamento, então comprar de forma agressiva demais transforma um desconto num passivo quando um produto é descontinuado ou migra. Levem os números: a sua porcentagem de cobertura comprometida, a tendência da carga-base e as cargas com maior probabilidade de mudar de forma no próximo ano. A disciplina é comprometer apenas o piso que vocês têm confiança de que persiste, cobrir a camada variável com sob demanda ou spot e revisitar conforme a demanda evolui. Para uma grande empresa, essa é uma decisão de estilo tesouraria, com exposição financeira real, então finanças e engenharia devem ser donas dela juntas e não um lado só. A resposta deve separar a sua carga-base durável da demanda incerta e dimensionar os compromissos pela primeira.
Quanto da sua frota fica ociosa, e vocês estão contando o carbono incorporado da fabricação ou apenas a energia que ela queima enquanto roda? A capacidade ociosa ainda consome energia e carrega o carbono de fabricação já gasto para construir o hardware, então focar só na energia em execução enquanto superprovisiona deixa de fora uma parte real da pegada. Levem dados de utilização: média e pico, a diferença entre provisionado e usado e onde é possível escalar a zero ou consolidar. A maior utilização serve ao custo e ao carbono de uma vez, que é o fio condutor deste capítulo, então o desperdício ocioso é a vitória mais limpa que vocês têm. Para organizações sob um mandato de emissões líquidas zero, uma medida honesta de carbono que inclua as emissões incorporadas é o que separa o progresso real da lavagem verde (greenwashing) que convida a reação regulatória e de reputação. A resposta deve mirar as cargas de menor utilização para consolidação, autoescalonamento ou escala a zero e definir uma abordagem de medição que não ignore em silêncio o carbono de fabricação.
Os seus engenheiros veem o custo e o carbono dos próprios serviços, e alguém age sobre o que vê? A visibilidade só compensa quando chega às pessoas que provisionam recursos e muda o comportamento delas, então um painel que as finanças revisam por mês mas que os engenheiros nunca abrem é decoração, não responsabilização. A atração contrária é real: as equipes de plataforma querem controle central e relatórios limpos, enquanto as equipes de entrega ressentem qualquer coisa que pareça vigilância ou mais um portão para entregar. Levem evidências de quem de fato olha os dados de custo e de carbono, com que frequência e se algum dimensionamento ou limpeza se seguiu a eles no último trimestre. Para uma grande organização em que centenas de equipes provisionam de forma independente, a diferença entre um sinal que os engenheiros assumem e um relatório que ignoram é a diferença entre economias que se compõem e desperdício que se compõe. Em contextos corporativos e governamentais, ponham a economia unitária (custo e carbono por requisição, por cliente ou por caso) diante da equipe dona, porque um número agregado defende um orçamento mas um número por unidade muda uma decisão de projeto.
Quais das suas cargas são genuinamente flexíveis no tempo ou na região, e o que seria preciso para agendá-las onde a rede é mais limpa? O agendamento consciente de carbono desloca o trabalho flexível para quando e onde a eletricidade é de baixo carbono, mas só serve a jobs que toleram atraso ou realocação, então a primeira tarefa é separar o trabalho em lote genuinamente adiável de qualquer coisa voltada ao usuário ou limitada por latência. O compromisso é que mover jobs entre regiões ou janelas fora do pico acrescenta esforço de engenharia, custo de transferência de dados e, às vezes, risco de residência de dados que podem superar as emissões economizadas. Levem uma lista candidata de jobs em lote e de análise, a tolerância à latência de cada um, suas restrições de residência de dados e a intensidade de carbono das regiões onde vocês podem legalmente rodá-los. Para empresas, essa é uma otimização modesta por cima do dimensionamento, então sequenciem-na depois dos fundamentos de custo e não antes. No governo, as regras de residência de dados e de soberania podem proibir mover dados de cidadãos entre fronteiras seja qual for a limpeza da rede, então a escolha da região é uma questão legal antes de ser de carbono.
Que metas de eficiência e de sustentabilidade vocês definiram, e elas estão escritas de modo que atingi-las não possa quebrar a confiabilidade em silêncio? As metas focam o esforço, mas uma meta grosseira de custo ou de carbono convida ao comportamento errado: as equipes subprovisionam, tiram redundância ou adiam trabalho de modos que trocam uma pequena economia por um grande incidente. A tensão está entre um número ambicioso, de cima para baixo, que a liderança consegue reportar, e uma meta de baixo para cima, fundada nos SLOs reais de cada serviço, então os dois precisam ser reconciliados e não impostos. Levem as metas atuais, a linha de base contra a qual são medidas e os guardrails de confiabilidade que impedem a otimização de cortar o que um serviço genuinamente precisa. Para uma grande organização, as metas agregadas precisam se decompor de modo justo para equipes cujas cargas diferem, de modo que um serviço de pagamentos voltado ao cliente e um job interno de relatórios não devem carregar a mesma expectativa de eficiência. Em contextos corporativos e governamentais em que números de sustentabilidade aparecem em divulgações públicas, liguem cada número reportado a um método de medição auditável, porque uma meta que vocês não conseguem defender sob escrutínio é um passivo, não uma conquista.

Perspectiva por setor

Startup. O custo é o fôlego, então uma única tarde de etiquetagem e um alerta de orçamento podem comprar mais um mês antes de captar de novo. Pulem por completo o processo de FinOps e a contabilidade de carbono; basta vigiar a conta, matar os recursos ociosos e escolher uma plataforma gerenciada que escala a zero para pagar pela carga e não pela capacidade parada à espera. O seu recurso mais escasso é a atenção da engenharia, então automatizem o desperdício óbvio e sigam em frente.

Pequena empresa. Vocês não têm especialista em FinOps e têm orçamento apertado, então apoiem-se nas ferramentas de custo que o seu provedor de nuvem já oferece em vez de comprar uma plataforma dedicada. Definam um alerta de orçamento mensal, liguem as recomendações de dimensionamento do provedor e prefiram serviços gerenciados e serverless que embutem a eficiência operacional no preço. Tratem a sustentabilidade como escolher uma região de baixo carbono e um padrão eficiente, não como um programa de relatórios que vocês precisam manter com equipe.

Grande empresa. O problema é a governança entre muitas equipes: etiquetagem consistente, alocação justa dos custos de plataformas compartilhadas, estratégia de descontos por compromisso de que finanças e engenharia são donas em conjunto, e custo e carbono expostos como sinais que toda equipe vê. Padronizem padrões eficientes e um método de medição para que centenas de decisões independentes de provisionamento não se componham em desperdício e gerenciem o gasto em nuvem e as emissões como um portfólio, com metas, alertas de anomalia e relatórios transparentes e não um amontoado de otimizações locais.

Governo. As regras de contratação, a transparência e a prestação de contas públicas moldam toda escolha. Vocês gastam dinheiro dos contribuintes e muitas vezes estão sujeitos a um mandato de emissões líquidas zero, então precisam mostrar tanto prudência fiscal quanto progresso auditado nas emissões, o que significa uma medida honesta de carbono que inclua o hardware incorporado e não lavagem verde. As regras de residência de dados e de soberania podem restringir que regiões vocês podem usar seja qual for a limpeza da rede, e as métricas de eficiência e de emissões podem precisar ser publicadas para o escrutínio público, então escolham métodos de medição que vocês consigam defender numa auditoria.

Exemplos

Startup. Uma startup em estágio semente vê a conta de nuvem dobrar em dois meses e não sabe dizer por quê. Um fundador gasta uma tarde etiquetando todo recurso por funcionalidade e liga um alerta simples de orçamento. As etiquetas revelam um cluster de staging esquecido e um banco de dados superdimensionado rodando o dia inteiro para um job noturno. Desligar o cluster e mover o job para uma execução agendada fora do pico numa instância menor corta a conta em um terço, o que compra mais um mês de fôlego para a equipe.

Grande empresa. Uma varejista multinacional com um patrimônio de nuvem grande e disperso monta uma prática de FinOps. Ela impõe etiquetas, aloca todo custo a uma equipe de produto e expõe o gasto em painéis que os engenheiros veem todo dia. Em um ano, remove recursos ociosos, dimensiona corretamente serviços superprovisionados e compra planos de economia para a carga-base estável, cortando o gasto em nuvem em cerca de um quarto. Depois agenda os jobs noturnos de análise em lote para rodar em regiões de menor carbono e fora do pico, reduzindo custo e emissões, e relata a economia de carbono em sua divulgação anual de sustentabilidade.

Governo. Uma agência governamental que opera serviços ao cidadão sob um mandato nacional de emissões líquidas zero precisa mostrar tanto prudência fiscal com o dinheiro dos contribuintes quanto progresso rumo às metas de emissões. Ela dimensiona e consolida as cargas, define políticas de retenção de dados que movem registros raramente acessados para um armazenamento frio e de baixa energia e seleciona regiões de nuvem alimentadas por altas parcelas de eletricidade renovável. Mede a intensidade de carbono de seus principais serviços e publica métricas de eficiência e de emissões para prestação de contas pública. Padrões eficientes e painéis de autoatendimento permitem a dezenas de equipes de entrega fazer escolhas sustentáveis sem gargalos centrais.

Justificativa de negócio: motivações, ROI e TCO

O retorno aqui é excepcionalmente direto. A otimização de FinOps costuma reduzir o gasto em nuvem de um quinto a um terço com esforço disciplinado, uma economia que vai direto para o resultado ou para financiar novo trabalho. A redução de carbono também carrega cada vez mais valor financeiro, por meio do preço de carbono evitado, da elegibilidade a contratos com exigências de sustentabilidade e do menor risco regulatório e de reputação. Como a eficiência reduz custo e carbono de uma vez, um único investimento em visibilidade e dimensionamento se paga nas duas dimensões.

O custo total de propriedade precisa contar o custo de adoção: ferramentas de visibilidade de custo e de carbono, a equipe de FinOps ou de plataforma para rodar a prática e o tempo de engenharia para dimensionar e rearquitetar. São modestos diante das economias e encolhem conforme os padrões eficientes se incorporam. O custo de não adotar se compõe em silêncio: contas de nuvem descontroladas que crescem mais depressa que o negócio, desperdício que nunca vem à tona porque ninguém é dono dele e exposição regulatória, de investidores e de reputação crescente sobre a sustentabilidade. Para defender o caso junto à liderança, apresentem o gasto atual e sua trajetória de crescimento, o desperdício estimado e as economias de referência da adoção de FinOps. Depois combinem isso com a redução de emissões e o valor de conformidade. Enquadrem custo e sustentabilidade como a mesma iniciativa de eficiência vista por duas lentes, para que o negócio não precise escolher entre economizar dinheiro e cortar carbono.

Antipadrões e armadilhas

Sem atribuição de custos. O gasto sem etiqueta e sem alocação significa que ninguém é dono do desperdício e ninguém consegue otimizá-lo.
Provisionamento de configurar e esquecer. Dimensionar os recursos uma vez e nunca revisitá-los garante a deriva para o superprovisionamento.
FinOps só das finanças. Tratar o custo como preocupação de retaguarda e não como sinal de engenharia fracassa, porque os engenheiros tomam as decisões que conduzem o gasto.
Lavagem verde (greenwashing). Alegar sustentabilidade sem medição convida a reação regulatória e de reputação.
Eficiência à custa da confiabilidade. Cortar de forma tão agressiva que os serviços falham sob carga troca uma pequena economia por um grande incidente.
Ignorar o carbono incorporado. Focar só na energia em execução enquanto se superprovisiona hardware ocioso deixa de fora a pegada de fabricação.
Portões burocráticos. Processos pesados de aprovação de gasto atrasam a entrega e empurram as equipes a contornar a governança.

Modelo de maturidade

Nível 1, Iniciar. Os custos de nuvem são uma surpresa na conta mensal. Não há etiquetagem, alocação nem consciência de carbono, e o provisionamento é generoso e raramente revisitado. O desperdício é invisível porque ninguém é dono dele, e qualquer limpeza que aconteça é reação a um choque de conta e não uma prática.

Nível 2, Desenvolver. Existem visibilidade básica de custo e etiquetagem, e alguma limpeza de recursos ociosos e de dimensionamento acontece, mas a cobertura e o rigor variam muito entre as equipes. Alguns grupos vigiam o gasto e tentam regiões de baixo carbono; outros não fazem nenhum dos dois. A sustentabilidade é reconhecida mas não medida, e os bons hábitos dependem da iniciativa individual e não de uma expectativa compartilhada.

Nível 3, Padronizar. Uma prática de FinOps é documentada e aplicada em toda a organização: as etiquetas são impostas, os custos compartilhados são alocados por um método combinado e orçamentos, previsões e alertas de anomalia são padrão. Os descontos por compromisso e o dimensionamento seguem um manual definido, e o carbono é medido para os serviços principais usando um método reconhecido como a especificação de Intensidade de Carbono do Software, com as escolhas de região e de agendamento consideradas de modo consistente e não caso a caso.

Nível 4, Gerenciar. Custo e carbono são medidos e controlados em relação a linhas de base. As equipes acompanham a economia unitária (custo e carbono por requisição, por cliente ou por caso), a utilização incluindo estimativas de ociosidade e de carbono incorporado, a cobertura de compromisso contra a carga-base e a exatidão das previsões, tudo reportado contra metas organizacionais. As anomalias disparam investigação, a eficiência e a aderência aos SLOs são revisadas juntas para que a otimização nunca corroa a confiabilidade em silêncio, e as decisões de ir ou não ir sobre provisionamento são tomadas com esses dados e não por intuição.

Nível 5, Orquestrar. Custo e carbono são sinais de engenharia contínuos e com dono, ligados à prática diária. Os padrões eficientes, o dimensionamento automatizado e o agendamento consciente de carbono são a norma, e a organização reequilibra continuamente seu patrimônio conforme a demanda, os preços e a intensidade da rede mudam. Custo, desempenho e confiabilidade são trocados deliberadamente por meio de SLOs, as métricas de sustentabilidade alimentam relatórios públicos e de investidores com métodos auditáveis e a prática se adapta conforme o negócio, o mercado e a regulação evoluem.

Ideias para discussão

Quem deve ser dono do custo de nuvem na sua organização: as finanças, uma equipe central de FinOps ou as equipes de engenharia que provisionam os recursos?
Como vocês atribuem de modo justo os custos de plataformas compartilhadas entre muitas equipes consumidoras?
Onde fica o equilíbrio certo entre a economia de custo e a confiabilidade ou o desempenho que vocês talvez sacrifiquem para obtê-la?
Como vocês mediriam a pegada de carbono dos seus serviços, e quanto vocês confiam nos dados disponíveis?
Quais das suas cargas são flexíveis o bastante para o agendamento consciente de carbono no tempo ou na região?
Como vocês definem metas de eficiência e de sustentabilidade que motivam as equipes sem encorajar o subprovisionamento arriscado?

Principais conclusões

A nuvem fez do custo e do carbono preocupações de engenharia. Visibilidade e propriedade são a fundação para controlar ambos.
O FinOps funciona em três fases: informar (visibilidade), otimizar (dimensionar e descontar) e operar (embutir na prática).
O software eficiente costuma economizar dinheiro e carbono juntos, então tratem-nos como uma iniciativa com duas lentes.
Reduzam o carbono por meio da eficiência energética, da maior utilização do hardware e do agendamento consciente de carbono no tempo e no lugar.
A arquitetura e o dimensionamento dominam o custo e o carbono de longo prazo. Projetem para a elasticidade e a escala a zero.
Equilibrem custo, desempenho e confiabilidade deliberadamente com SLOs e governem com guardrails e não com portões.

Referências e leitura complementar

J.R. Storment, Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
FinOps Foundation, FinOps Framework documentation
Green Software Foundation, Principles of Green Software Engineering and Software Carbon Intensity (SCI) Specification
Anne Currie, Sarah Hsu, Sara Bergman, Building Green Software
Adrian Cockcroft, writings on cloud efficiency and sustainability
The Shift Project, Lean ICT: Towards Digital Sobriety