Google Axion e Kubernetes: Como o Arm virou política de execução e mudou a escolha de hardware na nuvem

A conversa sobre infraestrutura em Kubernetes costuma começar no hardware e terminar no software. Mas, no caso do Google Axion, a Google Cloud está tentando mudar essa ordem: em vez de tratar Arm como uma migração trabalhosa de x86, a empresa quer que a escolha entre arquiteturas pareça apenas uma decisão de agendamento dentro do GKE.

Esse reposicionamento é mais importante do que parece. Se Arm deixa de ser uma “troca de plataforma” e passa a ser uma opção declarativa no Kubernetes, a barreira de adoção cai drasticamente. O foco sai de reescrever arquitetura e entra em variáveis muito mais pragmáticas: custo, eficiência energética, disponibilidade de capacidade e facilidade de operação.

No KubeCon Europe, executivos da Google Cloud reforçaram essa narrativa ao destacar que, depois de cerca de um ano em produção, o Axion — a CPU Arm customizada da companhia — está sendo tratado menos como uma aposta isolada em hardware e mais como uma opção operacional nativa do GKE. A mensagem é clara: o chip importa, mas o que realmente escala é a experiência de orquestração.

Na prática, isso acontece porque a Google está amarrando a adoção de Arm a recursos já familiares para equipes de plataforma: imagens multi-arch, node selectors, compute classes e até fallback automático entre diferentes tipos de VM. Em outras palavras, o cluster pode decidir onde executar a carga com base em preferências declarativas, sem exigir uma reengenharia da aplicação inteira.

De migração de arquitetura para decisão de agendamento

Durante anos, a principal objeção a Arm em ambientes corporativos foi a mesma: “isso vai quebrar minha aplicação?”. Em muitos casos, a resposta era “depende”. Bibliotecas nativas, binários fechados, dependências de baixo nível e diferenças sutis de comportamento impediam movimentos rápidos. O que a Google está propondo agora é um enquadramento diferente: em vez de pensar em uma migração “big bang”, pense em seleção de nós.

Esse é um ponto decisivo para o mercado de cloud. Quando a unidade de decisão muda do sistema inteiro para o scheduler, a adoção deixa de exigir coragem de transformação e passa a exigir maturidade operacional. E maturidade operacional é algo que times de plataforma já têm como evoluir gradualmente.

O caminho sugerido é bem mais realista:

• recompilar imagens para suportar múltiplas arquiteturas;
• usar node selectors ou afinidade para direcionar parte da carga;
• adotar compute classes para expressar preferências de execução;
• aplicar canary releases pequenos, como 5% ou 10% do tráfego;
• expandir conforme métricas de estabilidade, custo e performance confirmarem a hipótese.

Esse modelo reduz o atrito de entrada e transforma Arm em uma opção muito mais parecida com uma política de infraestrutura do que com uma migração traumática.

O papel estratégico das compute classes

Entre todos os elementos citados pela Google, as compute classes talvez sejam o mais estratégico. Elas permitem definir uma ordem de preferência entre perfis de máquina — por exemplo, priorizar Axion, depois x86 e, em seguida, capacidade spot ou alternativas de fallback. Isso muda o jogo porque o operador passa a declarar intenção, e não um destino fixo.

Na prática, isso significa que um workload pode dizer: “se houver Axion, prefira Axion; se não houver, use x86; se a prioridade for custo, considere spot”. O scheduler e a infraestrutura cuidam do resto. Esse tipo de abstração ajuda a dissolver o debate rígido entre arquiteturas e coloca o foco no resultado operacional.

Para equipes que rodam grandes ambientes em GKE, a consequência é direta: o cluster pode se adaptar melhor a restrições de custo, disponibilidade e eficiência. E quando o fallback automático entra na equação, a adoção fica menos dependente de uma aposta única em um tipo de VM.

Por que isso importa para workloads em contêineres

O recado da Google faz sentido especialmente para workloads containerizados. Contêineres já têm como princípio isolar dependências e padronizar execução. Se a aplicação consegue ser empacotada de forma multi-arch, a arquitetura subjacente perde parte da sua rigidez histórica. É justamente aí que Arm ganha terreno.

Em vez de migrar toda a plataforma, a equipe pode:

• gerar imagens compatíveis com Arm e x86;
• fazer testes comparativos entre grupos menores;
• medir custo por requisição, latência e consumo;
• expandir a adoção apenas onde o ganho estiver claro.

