Durante a live de kong da semana passada rolou uma dúvida bem pertinente, mas como a live já estava com 3 horas e 30 min, não dava para continuar por mais 2 horas para conseguir contextualizar e falar sobre o tema. Então resolvi escrever esse post.

Na prática eu decidi que ia escrever esse post na própria sexta, mas eu não tive tempo de colocar a mão nisso nesses dias então resolvi fazer isso agora no domingo, já que fui relembrado, ao fazer a indexação do vídeo no youtube, e sinceramente eu já havia me esquecido do assunto.

Então vamos entender o contexto:

Wiluey Queiroz pergunta:

Istio + Kong + HA Proxy – Diferenças, prós e contras.

Boa Wiluey! Tem bastante coisa para discorrermos aqui sobre isso!

Do que estamos falando?

É preciso contextualizar do que estamos falando. São 3 categorias bem distintas:

• Service Mesh: Istio
• API Gateway: Kong
• Proxy Reverso: HAProxy

E no final das contas, estamos lidando quase que com temas que se assemelham às diferenças entre carros. Carros, caminhonetes e caminhões. E dentro dos carros vamos encontrar uma segmentação menos rígida, como os compactos, compactos médios, crossovers e SUV’s.

Antes desses detalhes, que dão vida a essa analogia, precisamos pontuar o que é o modelo OSI.

O modelo OSI

Quando lemos “Layer 4 load balancing/proxy/etc” isso nos diz que, o roteamento possível com esse tipo de proxy é baseado na camada 4 do modelo OSI. Trazendo para o popular, isso quer dizer que esse proxy reverso só sabe redirecionar tráfego de acordo com o IP e porta em que recebeu a requisição. Ou seja para cada ip/porta que escuta, ele consegue enviar tráfego para um endereço diferente.

Quando lemos “Layer 7 load balancing/proxy/etc” isso nos diz que esse proxy é baseado na camada 7, camada de aplicação. Isso quer dizer que esse proxy reverso conhece protocolos sob o TCP, e na maioria das vezes somente HTTP, mas poderia ser qualquer outro. E tem vários que são espertinhos ao ponto de conhecer protocolos específicos como do Redis, MongoDB, e outros. Um proxy layer 7, poderia, por exemplo rotear comunicação com bancos de dados, usando parte da definição de sua connectionstring para identificar em qual servidor deve redirecionar o tráfego. Aliás, o SQL Server tem algo assim embarcado nele.

No entanto, o fato de conhecer o protocolo, não o faz especialista. No nosso mercado de TI, conhecer uma tecnologia não nos faz especialista nela, não é? Isso precisa ser levado em conta quando falamos desse tema.

No nosso contexto, de proxy reverso, load balancing e service mesh, temos estamos quase que afunilando o pensamento em HTTP (layer7) ou TCP simples (layer 4).

No início era tudo mato

No início dos tempos só existiam Load Balancers baseados na camada 4 que eram hardwares. Chamar o produto de load balancer era comum para quem só tinha esse recurso. E faz sentido. Load Balancing para grandes cargas de trabalho exige uma customização infernal no sistema operacional, e para garantir isso, entregar um hardware consistente, elimina muitos dos problemas, aumenta o ticket (preço médio de cada venda) e oferece a capacidade de entregar um SLA muito preciso sobre carga de trabalho aceita. Enfim, reduzem-se variáveis na hora de entregar uma solução de alta disponibilidade, o resultado é maior previsibilidade.

O principal a ser notado, é que Hospedar arquivos estáticos, Proxy Reverso, Load Balancing são comportamentos, muito mais que categorias de produtos. Isso porque cada vez mais vemos produtos que originalmente eram uma coisa só, assumindo mais papéis.

Com o passar dos anos, e com o custo do hardware, empresas pequenas começaram a usar soluções baseadas em software. Esse software tinha os mesmos recursos, mas agora trabalhavam sob um sistema operacional do cliente. Obviamente não dá para assegurar a mesma carga de trabalho, mas aí a pergunta: E daí, se você não tem nem 1/10 da necessidade?

Bom, é por aí mesmo. Cargas de trabalho menores começaram a ser atendidas por software. E não é que as empresas foram lidando com isso cada vez melhor? A cloud ajudou a diluir esse custo também.

E hoje ainda existe esse tipo de hardware e é comercializado normalmente. A diferença é que cada vez mais, usamos aplicações para realizar esses diversos papéis. E cada vez mais, esses papéis muito especialistas são incorporados a quem só precisa de um detalhe para abocanhar essa fatia de responsabilidade nos clientes que já usam sua tecnologia.

As responsabilidades

