3.16 Gateways de API e malha de serviços

Visão geral e motivação

No momento em que vocês dividem um programa em muitos serviços, surge uma pergunta nova: quem manda no tráfego entre eles e no tráfego que chega de fora? Dá para responder mal a essa pergunta, espalhando à mão as mesmas preocupações (autenticação, novas tentativas, tempos limite, limites de taxa, registro) por cada serviço, ou dá para responder bem, empurrando essas preocupações para uma camada compartilhada que todo serviço herda de graça. Este capítulo trata de duas camadas assim. Um gateway de API fica na porta da frente e gerencia o tráfego que chega dos clientes. Uma malha de serviços (service mesh) fica entre os seus serviços e gerencia o tráfego que flui entre eles. Resolvem problemas relacionados em lugares diferentes, e confundir os dois é um erro comum e caro.

O setor nomeia as duas direções do tráfego com uma metáfora de bússola. O tráfego norte-sul é o que cruza a fronteira do seu sistema: um aplicativo móvel, um navegador ou um parceiro chamando de fora. O tráfego leste-oeste é o que fica dentro do seu sistema: o serviço A chamando o serviço B chamando o serviço C para atender uma requisição. Um gateway de API é o especialista em norte-sul. Uma malha de serviços é o especialista em leste-oeste. Manter essa distinção nítida é a ideia mais útil deste capítulo, porque ela diz qual ferramenta é dona de qual política e evita que vocês façam duas vezes o mesmo trabalho.

Para grandes equipes, essas camadas são como se impõe uma política uma vez em vez de cem. Quando a autenticação, a criptografia em trânsito e a limitação de taxa vivem numa camada compartilhada, uma correção de segurança chega a todo serviço no dia em que vocês implantam a camada, em vez de esperar em cem backlogs. Em contextos corporativos e governamentais, essa centralização muitas vezes é o objetivo: os auditores querem um único lugar comprovável onde o acesso é verificado e o tráfego é criptografado, e um gateway ou malha compartilhado dá a eles exatamente esse ponto de imposição de política. Este capítulo se apoia nos estilos arquiteturais do capítulo 3.2, nas realidades de sistemas distribuídos do capítulo 3.3 e nos fundamentos de rede do capítulo 3.13, e os transforma em orientação concreta sobre quem trata o seu tráfego.

Princípios fundamentais

Separem o norte-sul (gateway) do leste-oeste (malha). Deixem cada um ser dono da sua direção.
Empurrem as preocupações transversais para uma camada compartilhada, para escrevê-las uma vez e não por serviço.
Adotem uma malha de serviços apenas quando o número de serviços fizer da fiação por serviço o custo maior.
Definam um ponto de imposição de política por preocupação. Nunca deixem o gateway e a malha fazerem o mesmo trabalho.
Mantenham os serviços finos: a plataforma trata o transporte, o serviço trata a lógica de negócio.
Prefiram redes de confiança zero baseadas em identidade à confiança baseada na localização na rede.
Comprem a complexidade operacional de uma malha de olhos abertos e meçam se ela compensa.

Recomendações

Entenda o que um gateway de API faz

Um gateway de API é um ponto de entrada único que fica na frente dos seus serviços e faz a mediação de toda requisição do mundo externo. No mais simples, é um proxy reverso inteligente (um servidor que recebe requisições de clientes e as encaminha ao backend certo), mas um gateway merece o nome fazendo muito mais que encaminhar. Ele roteia cada requisição ao serviço correto com base no caminho, no host ou nos cabeçalhos. Autentica quem chama (verificando quem é) e autoriza a requisição (verificando o que a pessoa pode fazer), para que um serviço atrás dele possa confiar que uma requisição já passou pela porta da frente. Impõe limitação de taxa (limitar requisições por cliente ao longo do tempo) e cotas (limitar o uso total numa janela mais longa) para que um cliente barulhento ou abusivo não deixe os outros sem recursos.

Um gateway também remodela o tráfego. A transformação de requisições reescreve cabeçalhos, traduz entre protocolos ou adapta o formato de um cliente antigo às expectativas de um serviço novo. A composição de API permite ao gateway abrir uma única requisição de entrada em vários serviços e costurar as respostas em uma, para que o cliente faça uma chamada em vez de seis. O suporte a versionamento permite rodar a v1 e a v2 de uma API lado a lado e rotear cada cliente à versão que espera, o que compra espaço para evoluir sem quebrar ninguém. Concentrar essas preocupações na borda mantém seus serviços focados na lógica de negócio e dá um único lugar para observar, proteger e limitar tudo que entra. O design das APIs que o gateway representa é assunto do capítulo 2.3, e as verificações de identidade que ele faz se apoiam no capítulo 4.7.