Esse modelo é poderoso porque respeita a realidade de ambientes modernos: raramente existe um “tudo ou nada”. O mais comum é a convivência entre múltiplos perfis de carga, cada um com exigências diferentes.

O argumento econômico: eficiência, custo e energia

O que realmente sustenta a tese da Google é a camada econômica. A empresa posiciona o Axion como uma opção com melhor relação entre preço, performance e eficiência energética para workloads gerais em GKE. Isso conversa diretamente com uma tendência maior do mercado: a energia está virando um dos principais limitadores da expansão de infraestrutura, especialmente em cenários de IA.

Daí vem a lógica de “tokens per watt”, uma métrica que começa a ganhar espaço como forma de avaliar não só performance bruta, mas eficiência operacional real. Em um mundo em que o custo energético pesa cada vez mais sobre decisões de compra, o debate deixa de ser apenas “qual CPU é mais rápida?” e passa a ser “qual entrega mais trabalho útil por watt consumido?”.

Esse é um deslocamento importante. Se a conta passa a ser energética, a disputa com x86 muda de natureza: não basta benchmark bruto. É preciso provar eficiência, elasticidade e disponibilidade de capacidade em escala.

O que muda para times de engenharia e plataforma

Na visão operacional, a proposta da Google reduz a complexidade percebida, mas não elimina a necessidade de disciplina técnica. Há um conjunto de cuidados que continuam indispensáveis:

• compatibilidade multi-arch precisa ser validada de verdade, não presumida;
• canary releases continuam sendo a forma mais segura de ampliar adoção;
• monitoramento deve cobrir latência, consumo, erros e variações de comportamento;
• dependências nativas ainda podem travar a portabilidade em alguns casos;
• binários sensíveis a arquitetura exigem teste específico antes de produção ampla.

Ou seja: a promessa é de redução de atrito, não de ausência de engenharia. O benefício real está em tornar a operação mais flexível, menos reativa e mais orientada a política.

Os limites técnicos que ainda importam

Apesar do discurso otimista, existem limites importantes. Nem todo workload funciona da mesma forma em Arm e x86. Diferenças em ponto flutuante, variações em desempenho de baixo nível e comportamentos muito específicos de determinadas bibliotecas podem exigir validações cuidadosas.

Além disso, a tese depende de um ecossistema maduro. Para funcionar de ponta a ponta, o ambiente precisa de:

• imagens de container preparadas para múltiplas arquiteturas;
• automação confiável de build e deploy;
• políticas claras de scheduling;
• observabilidade para comparar resultados por arquitetura;
• processos de rollback bem definidos.

Sem isso, a promessa de “troca simples de agendamento” pode se transformar em apenas mais uma camada de complexidade operacional. A diferença está menos no chip e mais na maturidade do pipeline.

O mercado está comprando uma nova narrativa

Do ponto de vista competitivo, a Google está fazendo algo inteligente: em vez de vender apenas um processador, está vendendo um modelo de adoção. Isso é especialmente relevante em cloud, onde a experiência de uso importa tanto quanto a especificação técnica.

Se Axion conseguir se consolidar como a escolha “natural” para workloads gerais no GKE, o debate deixa de ser centrado no hardware em si e passa a girar em torno de experiência operacional. Nessa lógica, a competição com x86 não é mais só sobre performance de pico; é sobre custo total, eficiência, elasticidade e facilidade de decisão dentro do ecossistema Kubernetes.

Esse framing também ajuda a explicar por que a Google insiste tanto no aspecto declarativo. Quanto mais a escolha de infraestrutura puder ser automatizada e codificada, menor é o custo cognitivo para os times e maior é a chance de adoção contínua.

Conclusão

O que a Google está tentando fazer com o Axion é mais ambicioso do que lançar uma CPU Arm customizada. A empresa quer mudar o jeito como o mercado pensa Arm dentro do Kubernetes: de uma migração delicada para uma preferência operacional de agendamento.

Se essa visão ganhar força, a decisão deixa de ser “vamos portar ou não vamos portar” e passa a ser “qual perfil de máquina faz mais sentido para este workload agora?”. É uma transformação sutil, mas poderosa. Ela reduz o atrito, amplia o espaço para experimentação e desloca a conversa para o que realmente interessa em cloud moderna: custo, eficiência e resiliência.

No fundo, o recado da Google é simples: o próximo gargalo não será apenas CPU. Será watt. E, no mundo do Kubernetes, quem consegue declarar melhor suas preferências de execução tende a ter vantagem.