Os codificadores terão que se tornar políticos se a indústria não começar a levar o software verde a sério.

O setor de Data Centers está fortemente focado na redução de emissões, mudando para energia renovável e também redesenhando as instalações para que os sistemas de resfriamento usem menos energia. Mas o que acontece com a energia que chega aos racks de servidores raramente é examinado.

Apesar disso, todos sabem que os servidores não são usados de forma eficiente. Muitos servidores ociosos continuam em execução e executam código em segundo plano que não é necessário. Os programas não são escritos de forma eficiente: giram e giram em torno de conjuntos repetidos de instruções, disparam recursos de nuvem que ficam ociosos, fornecem recursos que não são necessários e diferentes módulos realizarão handshakes excessivamente complexos, dentro de sistemas ou redes.

O software verde pode reduzir maciçamente as emissões operando com mais eficiência. Também tem o potencial de melhorar drasticamente a eficiência da instalação, melhorando interativamente a operação de todo o sistema.

O software “autoconsciente” ou “consciente da energia” pode até alterar suas próprias operações. Ao se referir a números em tempo real para o uso de energia e a intensidade de carbono do fornecimento de eletricidade, os programas podem interromper sua própria operação e mudar para servidores mais eficientes ou para horários e locais onde a eletricidade é menos intensa em carbono.

Apesar disso, o software verde ainda é negligenciado.

Como as revoluções verdes anteriores, o software verde está sendo inicialmente descartado como impraticável e contrário às realidades econômicas. Mas os codificadores verdes podem ver o potencial. Em uma reunião em Berlim em novembro de 2024, convocada pela Aliança Digital Sustentável (SDIA), eles pediram transparência, regulamentações e ação.

Max Schulze, fundador da SDIA, disse aos programadores que cabe a eles: “Somos nós que esperávamos”, disse ele. “Gostaria de pedir que você entenda o que você pode fazer para se conectar com as pessoas para experimentá-lo e ver o que você pode fazer”.

Impacto

Qual é o impacto do software? “Há um efeito de escala”, disse Schulze. “Se você tem um aplicativo da web com 10.000 usuários ativos, esses 10.000 usuários ativos podem gerar centenas de milhares de chamadas de função. Essas chamadas usam energia. Eles precisam de capacidade de servidor, precisam de capacidade de armazenamento. Acho que todos nós sabemos que há um custo ambiental”.

Há mais, disse ele: “Pense nos sistemas de backup, nos sistemas de monitoramento, no registro, em todas essas coisas que estão acontecendo para a maioria dos aplicativos”.

O problema do software é que um programa escrito por uma pessoa e uma equipe terá um impacto maior dependendo de quanto for usado - e a economia de energia também aumentará.

Há cerca de um ano, o engenheiro de produto da SAP, Detlef Thoms, fez um cálculo aproximado que mostrou que economizar um segundo de CPU em uma transação economizará apenas 10 Joules (10 watts-segundos). Essa é uma pequena economia, mas se 1,5 milhão de pessoas estiverem usando o software e houver 20 transações por dia durante 230 dias úteis, isso representa uma economia de 19 MWh ao longo do ano.

Os desenvolvedores de software podem se sentir impotentes para mudar isso e melhorá-lo, porque estão sob pressão para entregar software rapidamente e não para terminá-lo adequadamente e torná-lo eficiente.

O software mata o hardware

Além de seu impacto direto, o software está aumentando o fluxo físico de lixo eletrônico, disse Anna Zagorski, pesquisadora associada em TI Verde da Agência Ambiental Alemã (UBA).

“Software ruim leva à morte do hardware”, disse ela na reunião da SDIA em Berlim, referindo-se à maneira como novas versões de software podem tornar o hardware mais antigo obsoleto. Versões mais antigas do software ainda podem funcionar, mas, sem suporte, tornam-se “abandonware”. O hardware em que eles são executados não oferece suporte a versões mais recentes e é descartado.

Os dispositivos eletrônicos são a categoria de lixo que mais cresce, e a comunidade de código aberto do KDE coloca a culpa por esse “tsunami de lixo eletrônico” no software: “Qual é a causa de todo esse lixo eletrônico e por que os dispositivos digitais que ainda funcionam acabam em aterros sanitários? A engenharia de software tem um papel importante, mas muitas vezes invisível, na condução de nossos padrões de consumo digital. Os fabricantes incentivam regularmente os consumidores a comprar novos dispositivos, muitas vezes desnecessariamente; na verdade, eles podem até aplicá-lo por meio do design de software”.