Use o padrão backend para frontend com clientes divergentes

Uma única API de uso geral costuma servir ao mesmo tempo um aplicativo web, um aplicativo móvel e integrações de parceiros, e serve a todos um pouco mal. O cliente móvel quer cargas pequenas e poucas idas e vindas porque largura de banda e bateria são escassas. O cliente web aguenta respostas mais tagarelas e ricas. O parceiro quer um contrato estável que nunca o surpreenda. O padrão backend para frontend (BFF, backend for frontend) resolve essa tensão dando a cada classe de cliente o seu próprio gateway fino, sob medida para as necessidades dela, na frente dos serviços compartilhados atrás.

Um BFF é um gateway com um público mais estreito. O BFF móvel compõe e apara as respostas para que o aplicativo faça uma chamada eficiente. O BFF web expõe uma forma mais completa. O BFF de parceiros guarda um contrato de evolução lenta e cuidadosamente versionado. Cada equipe pode evoluir o seu próprio BFF sem esperar as outras, o que muitas vezes é a vitória de verdade, porque desacopla as equipes de clientes umas das outras. O custo é mais peças móveis e alguma lógica duplicada entre os BFFs, então reservem o padrão para os casos em que as necessidades dos clientes genuinamente divergem. Quando todo cliente quer a mesma coisa, um gateway só é mais simples e melhor.

Entenda o que uma malha de serviços faz

Uma malha de serviços gerencia o tráfego leste-oeste entre os seus serviços, e faz isso sem pedir a esses serviços que mudem o código. A malha clássica funciona implantando um proxy sidecar (um pequeno processo de proxy que roda ao lado de cada instância de serviço e intercepta todo o seu tráfego de rede). O seu serviço acha que está falando direto com outro serviço, mas na realidade fala com o sidecar local, que trata a chamada de rede de verdade. Como toda requisição agora passa por um proxy que a plataforma controla, a malha consegue impor comportamento de modo uniforme em todo serviço, em qualquer linguagem, sem biblioteca compartilhada para manter sincronizada.

O que ela impõe? Primeiro, o TLS mútuo (mTLS), em que os dois lados de toda conexão apresentam certificados e criptografam o tráfego, de modo que as chamadas entre serviços são autenticadas e privadas por padrão. Segundo, o gerenciamento de tráfego: a malha pode deslocar uma pequena porcentagem do tráfego para uma nova versão num lançamento canário, dividir o tráfego por cabeçalho para testes ou espelhar o tráfego para um serviço sombra. Terceiro, a resiliência: novas tentativas, tempos limite e disjuntores (os padrões do capítulo 2.20) aplicados na camada da plataforma, configurados por política em vez de codificados em cada serviço. Quarto, a observabilidade: como toda requisição passa por um proxy, a malha emite métricas, logs e rastros distribuídos consistentes para todo o tráfego entre serviços, alimentando as práticas de observabilidade do capítulo 9.2. Quem escreve o serviço não escreve nada disso e ganha tudo.

Conheça o padrão sidecar e as alternativas sem sidecar

O modelo sidecar é elegante mas não é de graça. Cada instância de serviço agora roda um contêiner extra de proxy que consome memória e CPU, e cada chamada faz dois saltos de rede a mais (para dentro do sidecar local e para fora do remoto), acrescentando um pouco de latência. Com um punhado de serviços esse custo adicional é invisível. Com milhares de pods vira uma linha real na conta de computação e no orçamento de latência. Esse custo impulsionou uma onda de abordagens sem sidecar, ou sem proxy.

Duas direções importam. Uma move as funções da malha de um sidecar por pod para um proxy por nó, de modo que muitos serviços na mesma máquina compartilhem um proxy em vez de cada um rodar o seu. Isso troca algum isolamento por uma grande queda no custo adicional. A outra, a abordagem sem proxy, embute a lógica da malha diretamente no serviço por meio de uma biblioteca fina ou do ambiente de execução, removendo por completo os saltos extras ao custo de uma dependência por linguagem. Um desenvolvimento mais novo empurra algumas funções da malha para o núcleo do sistema operacional usando eBPF (uma tecnologia para rodar programas isolados dentro do núcleo do Linux), que pode impor políticas e coletar telemetria com menos custo adicional que um proxy em espaço de usuário. Vocês não precisam apostar num vencedor hoje. Precisam saber que o imposto do sidecar é real, que existem alternativas e que suas escolhas de plataforma não devem impedi-los de adotá-las depois. Esses padrões se assentam na fundação de orquestração de contêineres do capítulo 8.3.