Na web existem várias responsabilidades ocultas que não nos damos conta.

Web Server

• Sabe entregar conteúdo estático e em geral via módulos hospedar uma aplicação.
• Web servers embarcados em uma aplicação, como é o caso do Kestrel, já estão lado-a-lado com o código portando não precisam de módulos para rodar outra coisa, eles já estão ali.

Proxy Reverso

• Saber propagar uma requisição para um backend, aguardando sua resposta para entregar para o requisitante.
• Esse backend pode ser composto por múltiplos endereços, isso faz ele ganhar a responsabilidade de load balancer.

Load Balancer

Saber distribuir cargas de trabalho e ser eficiente em criar afinidade em condições muito específicas. O know how sobre os protocolos que trafega é importantíssimo para não produzir afinidade de todo o tráfego, só sob condições específicas.

Cache

Sim, caching é um componente e tem serviços especializados nisso, como por exemplo o Varnish Cache.

Fim?

Não! Ainda falta falar de CDN e outros elementos da web, mas por hora vamos parar por aqui, pois é preciso terminar o post.

API Gateway

Saber lidar com trafego específico de API’s, em geral JSON e XML, podendo ter os mais variados tipos de autenticação e autorização baseado nos mais variados fluxos de segurança. Lidando com transformação em alguns casos. Isso faz dele, por definição tanto um proxy reverso. Mas é super comum também ser um load balancer. E também é comum ser um cache, principalmente se conectado a um redis ou algo do gênero.

Aqui estão alguns recursos do kong. E essa lista se basta em relação à comparação entre API Gateway vs Proxy Reverso vs Service Mesh.

Service Mesh

Service mesh é uma outra coisa, beeeeeem distante. Trata-se de uma implementação usada na mediação da interconectividade entre serviços para produzir abstração e gerenciamento tanto do tráfego de entrada quanto do tráfego de saída.

Confuso? Calma, eu achei esse vídeo do Brendan Burns, co-criador do Kubernetes.

O ponto principal é abstrair a complexidade de lidar com endpoints, roteamento, composição e adicionar uma camada de observabilidade não para o processo, mas para tudo que entra e sai do processo.

O service mesh entra como mediador do tráfego inbound e outbound, e isso permite conectar a outro service mesh de outro endpoint que pode estar em outro datacenter ou em outro provedor de cloud, ou mesmo on premise, sem que sua aplicação saiba disso.

Aliás, outro recurso interessante é a observabilidade (“tracing, monitoring, and logging“), embora seja controverso, como intermediador de 100% da comunicação que entra e sai do teu processo, essa é uma capacidade adicional interessante por ser feita out of the box. Mas claro, sempre será de certa forma limitada, se não estiver claro que essas métricas são relacionadas ao que está ao redor do processo e não sobre o processo em si.

Vale a pena a lida em Classifying Metrics Based on Request or Response (Experimental). Embora experimental, é interessante.

Como você viu no vídeo, você tem também autorização e gestão sob a conectividade, quem fala com quem. Enfim, é tambme, novamente outra coisa bem diferente de load balancing, diferente de proxy reverso, diferente de web server, caching.

Um ponto importante é, que por exemplo o Istio é baseado no Envoy, outro projeto da CNCF, assim como o Kubernetes e o próprio Istio. Por baixo dos panos, o Istio, coordena instancias envoy. O sidecar que você enxerga no mesmo pod da tua aplicação, não é uma instancia istio, é uma instância do envoy. Você encontra essa informação na página de arquietura do Istio.

Parece muito divertido? não. Istio pode ou não ser usado com Kubernetes, mas na prática é desumano usar Istio sem Kubernetes.

Edge

Por fim queria pontuar o que eu chamo de Edge, pois é como essas responsabilidades que vimos acima se confundem com suas implementações. Categorizar as coisas é uma tarefa chata demais. Então hoje eu simplifiquei minha comunicação, separando em Edge de resto. Edge é o serviço mais extremo em sua rede, aquele que recebe a primeira camada que você tem controle em que você recebe as requisições. Essa é uma distinção entre seu serviço e um cliente externo à sua infraestrutura, como um navegador, por exemplo.

Quando usar?

Agora que colocamos todos os elementos na mesa, podemos falar das decisões arquiteturais a respeito desses assuntos.

Como Edge, eu quero alguém que lide com tráfego http comum, tanto API, como não API’s. Eu preciso de um proxy reverso. Nesse papel eu usaria NGINX, Envoy, HAProxy e afins.