O KDE usa o único exemplo dos e-readers, nos quais as pessoas consomem livros. Ele estima que o carbono, a energia e os materiais incorporados em um e-reader serão aproximadamente equivalentes a trinta livros.

Se você ler trinta livros em seu e-reader, você empatou ambientalmente, e cada livro adicional é um ganho para o meio ambiente (assim como para sua mente). Mas as listas publicadas mostram que os modelos de e-reader são descontinuados em cerca de 1,5 anos, após os quais o software não é mais suportado. Leitores vorazes chegarão a 30 livros nesse período, talvez, mas perderão a vantagem ambiental do uso contínuo, porque terão que jogar o dispositivo fora (talvez para aterros sanitários, talvez para reciclagem).

Mesmo no uso rotineiro, um software ruim desperdiça energia. O KDE compara um processador de texto de código aberto com um comercial (ambos sem nome) e observa que o produto proprietário usa quatro vezes mais energia para executar uma única tarefa de benchmark. Ele usava mais energia na operação, por causa de todos os recursos extras de bloatware adicionados, e continuava usando energia para fins desconhecidos após o término do trabalho.

Para software executado em servidores e na nuvem, espera-se que o hipervisor subjacente e outros softwares de sistemas sejam otimizados, pois são comissionados e executados pelo fornecedor de nuvem que paga pelo hardware.

Nos primórdios da computação, os programadores costumavam codificar com moderação porque os recursos eram escassos, mas agora a generosa infraestrutura de software os estragou. Os recursos são fáceis de obter - e, portanto, muito fáceis de desperdiçar, disse Atanas Atanasov, engenheiro de software sênior da Intel: “Quando comecei, pedia um servidor e tinha que esperar que ele fosse entregue. Alguns anos depois, se eu quisesse um servidor, levaria duas ou três semanas para configurar a máquina virtual. Hoje em dia, peço um servidor e, se demorar mais de três minutos, escolho outro fornecedor, porque é muito lento”.

O software de aplicativo em execução nessas instâncias de servidor descartáveis geralmente não será otimizado. De fato, a falta de otimização nesse nível funciona a favor do fornecedor de nuvem, pois garante que mais recursos cobráveis sejam consumidos.

Por que a programação é ineficiente?

As empresas não fazem software inchado deliberadamente.

Programadores com memória longa dizem que costumava ser diferente, disse uma especialista: “Tenho idade suficiente para lembrar quando codificamos de uma maneira diferente. A largura de banda era limitada, a conectividade não era realmente confiável, a memória era pequena e assim por diante”.

Ela continuou: “Acho que ainda temos esse conhecimento. Talvez pudéssemos voltar, ajudados por idosos como eu”.

Janne Kalliola, fundador da empresa de software finlandesa Exove, concordou que os desenvolvedores poderiam se beneficiar de “voltar aos bons e velhos anos 80, quando comecei a codificar”.

Quando ele notou o declínio, pensou a princípio “Vou fazer barulho sobre isso”. Mas não obteve resposta e decidiu: “Preciso ser um agente de mudança”. Kalliola lançou o Green Code, um livro gratuito sobre o assunto.

A Exove, juntamente com outras empresas de software do grupo Code from Finland, criou um rótulo de “Software Neutro em Carbono”, baseado mais nas emissões de toda a empresa do que nas minúcias da codificação, o que talvez seja uma admissão da dificuldade de mudar essas práticas.

O problema subjacente que leva a um software ruim é que custa tempo e dinheiro para fazê-lo bem. Os programas demoram mais para codificar com eficiência. Esses programas são produtos comerciais lucrativos, portanto, atrasar um produto para torná-lo melhor aumentará o custo. Isso pode levar outra organização a chegar primeiro ao mercado.

“A indústria passou os últimos 20 anos focando na produtividade do desenvolvimento”, disse Max Körbächer, que fundou a consultoria de código aberto Liquid Reply. Isso não deixa tempo para considerar a eficiência operacional.