Decida quando uma malha merece a sua complexidade

Uma malha de serviços é poderosa e genuinamente complicada de operar. Ela acrescenta um plano de controle para operar, proxies para atualizar, certificados para rotacionar e uma nova camada para depurar quando uma requisição some. Essa complexidade vale a pena comprar quando há serviços suficientes para que ligar essas preocupações à mão, por serviço e por linguagem, custe mais que operar a malha. O sinal aproximado é escala e diversidade poliglota: dezenas ou centenas de serviços, escritos em várias linguagens, em que uma biblioteca compartilhada de mTLS e de novas tentativas seria um pesadelo para manter consistente. Nessa escala, a malha se paga em uniformidade e segurança comprovável.

A malha não merece a complexidade quando há um punhado de serviços, uma única linguagem ou uma equipe pequena. Para um sistema modesto, uma boa biblioteca ou framework pode dar mTLS, novas tentativas e métricas com um ônus operacional muito menor que uma malha completa, e um gateway simples mais bibliotecas de cliente sensatas muitas vezes cobre tudo de que vocês precisam. Adotar uma malha por estar na moda, antes de a sua escala exigir, é um jeito comum de gastar um ano operando infraestrutura que resolve um problema que vocês não têm. Comecem pelo gateway, acrescentem padrões de resiliência em código ou em bibliotecas e recorram a uma malha quando a contagem de serviços e de linguagens fizer da abordagem por serviço a mais cara. É a mesma disciplina do “merece a complexidade?” a que os capítulos de nuvem e de sistemas distribuídos (3.11 e 3.3) voltam sem parar.

Evite o tratamento duplo onde o gateway e a malha se sobrepõem

Gateways e malhas se sobrepõem, e a sobreposição é onde as equipes se machucam. Os dois podem fazer novas tentativas, os dois podem impor tempos limite, os dois podem verificar a identidade, os dois podem coletar telemetria. Se o gateway tenta de novo uma requisição três vezes e a malha também a tenta três vezes em cada salto interno, uma nova tentativa do cliente pode explodir em dezenas de chamadas ao backend e transformar um pequeno soluço numa tempestade de novas tentativas. Se as duas camadas impõem um tempo limite e o interno é mais longo que o externo, o externo desiste enquanto o interno continua trabalhando, desperdiçando esforço numa resposta que ninguém lerá.

A correção é uma divisão clara de trabalho, escrita e acordada. Atribuam cada preocupação a exatamente uma camada. O gateway é dono das preocupações norte-sul: a autenticação do usuário final, os limites de taxa e cotas externos, a transformação de requisições e a composição de API para os clientes. A malha é dona das preocupações leste-oeste: o mTLS entre serviços, as novas tentativas internas e os disjuntores e o deslocamento de tráfego entre versões de serviço. Onde uma preocupação poderia viver em qualquer uma, escolham um dono e façam a outra camada deixar passar. Configurem orçamentos de novas tentativas e hierarquias de tempos limite para que um tempo limite externo seja sempre mais longo que o trabalho interno que ele aguarda. O objetivo é que toda requisição tenha exatamente um lugar que trate cada preocupação, e nenhuma requisição seja tentada de novo, autenticada ou registrada duas vezes por acidente.

Trate o gateway e a malha como pontos de imposição de política para a confiança zero

A razão mais profunda para rodar essas camadas é a arquitetura de segurança. A confiança zero é o princípio de que nenhuma requisição é confiável por causa de onde veio. Toda requisição precisa provar a sua identidade e a sua autorização, mesmo dentro da própria rede. O modelo antigo confiava em qualquer coisa já dentro do perímetro, o que significava que um serviço violado podia circular livremente. A confiança zero troca a confiança por localização na rede por confiança baseada em identidade em cada salto, e os gateways e as malhas são os pontos naturais de imposição onde essa identidade é verificada.

O gateway é o ponto de imposição de política para a identidade externa: verifica o usuário final ou o parceiro antes de qualquer coisa chegar aos seus serviços. A malha é o ponto de imposição de política para a identidade da carga de trabalho: cada serviço recebe uma identidade criptográfica, o mTLS a comprova em cada chamada e a política decide quais serviços podem falar com quais. Juntos dão defesa em profundidade, em que uma requisição é verificada na borda e de novo entre serviços, de modo que o comprometimento de um serviço não concede movimento livre aos demais. Em implantações com vários clusters e regiões, uma malha pode estender esse tecido de identidade além das fronteiras dos clusters, para que um serviço num cluster se autentique a um serviço em outro com as mesmas garantias de mTLS que usa localmente, dando uma rede de confiança zero consistente mesmo quando a pegada se espalha. Os fundamentos de identidade aqui se conectam diretamente ao capítulo 4.7.