Proxy Reverso vs API Gateway, ou melhor, HAProxy vs Kong? Essa é uma comparação que não faz tanto sendido. Faria, se seu API Gateway fosse subutilizado, mas aí o erro é ter usado um API Gateway no lugar de um proxy reverso. As habilidades da camada 7 de um proxy reverso representam nem 10% das habilidades de um api gateway. E isso não faz um ser melhor que outro, faz um ser especializado em uma coisa e outro especializado em outra. Na minha opinião, se há um API Gateway, um proxy reverso é quase que obrigatório quando você não trabalha naqueles endpoints com somente API’s.

Um nível abaixo, eu quero quem saiba lidar com minhas API’s. Do cenário mais simples: NADA. Querendo mais maturidade, Kong ou outro API Gateway, talvez até mesmo a Jaguaritica.

Mas como disse no início, o que precisamos separar as responsabilidades das categorias e olhar para cada implementação, visto que essas compartilham cada vez mais responsabilidades que antes eram de outra categoria.

Aí entra a questão. Se eu estiver usando service mesh, eu fatidicamente pensaria no Istio. Mas é uma tecnicalidade: Eu conheço o alicerce do Istio, o Envoy, e tenho certo carinho pelo projeto. Uma vez com Istio, eu teria a oportunidade de pensar no envoy como edge da minha infra, servindo quem está na malha e quem não está.

Ainda cabe a discussão se eu teria algo fora da malha ou não. Eu tento a, por exemplo, não ter um site wordpress dentro da malha. E sites wordpress são parte de quase a totalidade do mercado. Usar o envoy nesse contexto me dá poder para escolher.

O principal ponto é que eu não decido, e você não deveria decidir, usar um service mesh porque é bonito, ou eficiente! Eu usaria um service mesh para endereçar uma necessidade que eu preciso e atende um requisito, exatamente como descrevi em 2014 em Como definir a Arquitetura de um Software.

Aliás, é isso que me faz hoje estudar coisas que não uso. Eu preciso entender os benefícios, entender o que me traz de demandas e preciso tomar decisões.

Nesse último ano, muita coisa tem mudado do lado de cá, com o Docker Definitivo, Jornada Docker de A a Z, em breve com o O Código .NET, ou o *.pro, isso tem demandado uma nova visão sobre a minha infraestrutura e estou começando começando a estruturar as mudanças para o futuro. E é preciso conhecer esses aspectos para aprender a decidir, seja para meu próprio cenário de uso, ou para meus clientes ou para meus alunos.

As decisões que eu exploro aqui são decisões para o mercado comum, SMB’s, 90% das empresas. Não para grandes empresas e corporações como a XP, que é o caso do Wiluey. As decisões que estou enlatando aqui estão para atender a empresas normais, com clientes médios, não instituições financeiras.

As decisões que vocês tomam em empresas grandes precisam ser pautadas nos problemas e necessidades que vocês possuem, e possivelmente uma tendência ao service mesh seja algo desejável em um parque complexo e grande. No entanto isso é exótico e é um problema de empresa grande, com centenas de desenvolvedores, isso não é um problema do mundo normal. No mundo cotidiano, Service Mesh é overdesign, é colocar o currículo à frente do requisito.

Esse papo me lembra Don’t Put Your Resume Ahead of the Requirements, primeiro capítulo de 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts.

Grande abraço!

Índice da Live do Youtube:

00:00 Boas vindas

01:04 Novidades – Azure na Prática e Eventos do .NET SP

02:30 Novidades – MVP Conf 2020

03:35 Novidades – Docker Definitivo

05:40 Novidades – NoSQL BR

07:34 Introdução XMLHttpRequest

14:19 SPA’s

17:40 API’s e seus requisitos (DDOS, WAF, Rate Limit, Contrato, Versionamento, Resiliencia, Escala, Escalabilidade, Monotoramento, Governança, Autenticação, Autorização, JWT, Detecção de Anomalias)

26:04 Proxy Reverso vs API Gateway vs API Manager

44:19 Proxy Reverso, parte fundamental de toda a internet como conhecemos hoje.

54:47 Web Servers – Apache, NGINX, IIS, Kestrel, Node

57:35 API Gateway

1:19:11 Versionamento de API’s e retrocompatibilidade

1:26:37 O Magic Quadrant da Gartner e o posicionamento do Kong

1:41:34 Kong vs Ocelot

1:49:41 API Gateway substituem proxy reversos? Faz sentido ter os 2 no mesmo stack?

1:55:24 Stackshare – Quem está usando Kong e para que serve saber quem está usando.

1:57:27 Plugins e o Hub de plugins do Kong

2:09:42 Setup e formas de instalar o Kong 2:15:14 UI e Comandos vs YAML e definições versionáveis

2:19:20 Demo

3:15:52 Perguntas e respostas e considerações finais.