“Há um certo aspecto de preguiça na indústria”, disse ele, mas é o outro lado de uma indústria que quer que o desenvolvedor entregue mais rápido. “Toda a indústria está sempre desejando a próxima coisa, e todo desenvolvedor odeia o vendedor que vende a próxima versão do produto e não a atual”.

Isso leva à “codificação Frankenstein”, na qual rotinas que funcionam são montadas para construir um produto, sem considerar se funcionarão bem juntas e se todos os elementos de cada componente são realmente necessários no novo produto.

Para ajudar com isso, Körbächer criou um recurso para ajudar aqueles que fazem software de código aberto. Ele oferece ferramentas para medir a pegada de seus lançamentos, “somos nós que damos conselhos”, disse ele. “Para ver como eles se saem e, principalmente, como podem melhorar”.

Os defensores do software verde deixam claro que, como acontece com outros produtos ambientais, a única maneira de forçar uma atitude melhor é expor a pegada ambiental de um produto e esperar criar uma pressão comercial em direção à eficiência. Tal como acontece com carros e geladeiras, os clientes precisam ver o impacto do que usam.

Schulze disse: “Para que exista um software eficiente em termos de recursos, é necessário que haja um mercado para ele. Isso significa que deve haver transparência, com cada aplicativo tendo que mostrar seu impacto ambiental de forma muito transparente para os usuários”.

O uso de software mais ecológico pode ser reforçado se os órgãos do setor público liderarem suas aquisições, disse Zagorski: “O software sustentável deve entrar nas diretrizes para as estratégias de compras públicas”.

Schulze concordou: “O mercado pode ser reforçado com compras públicas. Pode ser reforçado com regulamentação. Mas acreditamos que é preciso haver no mercado um software eficiente em termos de recursos”.

Padrões

O problema é que você só pode ter esse mercado se puder ver a eficiência do seu software. Os defensores do software verde foram muito claros que o maior problema com o software ecológico é a falta de visibilidade.

“A transparência é um grande problema. Nós realmente não temos números muito bons sobre os custos ambientais do software”, disse Schulze.

“Precisamos obter informações muito mais precisas sobre o design do software”, disse Zagorski.

E isso precisa de padrões, sobre como medir e relatar a pegada do software.

A Alemanha pode muito bem ser a líder aqui, com projetos para ajudar a tornar o software mais ecológico e um esquema de rotulagem projetado para fornecer informações sobre o impacto do código.

A UBA tem trabalhado no SoftAWERE, um projeto financiado pelo Ministério Federal Alemão de Assuntos Econômicos e Ação Climática (BMWK) para desenvolver ferramentas que ajudariam os desenvolvedores de software a produzir software com eficiência energética e economia de hardware.

A SoftAWERE também pesquisou a ideia de rotular software com eficiência energética - e tornar o software transparente sobre a energia que está consumindo.

Zagorski, que trabalhou no projeto, apresentou suas conclusões finais ao evento SDIA. Ela disse que, embora o projeto SoftAWERE possa estar concluído, o trabalho continuará. Os próximos passos serão tornar as ferramentas mais “produzidas” e utilizáveis por outros.

A equipe da SoftAWERE lançou um Wiki de Codificação Verde no evento SDIA, para compartilhar e melhorar as melhores práticas.

Mas, paralelamente ao SoftAWERE, o governo alemão já está apoiando um esquema para reconhecer programas de ecoeficiência. O software está incluído no programa de rótulos Blue Angel do governo para produtos ecologicamente corretos.

Vale a pena mencionar que o Blue Angel não foi o primeiro programa a considerar a pegada ambiental do software. O Conselho Verde de Hong Kong divulgou alguns critérios para software verde em 2010, que incluíam coisas como ter manuais online em vez de impressos e usar o mínimo de embalagens em entregas físicas.

Na Alemanha, o esquema Blue Angel adicionou certificação para produtos de software de desktop em 2020, a primeira vez no mundo que uma certificação de rótulo ecológico foi aplicada a software. A Blue Angel possui rótulos “Tipo 1”, que consideram a pegada ambiental de um produto durante toda a vida.

O programa Blue Angel argumenta que o software tem um enorme impacto ambiental além dos sistemas em que é executado, em tudo, desde programas de desktop até Data Centers. O programa concede certificados com base na eficiência com que o código opera - portanto, exige que o software permita que o uso de energia seja medido e relatado. O software também deve dar autonomia aos usuários para reduzir manualmente o impacto do software. Finalmente, ele deve ter uma demanda baixa o suficiente para poder ser executado em hardware com cinco anos.