Compromissos: prós e contras

Abordagem	Prós	Contras
Gateway de API	Um lugar para autenticação, limites de taxa, composição, versionamento	Um ponto único de estrangulamento para escalar e manter altamente disponível
Backend para frontend	Cada cliente recebe uma API sob medida e de evolução independente	Mais gateways para operar. Lógica duplicada entre os BFFs
Malha de serviços (sidecar)	mTLS uniforme, novas tentativas, observabilidade sem mudar código	Custo adicional de proxy, latência e um plano de controle para operar
Malha sem sidecar / sem proxy	Menos custo adicional e latência que sidecars por pod	Menos madura. Isolamento mais fraco ou dependência por linguagem
Resiliência baseada em bibliotecas	Simples de operar. Sem infraestrutura extra	Duplicação por linguagem. Difícil de manter consistente em escala
Malha entre clusters	Identidade de confiança zero consistente em toda parte	Complexidade operacional e de rede significativa

A tensão central é uniformidade versus custo operacional. Uma camada compartilhada compra consistência, segurança comprovável e política escrita uma vez, mas é um sistema real que vocês precisam operar, escalar, proteger e depurar, e que se insere no caminho de toda requisição. Resolvam a tensão por escala e necessidade. Um gateway quase sempre compensa no momento em que vocês têm clientes externos, porque as preocupações que ele centraliza são inevitáveis. Uma malha compensa mais tarde, quando o número de serviços e de linguagens torna a fiação por serviço o caminho mais caro. Abaixo desse limiar, bibliotecas e um gateway simples dão a maior parte do benefício por uma fração do custo. Acima dele, a uniformidade da malha vale o que pesa. O erro nas duas direções é adotar por moda e não por necessidade: uma malha cedo demais é um ano de trabalho inútil de preparação, e uma malha pulada tarde demais é uma centena de implementações caseiras e inconsistentes de mTLS.

Perguntas para discutir com sua equipe

