Blog/Artigos · Cloud e Plataforma
O sidecar e os planos de dados e controle, mTLS, gestão de tráfego e observabilidade, com Istio e Linkerd, e a pergunta honesta de quando precisa.
Para o altar do Mishkan, a Torá manda fazer uma grade de bronze, obra de rede, uma malha entrelaçada que sustenta e distribui. A imagem serve com precisão à comunicação entre serviços na nuvem. Quando uma aplicação vira dezenas ou centenas de microsserviços, o problema deixa de ser cada serviço e passa a ser a rede entre eles: como eles se acham, se autenticam, tentam de novo quando falham, e como se enxerga o que trafega nessa teia. Service Mesh é a obra de rede que se tece sobre os serviços para resolver isso por fora do código de cada um. A malha carrega o que antes cada serviço tinha que carregar sozinho, e mal.
Quebrar uma aplicação em microsserviços resolve o acoplamento e cria um problema novo: a comunicação. Cada chamada entre serviços, que antes era uma chamada de função dentro do mesmo processo, vira uma chamada de rede, que pode falhar, demorar, ou nunca chegar. E cada serviço passa a precisar das mesmas capacidades transversais: tentar de novo quando a chamada falha, desistir depois de um tempo, criptografar o tráfego, e reportar o que aconteceu. Sem uma rede que resolva isso, cada time reimplementa essas capacidades no seu serviço, em cada linguagem, de forma inconsistente e cheia de bug.
Service Mesh tira essas preocupações do código da aplicação e as coloca na infraestrutura de rede. O desenvolvedor volta a escrever a lógica de negócio, e a malha cuida de que a chamada seja criptografada, tentada de novo, cronometrada e observada, por igual, para todos os serviços, sem uma linha de código de infraestrutura na aplicação. É a mesma filosofia da plataforma, aplicada à comunicação: o difícil e repetitivo, resolvido uma vez, por fora, e herdado por todos. A rede de bronze sustenta o que cada serviço, sozinho, sustentaria mal.
O desenvolvedor volta a escrever a lógica de negócio; a malha cuida do transversal por igual para todos, sem uma linha de infraestrutura na aplicação.
A malha é feita de duas partes. O plano de dados é onde o tráfego de fato passa: ao lado de cada serviço roda um proxy, o sidecar, tipicamente o Envoy, que intercepta toda a comunicação de entrada e saída daquele serviço. O serviço acha que fala direto com o destino; na verdade, fala com o seu sidecar, que aplica as regras, criptografa, tenta de novo, mede, e só então encaminha. Como o sidecar está no caminho de toda chamada, ele pode fazer tudo isso sem que o código do serviço saiba que ele existe.
O plano de controle é o cérebro que configura todos os sidecars. É nele que você declara a política, roteie dez por cento do tráfego para a versão nova, exija mTLS neste namespace, aplique este timeout, e ele distribui essa configuração para os proxies do plano de dados. A separação é a mesma elegância declarativa do Kubernetes: você declara a intenção no plano de controle, e o plano de dados a realiza em cada chamada. Essa arquitetura é o que permite mudar o comportamento da rede inteira, de retry a criptografia, por configuração central, sem tocar em nenhum serviço nem fazer nenhum deploy de aplicação.
A malha entrega três famílias de capacidade. Gestão de tráfego: roteamento fino que sustenta o canary e o blue-green do progressive delivery, dividindo o tráfego por percentual ou por cabeçalho, além de retry, timeout e circuit breaking, que impede uma falha de se espalhar cortando a chamada para um serviço já doente. Segurança: mTLS automático entre todos os serviços, dando criptografia e autenticação mútua sem o desenvolvedor configurar certificado, o que materializa o Zero Trust dentro do cluster, onde nenhum serviço confia em outro só por estar na mesma rede.
E observabilidade: como o sidecar vê toda chamada, a malha gera automaticamente as métricas de ouro, latência, tráfego, erro e saturação, para cada serviço e cada conexão, sem instrumentar o código. Ela desenha o mapa real de quem fala com quem, aquele mesmo mapa de dependência que a migração precisava, agora vivo e atualizado a cada chamada. Essas três capacidades, juntas, são o que justifica a malha: elas transformam a teia caótica de microsserviços numa rede governada, segura e visível, sem espalhar essa responsabilidade por dentro de cada serviço.
Service Mesh é poderosa e cara em complexidade, e fingir o contrário custa caro. O sidecar em cada pod consome CPU e memória e adiciona um salto de rede a cada chamada, o que soma latência. O plano de controle é mais uma peça crítica para operar, atualizar e depurar. E quando algo dá errado na rede, agora há uma camada a mais entre o serviço e o problema, o que pode transformar depuração em arqueologia. Muitos times adotaram Istio pela fama e afogaram-se na operação de algo que não precisavam, para rodar poucos serviços que não exigiam nada daquilo.
A pergunta madura é a mesma do Kubernetes: preciso mesmo? Poucos serviços, com pouca comunicação entre si, não justificam uma malha; uma biblioteca de resiliência e TLS na borda resolvem com uma fração do custo. A malha rende quando há muitos serviços, muita comunicação entre eles, e necessidade real de mTLS universal, roteamento fino ou observabilidade sem instrumentar. Quando ela é a escolha certa, o Linkerd tende a ser mais leve e simples que o Istio, que é mais completo e mais complexo, e a evolução do mercado com o ambient mesh e o eBPF promete reduzir o custo do sidecar, tornando a malha mais barata de carregar. Mas a decisão de adotá-la continua sendo sobre escala e necessidade, não sobre moda.
A malha amadurece do transversal espalhado à rede governada e leve. No começo, cada serviço reimplementa retry, TLS e observabilidade, mal e diferente. Depois vem a malha adotada, com sidecar e mTLS. No meio ela sustenta o roteamento do progressive delivery e dá o mapa de dependência vivo. No topo é a malha com a evolução do ambient mesh, custo de sidecar reduzido, política coerente e observabilidade que vira detecção. Cada degrau tira mais um pedaço de infraestrutura de dentro do código e o resolve por fora, por igual.
A malha se apoia no Kubernetes, que dá o chão onde os sidecars vivem, e serve a vários vizinhos deste eixo: dá ao progressive delivery o roteamento fino do canary, ao Zero Trust o mTLS entre serviços, à observabilidade as métricas de ouro sem instrumentar. Ela é a obra de rede que entrelaça a comunicação da arquitetura de microsserviços. Saber tecê-la é útil; saber quando não precisar de malha alguma é o que separa quem adota por moda de quem adota por necessidade. A rede de bronze sustenta o altar, mas nem todo altar precisa de uma rede de bronze.
Service Mesh é a obra de rede que se tece sobre os microsserviços para resolver por fora o transversal que cada um sustentaria mal: mTLS, retry, timeout e observabilidade. O sidecar no plano de dados intercepta toda chamada, o plano de controle a governa por configuração central, e as três famílias, tráfego, segurança e visão, transformam a teia caótica em rede governada. Mas o poder vem com complexidade e latência reais, e a pergunta honesta é se a escala justifica a malha ou se o mais simples resolve. A IA mostra o valor e valida a política. Decidir tecer ou não a rede de bronze, porém, continua sendo arquitetura de quem responde pela comunicação do sistema.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaחוֹבֵל
Kubernetes é grego para timoneiro, e é isso que ele faz: você declara o estado desejado e ele conduz a frota de contêineres até lá, corrigindo sozinho o que sai da rota. O poder é real, e a complexidade também, e a maturidade começa em saber quando não içar essa vela.
Segurançaלַלֵּבָב
A rede interna parou de ser segura no dia em que o dado saiu dela. Zero Trust troca a confiança por endereço pela verificação de cada requisição, com o modelo do NIST e a experiência do BeyondCorp.