“É o software que determina o consumo de energia e a vida útil da infraestrutura digital”, disse um livro sobre conformidade de software Blue Angel do KDE - que foi uma das primeiras organizações cujo software ganhou o selo Blue Angel.

“O Blue Angel realmente define como é o software verde”, disse Schulze. “Você pode olhar para isso como o Santo Graal”.

Além do software, a Blue Angel está analisando questões maiores de infraestrutura, incluindo Data Centers verdes, onde o software verde pode eventualmente residir.

Desenvolvimento de software

Qualquer pessoa que tenha trabalhado em software sabe que os principais aspectos do produto final são gravados em pedra antes que uma única linha de código seja escrita ou colada. Os requisitos para o projeto exigirão características específicas e exigirão certas características e desempenho.

Schulze disse que as práticas verdes precisam ser incorporadas desde o início. “Entre as disciplinas que precisamos aprender, a primeira é a engenharia de requisitos verdes”, disse ele. “Antes de construirmos software, devemos pensar 'realmente precisamos construí-lo? Podemos de alguma forma minimizar os recursos que ele usa?'”.

Além disso, a programação deve funcionar de maneira eficiente em termos de recursos. Embora os desenvolvedores gastem tempo certificando-se de que seus aplicativos tenham memória e recursos suficientes para serem executados, eles também devem procurar limitar essas demandas.

E, finalmente, aqueles que executam o software terão que trabalhar de uma maneira que use recursos em Data Centers com moderação.

Atanasov, da Intel, sugeriu que as limitações de recursos podem ser impostas em um projeto durante o desenvolvimento e a implantação, em algo como o Kubernetes, mas não é simples, porque não temos sistemas que possam identificar automaticamente quais recursos são necessários em um aplicativo específico em um determinado momento.

“Esses sistemas estão sendo desenvolvidos na comunidade de código aberto, para fornecer limitações de recursos”, disse ele. Mas eles terão que ser capazes de processar solicitações de recursos e colocá-las no hardware certo, para utilizar melhor os recursos.

Para ajudar os desenvolvedores a escolher a opção mais ecológica ao desenvolver código, Atanasov é a favor de esquemas que possam classificar ferramentas e sub-rotinas de acordo com sua pegada de carbono relativa. “Como quando você compra uma geladeira”.

Pode haver problemas com isso, disse Schulze: “Nenhum aplicativo de software é o mesmo. Diferenciamos o software por meio de recursos. Começamos com um problema muito específico que estamos resolvendo com software e, em seguida, colocamos mais recursos ao longo do tempo. E isso torna quase impossível comparar”.

Além disso, a longo prazo, os criadores de software ecológico querem ter um software que seja autoconsciente e conheça a pegada de carbono dos servidores em que está sendo executado. Isso é um problema, porque existem muitas camadas no software, e sua localização real pode não ser clara, e o próprio servidor pode não ter conhecimento direto de sua pegada.

“É um problema de engenharia interessante”, disse Schulze, mas ele diz que os resultados úteis não precisam ser 100% precisos. “Testamos matematicamente se podemos chegar ao consumo de energia de uma CPU apenas usando matemática pura. Acontece que podemos. Não é muito preciso ou muito bom. Mas é bom o suficiente. E um modelo de aprendizado de máquina pode fornecer uma estimativa ainda mais precisa do consumo de energia. No momento, se pudermos obter um valor preciso de 60 a 70%, isso é melhor do que não obter nenhum valor”.

Problema de imagem

Os pioneiros do software verde podem achar difícil transmitir suas ideias ou fazer as mudanças que desejam.

Anita Schüttler, estrategista de sustentabilidade da empresa de software Neuland, disse que os problemas às vezes são escondidos pelas muitas camadas de software entre o usuário e o hardware que usa recursos. “É como o problema com as redes de suprimentos globais. As coisas ruins estão acontecendo em algum lugar distante, onde ninguém pode ver. O software é visto como algo limpo porque ninguém vê o que está acontecendo lá”.

O problema, disse ela, é a educação: “Os programadores reais não sabem disso”.