Para cada preocupação transversal (autenticação, novas tentativas, tempos limite, limitação de taxa, criptografia, telemetria), qual camada única é dona dela, e todos conseguem nomear o dono sem chutar? Esta é a pergunta que previne o tratamento duplo, e a maioria das equipes nunca a respondeu explicitamente, o que significa que a resposta difere por serviço e por autor. Levem uma lista concreta de preocupações no lado esquerdo e as suas camadas (biblioteca de cliente, gateway, malha, serviço individual) no alto e preencham a grade juntos. Os lugares em que duas células são marcadas para uma preocupação são as suas tempestades de novas tentativas e inversões de tempo limite esperando para acontecer. As linhas vazias são as preocupações que ninguém está tratando. O produto é uma única tabela acordada, publicada onde toda equipe possa ver, que diz que exatamente uma camada é dona de cada preocupação e as outras deixam passar. Essa tabela vale mais que qualquer quantidade de configuração de gateway ou de malha, porque é o que impede as duas camadas de brigarem entre si.
Temos de fato serviços e diversidade de linguagens suficientes para justificar uma malha de serviços, ou estamos prestes a comprar um plano de controle para resolver um problema que não temos? Uma malha é um compromisso operacional sério, e a resposta honesta para muitas equipes é que uma boa biblioteca mais um gateway as serviria melhor hoje. Levem a contagem real de serviços, o número de linguagens em que são escritos e uma avaliação honesta de quanto a lógica de rede duplicada de fato dói agora. Depois levem o outro lado: quem vai operar a malha, atualizar os proxies, rotacionar os certificados e ser chamado quando ela rotear mal uma requisição. Se a dor da fiação por serviço é menor que o custo de rodar a malha, vocês têm a resposta, e é esperar. Se vocês estão se afogando em código inconsistente de mTLS e de novas tentativas em dezenas de serviços poliglotas, a malha merece o que custa. O ponto é decidir com evidências, não pelo que uma palestra de conferência fez a malha parecer.
Onde está hoje a nossa fronteira de confiança zero, e o que acontece se um serviço interno for comprometido? Muitos sistemas ainda confiam em qualquer coisa já dentro da rede, o que significa que um único serviço violado pode se mover lateralmente e alcançar todo o resto, e as equipes frequentemente só descobrem isso durante um incidente. Percorram o raio de impacto com honestidade: se um atacante é dono de um dos seus serviços, o que ele pode chamar, o que pode ler e o que o detém? Levem a sua resposta atual sobre como as chamadas entre serviços são autenticadas e criptografadas e sejam específicos sobre quais chamadas são protegidas por mTLS e quais são confiança em texto puro por estarem na mesma rede. A ação que decorre é um plano deliberado de acesso baseado em identidade em cada salto, com o gateway verificando a identidade externa e a malha, ou equivalente, verificando a identidade da carga de trabalho, para que um comprometimento seja contido e não catastrófico. Mesmo que vocês não estejam prontos para rodar uma malha completa, nomear onde a fronteira de confiança realmente fica é o primeiro passo honesto.
Se a nossa camada de gateway de API falhasse agora, quanto do sistema apagaria, e testamos essa falha em vez de presumir que ela não acontece? O gateway centraliza tanta coisa que sua queda tira do ar tudo que está atrás dele, e as grandes equipes tendem a investir pouco na redundância dele exatamente porque ele funciona em silêncio até deixar de funcionar. Pesem as atrações concorrentes: um único gateway simples é fácil de raciocinar e barato de operar, enquanto uma camada escalada horizontalmente e multizona custa mais e acrescenta sua própria configuração de failover e complexidade. Levem números reais para a discussão, incluindo quantas instâncias rodam hoje, em quantas zonas de disponibilidade, qual é o tempo de failover e quando foi a última vez que vocês fizeram um dia de simulação que derrubou o gateway de propósito. Para plataformas corporativas e governamentais com compromissos de disponibilidade ou níveis de serviço estatutários, acrescentem a penalidade contratual ou regulatória por uma queda, porque uma porta da frente sem redundância é um risco de disponibilidade que vocês aceitaram em silêncio em nome de todo serviço e de todo cidadão atrás dela.
Medimos o imposto do sidecar que a nossa malha de fato cobra, e temos um plano para as alternativas sem sidecar e eBPF, ou estamos pagando às cegas? Em escala, o custo adicional de proxy por pod em computação e latência deixa de ser invisível e vira uma linha real no orçamento, e ainda assim muitas equipes rodam milhares de sidecars sem nunca medir o custo. A tensão é entre a maturidade e o isolamento do modelo sidecar de um lado e o menor custo adicional dos proxies por nó, das bibliotecas sem proxy ou das abordagens eBPF no núcleo do outro, que são mais novas e trocam algum isolamento ou acrescentam uma dependência por linguagem. Levem os números medidos: a memória e a CPU consumidas pelos proxies em toda a frota, a latência de cauda acrescentada por salto e que fração da conta de computação a malha representa. Para uma grande empresa que roda a malha em milhares de pods, ou uma plataforma governamental sob escrutínio orçamentário, essa é uma decisão de gasto sobre a qual a supervisão acabará perguntando, então saber o imposto e se as suas escolhas de plataforma mantêm abertas as alternativas mais baratas é diligência básica.
Cada classe de cliente realmente precisa do seu próprio backend para frontend, ou estamos prestes a duplicar lógica entre gateways para clientes que na verdade querem a mesma coisa? O padrão BFF desacopla as equipes de clientes e deixa cada uma evoluir um contrato sob medida, mas cada novo BFF é mais um gateway para operar, proteger e manter sincronizado, e a lógica duplicada entre eles vira em silêncio um imposto de manutenção. As considerações concorrentes são a autonomia das equipes e a eficiência específica por cliente versus o custo operacional e a deriva de muitos gateways quase idênticos. Levem evidências de quanto as necessidades dos clientes realmente divergem: tamanhos de carga, contagens de idas e vindas, cadência de versionamento e com que frequência a mudança de um cliente teria bloqueado outro sob um único gateway compartilhado. Numa grande organização com muitas equipes de clientes, ou numa plataforma governamental que serve ao mesmo tempo um aplicativo web público, um aplicativo móvel e integrações de parceiros, a pergunta honesta é se a divergência justifica a proliferação, porque um BFF por cliente em que todos querem a mesma forma é um espalhamento que vocês pagarão para manter por anos.

Perspectiva por setor

