Idioma: Português brasileiro
Uma aplicação está no ar. Mas por onde o tráfego entra?
Quem termina o TLS? A aplicação fica exposta diretamente? Quando surge uma segunda instância, quem distribui as requisições? E, quando os usuários estão espalhados pelo mundo ou aparecem dezenas de serviços, quando faz sentido colocar uma CDN, um API Gateway ou até um service mesh na arquitetura?
A proposta desta talk é olhar para essas tecnologias a partir de uma ideia simples: o proxy reverso é a base; o restante é especialização.
Load balancer, CDN e API Gateway continuam sendo proxies reversos na mecânica. O que muda é a responsabilidade que cada um acrescenta: distribuição de carga, distribuição geográfica, políticas de API e, no caso do service mesh, a mesma ideia aplicada ao tráfego entre serviços.
A talk acompanha uma aplicação crescendo e mostra esses componentes entrando conforme surgem problemas concretos: uma instância que não aguenta mais, usuários distantes, necessidade de autenticação e rate limiting, ou dezenas de serviços conversando entre si.
Em vez de decorar ferramentas, a ideia é sair entendendo qual problema cada camada resolve e quais são os sinais de que chegou a hora de evoluir, ou de que ainda não chegou.
Os conceitos são apresentados com diagramas animados, mostrando o tráfego acontecendo e as responsabilidades sendo adicionadas à arquitetura.
É comum aprender proxy reverso, load balancer, CDN e API Gateway como coisas diferentes. Aprende-se o nome, a ferramenta mais conhecida e alguns casos de uso. Mas, na prática, essas fronteiras não são tão claras.
Um load balancer L7 pode terminar TLS e fazer roteamento. Uma CDN também funciona como proxy reverso e pode aplicar políticas de segurança. Um API Gateway também termina TLS, roteia e pode fazer cache. Em produtos gerenciados de cloud, várias dessas responsabilidades aparecem juntas na mesma caixa, gerando questões de onde termina um e começa o outro.
A talk propõe um modelo mental mais simples: pensar primeiro na responsabilidade e só depois na ferramenta.
Tudo começa com um proxy reverso na frente da aplicação. Ele pode terminar TLS, esconder a origem, fazer cache e assumir parte do trabalho que antes ficava dentro da aplicação. Quando uma instância já não é suficiente, aparece a necessidade de distribuir carga e entra o load balancer. Quando os usuários estão espalhados pelo mundo, a mesma ideia de proxy aparece distribuída em vários pontos da rede com uma CDN. Quando o problema passa a ser autenticação, rate limiting, agregação e outras políticas de API, entra o API Gateway.
E quando o problema deixa de ser quem entra na aplicação e passa a ser como dezenas de serviços conversam entre si, a mesma ideia aparece novamente, o proxy reverso ao lado de cada serviço, formando um service mesh.
Serão apresentadas as necessidades de uma aplicação que cresce e assim cada nova camada aparece porque surgiu uma necessidade, e não porque a arquitetura "precisa" de mais uma tecnologia. Serão discutidos os pontos em que essas tecnologias se sobrepõem e por que produtos diferentes podem ocupar várias partes desse espectro ao mesmo tempo.
Na parte final, alguns cenários mostram essas decisões na prática: quando um NLB não resolve um problema de L7, quando uma aplicação em produção precisa deixar de depender de uma única instância, quando uma origem começa a sofrer com usuários espalhados pelo mundo e quando um API Gateway acaba virando um gargalo para o tráfego interno. Também há casos em que a melhor decisão é simplesmente não evoluir.
A ideia da talk é mostrar uma visão de que na hora de desenhar a arquitetura, não perguntar "qual ferramenta devo usar?", mas "qual problema apareceu e qual responsabilidade eu preciso colocar na borda?"
Platform Engineer/SRE e trabalha há mais de 15 anos com tecnologia, desenvolvimento e arquitetura, infraestrutura, confiabilidade e plataformas.