Desempenho de Service Mesh: Uma Análise Aprofundada

No mundo de hoje, onde todo mundo adora nuvem, muitas aplicações são feitas com microserviços. Imagina um festival gigante onde cada barraca tem seu próprio tema. Pra tudo funcionar direitinho, precisamos de um segurança amigável, mas firme, entre essas barracas. É isso que uma service mesh faz! Ela ajuda os microserviços a se comunicar, mantém a segurança e cuida das tarefas complexas da rede, enquanto os desenvolvedores podem focar nos projetos legais deles.

Mas, assim como colocar uma camada extra de cobertura em um bolo pode deixá-lo bonito, mas um pouco pesado, usar uma service mesh pode deixar tudo mais lento. Então, decidimos dar uma olhada em como o protocolo MTLS - nosso segurança - afeta o Desempenho ao usar diferentes service meshes como Istio, Linkerd e Cilium.

#O que é mTLS?

Antes de entrar nos detalhes, vamos primeiro entender o que é mTLS. Pense nisso como um cumprimento sofisticado. Em um cumprimento TLS normal, só o servidor mostra sua ID - como um segurança conferindo IDs na porta. No mTLS, tanto o cliente quanto o servidor mostram suas IDs. Assim, todo mundo sabe quem é quem e pode trocar informações sem se preocupar com convidados indesejados.

#Por que usar uma Service Mesh?

Com mais empresas entrando na onda dos microserviços, as service meshes ficaram mais populares. Elas ajudam a gerenciar o tráfego entre serviços, melhoram a segurança e tornam tudo mais fácil de manter. Uma pesquisa de algumas pessoas da tecnologia revelou que cerca de 70% das organizações estão usando service meshes, seja em produção ou em teste.

Diferentes service meshes podem oferecer diferentes vantagens, e é importante pesar isso contra possíveis lentidões. Então, como encontramos a melhor service mesh para nossas necessidades? Precisamos fazer alguns testes à moda antiga!

#Configurando os Testes

Pra conduzir nossa investigação, criamos um ambiente de testes parecido com uma configuração de nuvem movimentada. Imagine como um parque de diversões simulado cheio de brinquedos (microserviços) que precisam trabalhar juntos de forma harmoniosa.

Usamos uma ferramenta chamada Fortio pra simular o tráfego de rede, como um teste de pressão, pra ver como cada service mesh gerencia as requisições. Monitoramos tudo de perto, procurando sinais de estresse como latência (quanto tempo as coisas demoram) e uso de recursos (quanto de CPU e memória estão sendo usados).

Durante os testes, comparamos cada service mesh com uma linha de base - que é só um termo chique pra rodar as coisas sem nenhuma service mesh. Queríamos ver como elas se saíam com mTLS ativado e sem.

#O que encontramos?

#Sobrecarga de Desempenho

Assim como ingredientes extras em uma pizza podem deixá-la mais pesada, adicionar uma service mesh pode trazer uma sobrecarga de desempenho. Nossos testes mostraram que forçar o mTLS com service meshes resultou em aumento de latência em geral.

Aqui está como elas se saíram em termos de aumento de latência:

• Istio: Um impressionante aumento de 166%
• Istio Ambient: Apenas 8%
• Linkerd: Cerca de 33%
• Cilium: Um aumento de 99%

São números bem malucos! Parece que o Istio tem algumas explicações a dar!

#Consumo de Recursos

E não para por aí. Também descobrimos que o consumo de recursos disparou em todos os casos. Com o mTLS ativado, o uso de CPU e memória aumentou, mas nem todas as service meshes são iguais. O Istio parecia levar a palma (ou a pizza) pelo uso mais alto de recursos, enquanto o Istio Ambient foi o mais eficiente.

#Sidecar vs. Sidecarless

Pra entender melhor, aqui vai uma rápida explicação sobre dois tipos de arquitetura de service mesh que testamos: sidecar e sidecarless.

1. Padrão Sidecar: Imagine adicionar um garçom separado (o sidecar) para cada mesa (serviço). Esse garçom cuida de toda a comida (dados) que entra e sai. Enquanto funciona, pode ficar bem movimentado!

2. Modelo Sidecarless: Imagine se os garçons estivessem todos reunidos na cozinha (o nó), reduzindo o número de pessoas correndo por aí. É isso que o modelo sidecarless faz! Ao gerenciar tudo com um agente central, ele evita as paradas extras do lado do sidecar.

#Principais Descobertas

• Istio: Alta latência e sobrecarga de recursos. É como ter um mini-exército de garçons, mas eles estão levando um tempão!

• Istio Ambient: Melhor desempenho! É como uma cozinha bem organizada com garçons eficientes que não se perdem.

• Linkerd: Um pouco atrás do Istio Ambient, mas ainda indo bem. Um performer sólido, como um amigo confiável!

• Cilium: É como aquela pessoa no seu grupo de amigos que é super eficiente e nunca parece desacelerar, mas é um pouco excêntrica. O Cilium não criptografa o tráfego intra-nó, o que acelerou as coisas, mas pode levantar algumas sobrancelhas.

#Conclusão

Nossos testes mostraram que, enquanto as service meshes trazem benefícios importantes, elas também trazem desvantagens de desempenho, especialmente ao usar mTLS. Então, qual service mesh você deve escolher?

• Se você quer muitas funcionalidades e tá de boa com uma leve lentidão, o Istio pode ser a sua escolha.
• Se você quer eficiência sem sacrificar muito, dá uma olhada no Istio Ambient.
• Se precisa de algo confiável, mas não muito chamativo, o Linkerd tá no ponto.
• E se você tá procurando um velocista, o Cilium é sua melhor aposta, só fica ligado nas suas peculiaridades!

No final das contas, é tudo sobre descobrir o que você procura. Escolher uma service mesh é um pouco como escolher uma refeição: deve satisfazer sua fome enquanto se encaixa no seu orçamento e metas de saúde! Então reúna sua equipe, avalie suas necessidades e escolha a service mesh que é perfeita pra você. Boa sorte na rede!