Startup. Entreguem um gateway de API e pulem a malha. Com um punhado de serviços e uma equipe minúscula, um único gateway trata a autenticação, os limites de taxa e a composição, enquanto uma biblioteca de cliente compartilhada dá mTLS e novas tentativas por uma fração do custo de um plano de controle. O seu recurso mais escasso é a atenção da engenharia, então uma malha que vocês não conseguem operar é um passivo, não um fosso de proteção. Mantenham o gateway redundante o bastante para sobreviver à morte de um nó e revisitem a malha só quando a contagem de serviços e a diversidade de linguagens realmente forçarem a questão.

Pequena empresa. Vocês não têm equipe de plataforma para rodar uma malha, então apoiem-se no que a sua plataforma de hospedagem ou o produto de gateway dá de fábrica: TLS gerenciado, limitação de taxa embutida e um gateway hospedado em vez de um que vocês mesmos corrigem. Enquadrem a escolha como comprar versus construir, e comprem, porque um gateway de API gerenciado custa menos que as horas de engenheiro para operar o seu. Tratem a criptografia interna entre serviços como uma funcionalidade que a plataforma fornece, não um projeto que vocês põem gente para fazer.

Grande empresa. Com centenas de serviços em muitas equipes e linguagens, uma malha merece a complexidade, e o trabalho real é a governança: uma divisão de trabalho escrita para que o gateway e a malha nunca tratem em dobro uma preocupação, mTLS e telemetria uniformes e uma equipe de plataforma dona das atualizações de proxy e da rotação de certificados. Os auditores querem um único ponto comprovável de imposição para acesso e criptografia, então padronizem a interface e façam da política algo que as equipes herdam em vez de reimplementar. Gerenciem o imposto do sidecar como uma linha real de orçamento e mantenham abertas as opções sem sidecar para não ficarem impedidos de adotar abordagens mais baratas depois.

Governo. As regras de contratação, a transparência e a responsabilização pública moldam a arquitetura. Tratem o gateway e a malha como a espinha dorsal de confiança zero que os reguladores esperam: todo cidadão e parceiro autenticado na porta da frente, toda chamada interna autenticada e criptografada pela identidade da carga de trabalho e uma trilha de auditoria em cada ponto de imposição provando onde o acesso foi verificado e onde o tráfego foi criptografado. Favoreçam padrões abertos e configuração portátil em vez do aprisionamento proprietário que as regras de contratação podem proibir e publiquem, quando apropriado, como a plataforma protege os dados dos cidadãos ao cruzarem cada fronteira.

Exemplos

Startup. Uma startup de doze pessoas roda oito serviços atrás de um único gateway de API. O gateway trata todo o trabalho norte-sul: autentica os usuários com uma verificação de token, impõe limites de taxa por plano para que usuários do nível gratuito não afoguem o sistema e compõe alguns endpoints tagarelas em chamadas únicas amigáveis ao celular. Para o tráfego leste-oeste eles deliberadamente pulam uma malha de serviços, porque oito serviços em duas linguagens não justificam um plano de controle. Em vez disso obtêm mTLS e novas tentativas de uma biblioteca de cliente compartilhada e do gerenciamento de certificados embutido da plataforma e coletam rastros com um agente leve. Quando mais tarde acrescentam um cliente móvel dedicado com necessidades de carga mais apertadas, introduzem um backend para frontend móvel ao lado do gateway web existente. Revisitam a questão da malha todo ano e continuam decidindo, corretamente, que ainda não cruzaram o limiar em que ela compensaria.

Grande empresa. Um banco multinacional opera várias centenas de serviços em muitas equipes e linguagens, e aqui uma malha de serviços merece a complexidade. Todo serviço recebe uma identidade de carga de trabalho e mTLS por padrão, de modo que todo o tráfego interno é autenticado e criptografado sem que nenhuma equipe escreva código de criptografia, o que satisfaz tanto a organização de segurança quanto os auditores que querem um único ponto comprovável de imposição. A malha aplica por política novas tentativas, tempos limite e disjuntores uniformes e desloca o tráfego gradualmente nos lançamentos canário, de modo que uma implantação ruim toca um por cento dos usuários antes de tocar todos. Uma camada de gateways de API fica na frente do tráfego externo e de parceiros, sendo dona de autenticação, cotas e versionamento, com uma regra escrita firme de que as novas tentativas internas vivem apenas na malha e os limites de taxa externos vivem apenas nos gateways, para que as duas camadas nunca tratem em dobro uma requisição. A telemetria consistente de cada proxy alimenta uma plataforma central de observabilidade que permite a um engenheiro de sobreaviso rastrear uma requisição por dezenas de saltos de serviço.