Outra questão é a enorme complexidade do que está sendo feito. Atanasov disse que o campo da computação de alto desempenho está ciente da eficiência, mas nem sempre tem espaço para isso: “A quantidade de complexidade com a qual um desenvolvedor de software regular tem que lidar tira toda a capacidade de se concentrar em qualquer outra coisa”.

Mesmo que um programador queira fazer um código mais verde, ele precisa cuidar de muitas outras coisas primeiro, disse Atanasov. “O conhecimento é sempre um problema. Este campo tem pesquisa e novas ferramentas e produtos chegando ao mercado, você tem que otimizar o software e a infraestrutura. Muita informação pode confundir as pessoas”.

Os projetos de software também têm complexidade organizacional: “Não importa o quão automatizados sejam os processos, em um projeto como o Kubernetes temos milhares de colaboradores. O software é testado todos os dias, 7.000 vezes por commit. Existem centenas de clusters executando programas simultaneamente e tudo está ligado. Ninguém vê tudo”.

Nas grandes empresas, há mudanças que prometem tornar as coisas mais simples, como o DevOps, disse ele, mas uma evolução contínua das práticas de desenvolvimento de software pode espremer a sustentabilidade, disse Atanasov: “As empresas lutam com a conteinerização e outras novas tecnologias e tendências. Tenho certeza de que a maioria dos líderes de equipe hoje em dia não pensa em sustentabilidade”.

A conscientização pode ajudar porque as práticas de software verde geralmente economizam dinheiro e carbono, ressalta Körbächer. Se os desenvolvedores estiverem cientes de todos os custos de gerar recursos extras sem pensar, eles poderão reduzir as contas e o carbono: “Acho que conscientizá-los é a parte importante”.

Tendências futuras

Algumas coisas podem acontecer para colocar o software verde em primeiro plano, de acordo com alguns dos participantes da SDIA.

Körbächer acha que uma das principais fontes do problema que temos agora é que “a eletricidade é muito barata”.

Se os ciclos desperdiçados custassem mais, os desenvolvedores os evitariam - e é possível que isso se torne mais um fator no futuro.

Outro fator é que os recursos físicos para fazer chips podem se tornar mais restritos, disse ele. “Há estimativas de que haverá falta de silício em alguns anos” (presumivelmente não se referindo especificamente ao silício, abundante em toda a Terra, mas a todos os elementos necessários para fazer processadores).

“Isso seria interessante: isso realmente muda a dinâmica”.

Alguns codificadores apontam que eles são apenas uma parte do quadro. Kalliola, da Exove, disse que os desenvolvedores individuais são galhos e galhos de uma árvore, mas: “A maior parte da árvore é o tronco. Não temos nenhuma influência”.

Schüttler também analisa o quadro geral: “Para se tornar sustentável, você precisa de energia verde e eficiência, mas também precisa de suficiência”, disse Schüttler. “Temos que fazer menos e estamos vivendo em um sistema que promove a geração de dinheiro”.

Ela se sente desconfortável com as emissões que seu software permite - algo semelhante às emissões de Escopo 3: “No final, você tem conflitos porque outra pessoa lhe diz qual software escrever”.

“Como programadores, podemos tornar o software um pouco menos ruim, mas ainda não é bom. Porque o que o software faz? Vende produtos”.

Tornar o software mais eficiente pode resultar em mais uso e venda de mais coisas, disse ela, a menos que haja alguma maneira de estabelecer limites rígidos: “Na verdade, sou bastante pessimista sobre tudo isso porque, no final, qualquer economia será gasta”.

Para alguns, a única maneira de definir esses limites serão regimes semelhantes a impostos, como precificação de carbono e impostos sobre energia. “Se cada foto que você tira custa 75 reais, você tira menos fotos”, disse Kalliola. Da mesma forma, se os custos de energia subirem, as pessoas usarão menos: “O fiscal é o mocinho”.

Schulze é mais otimista. Ele esperava que a infraestrutura pudesse ser compreendida e legislada em todo o contexto da sociedade que a utiliza, e quer ver um crescimento da “sobriedade digital”, e a ideia de usar recursos suficientes, não muito.

“Espero que nos próximos dois anos possamos incluir o aspecto social e os aspectos econômicos”, disse Schulze.

“Não é apenas ambientalismo. O software verde é um passo em direção ao software sustentável”.