Governo. Uma autoridade tributária nacional moderniza uma plataforma de declaração voltada ao cidadão e trata o gateway e a malha como a espinha dorsal de uma arquitetura de confiança zero que os reguladores exigem. Um gateway de API é a porta da frente controlada: todo cidadão e todo parceiro é autenticado e autorizado ali, os limites de taxa externos protegem o sistema durante a onda do prazo de declaração e os formatos de clientes antigos são transformados na borda para que as integrações legadas continuem funcionando. Atrás dele, uma malha de serviços dá a todo serviço interno uma identidade criptográfica e impõe mTLS em toda chamada, de modo que nenhum serviço é confiável apenas por estar dentro da rede, e a política de acesso lista explicitamente quais serviços podem chamar quais. Como a plataforma abrange vários data centers por resiliência, a malha estende as mesmas garantias de identidade e de criptografia entre clusters, dando uma rede de confiança zero consistente em todo o país. Cada ponto de imposição emite uma trilha de auditoria, de modo que a autoridade pode provar aos órgãos de supervisão exatamente onde o acesso foi verificado e onde o tráfego foi criptografado.

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

O retorno de um gateway é fácil de ver e costuma ser grande. Em vez de cada serviço reimplementar a autenticação, a limitação de taxa e o registro de requisições, vocês os constroem uma vez na borda e todo serviço os herda. Uma correção de segurança ou uma nova política de limite de taxa chega numa implantação em vez de cem, o que encurta o tempo para fechar uma vulnerabilidade e reduz o custo de cada auditoria, porque há um único lugar a inspecionar. Os recursos de composição e de versionamento cortam idas e vindas dos clientes e permitem evoluir as APIs sem quebrar quem chama, o que reduz tanto os custos de latência quanto o imposto de coordenação entre equipes. Para quase qualquer sistema com clientes externos, um gateway se paga rápido.

A malha de serviços tem uma justificativa de negócio mais sutil, porque seu custo total de propriedade é real e contínuo. Vocês pagam pela computação e pela latência dos proxies, pelos engenheiros que operam o plano de controle e pela curva de aprendizado de depurar uma nova camada. Esse custo se justifica quando a alternativa (implementações por serviço e por linguagem de mTLS, novas tentativas e telemetria) seria maior e, pior, inconsistente de modos que criam brechas de segurança e quedas. Em alta escala a malha converte uma centena de soluções caseiras frágeis numa uniforme e comprovável, e o ROI aparece como menos incidentes de segurança, implantações seguras mais rápidas por deslocamento de tráfego e observabilidade drasticamente melhor. Abaixo dessa escala, o cálculo honesto muitas vezes favorece bibliotecas e um gateway, e o movimento disciplinado é esperar. Para defender o caso junto à liderança, liguem o gateway às métricas que ela já acompanha (tempo para remediar vulnerabilidades, custo de auditoria, custo adicional de coordenação de API) e liguem a malha à contenção de incidentes de segurança, à segurança das implantações e ao custo da duplicação poliglota que ela substitui.

Antipadrões e armadilhas

Malha antes da hora: adotar uma malha de serviços completa com um punhado de serviços, comprando um plano de controle para resolver um problema que vocês ainda não têm.
Novas tentativas em dobro: o gateway e a malha ambos tentam de novo, de modo que uma chamada de cliente se multiplica numa tempestade de novas tentativas no backend que amplifica uma queda.
Inversão de tempo limite: um tempo limite interno mais longo que o externo, de modo que quem chama desiste enquanto o chamado continua trabalhando numa resposta que ninguém lerá.
Gateway como monolito: enfiar lógica de negócio no gateway até virar um gargalo compartilhado que toda equipe precisa coordenar para mudar.
Ponto único de falha: rodar uma única instância de gateway sem redundância, de modo que a falha da porta da frente derruba todos os serviços atrás dela.
Confiar na rede: tratar tudo dentro do perímetro como seguro, de modo que um serviço comprometido pode se mover lateralmente e alcançar tudo.
Propriedade sobreposta: nenhuma divisão de trabalho escrita, de modo que a mesma preocupação é tratada nas duas camadas por acidente e ninguém sabe qual é a autoritativa.
Espalhamento de BFFs: criar um backend para frontend por cliente quando os clientes querem a mesma coisa, multiplicando gateways e duplicando lógica sem ganho.
Ignorar o imposto do sidecar: implantar milhares de sidecars sem medir o custo adicional de computação e de latência e depois se perguntar para onde foi o orçamento.

Modelo de maturidade

Nível 1, Iniciar: Os serviços falam diretamente uns com os outros, sem camada compartilhada. A autenticação, as novas tentativas e os tempos limite são codificados à mão por serviço e inconsistentes. O tráfego interno costuma estar em texto puro e ser confiável por estar na rede, e não há um único lugar para impor política ou observar o tráfego. As decisões são reativas, tomadas serviço a serviço à medida que os problemas surgem.
Nível 2, Desenvolver: Um gateway de API fica na frente do tráfego externo e centraliza a autenticação, a limitação de taxa e o roteamento, mas as preocupações leste-oeste são tratadas por bibliotecas compartilhadas com adoção desigual. Alguns serviços têm mTLS e muitos não. As equipes reconhecem a distinção entre norte-sul e leste-oeste, mas a propriedade é informal e as práticas diferem de uma equipe para outra.
Nível 3, Padronizar: As preocupações norte-sul e leste-oeste são separadas de forma limpa, com uma divisão de trabalho escrita aplicada em toda a organização. O gateway é dono da identidade externa, das cotas e da composição. Uma malha ou uma camada consistente de bibliotecas é dona do mTLS interno, das novas tentativas e da telemetria. As sobreposições são resolvidas para que nenhuma preocupação seja tratada em dobro, o tráfego interno é criptografado e verificado por identidade por padrão e o padrão é documentado e imposto e não deixado ao critério de cada equipe.
Nível 4, Gerenciar: A camada de tráfego é medida e controlada em relação a linhas de base. Vocês acompanham o imposto do sidecar em computação e latência de cauda por salto, a disponibilidade do gateway e da malha contra orçamentos de erro, os incidentes de amplificação de novas tentativas e de inversão de tempo limite, a cobertura de mTLS como porcentagem das chamadas internas e o tempo para empurrar uma mudança de política por toda a frota. As métricas condicionam decisões: uma atualização de proxy, um novo orçamento de novas tentativas ou uma regra canário são julgados com dados contra uma linha de base e não por intuição, e qualquer desvio do padrão dispara uma correção.
Nível 5, Orquestrar: O gateway e a malha são pontos de imposição de política de uma arquitetura madura de confiança zero, com a identidade verificada em cada salto entre clusters e regiões. O deslocamento de tráfego conduz a entrega progressiva segura, a observabilidade é uniforme e rica e a organização avalia e adota continuamente abordagens sem sidecar, sem proxy e eBPF onde elas compensam. A camada de tráfego é integrada à segurança, à entrega e ao planejamento de capacidade e se adapta à medida que a escala, as linguagens e o quadro de riscos mudam.

Ideias para discussão

Se o seu único gateway de API caísse agora, quantos serviços ficariam inalcançáveis, e qual é o plano de vocês para tornar redundante a porta da frente?
Qual preocupação do seu sistema é hoje tratada tanto no gateway quanto num serviço (ou numa biblioteca), e como vocês provariam que ela não está sendo tratada em dobro?
A partir de que número de serviços e de linguagens a sua equipe concordaria que uma malha finalmente merece a sua complexidade, e quão longe vocês estão dessa linha?
Se um atacante comprometesse um serviço interno amanhã, quais outros serviços ele poderia alcançar, e que verificação de identidade o deteria?
As abordagens de malha sem sidecar ou baseadas em eBPF já são maduras o bastante para a sua plataforma, e o que vocês mediriam para decidir?
Cada um dos seus clientes divergentes realmente precisa do seu próprio backend para frontend, ou vocês estão prestes a duplicar lógica que poderia continuar compartilhada?

Principais conclusões

Separem o tráfego norte-sul (tratado por um gateway de API) do tráfego leste-oeste (tratado por uma malha de serviços). Cada um é dono da sua direção, e confundi-los causa tratamento duplo.
Um gateway centraliza o roteamento, a autenticação, a autorização, a limitação de taxa, as cotas, a transformação de requisições, a composição e o versionamento, de modo que os serviços permanecem finos e a política vive num só lugar.
Uma malha de serviços dá mTLS, deslocamento de tráfego, novas tentativas e disjuntores no nível da plataforma e observabilidade uniforme sem mudar o código dos serviços, classicamente por proxies sidecar.
Adotem uma malha apenas quando a contagem de serviços e de linguagens tornar a fiação por serviço o caminho mais caro. Abaixo disso, bibliotecas mais um gateway vencem, e o imposto do sidecar é real o bastante para ser vigiado.
Tratem o gateway e a malha como os pontos de imposição de política de uma arquitetura de confiança zero, atribuam cada preocupação transversal a exatamente uma camada e verifiquem a identidade em cada salto entre clusters.

Referências e leitura complementar

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices