Desde do inicio da era digital para web, a maneira como os sistemas se comunicam passou por várias transformações. Na última década, particularmente a partir da metade dos anos 2000, vivenciamos um bum na utilização de APIs (Interfaces de Programação de Aplicativos). As APIs permitiram que aplicações independentes se conectassem e compartilhassem dados de forma fluida e segura, dando origem a uma onda de inovação e interconexão sem precedentes.
Na virada do milênio, em 2000, Roy Fielding apresentou uma tese de doutorado introduzindo o conceito de Representational State Transfer (REST) como um estilo arquitetural. Esta proposta foi incorporada ao protocolo HTTP
A natureza simples, porém poderosa, do REST começou a ganhar destaque ao longo da década, mas foi realmente nos anos 2010 que vimos uma adoção massiva do REST, levando ao declínio de padrões anteriores, como o SOAP. O protocolo REST, que utiliza padrões da web como HTTP e JSON, promoveu uma maior aceitação e implementação devido à sua simplicidade, até o presente momento, continua sendo o padrão dominante para serviços expostos na web.
Com o sucesso e a proliferação das APIs RESTful, a web começou a mudar. Empresas como Twitter, Facebook e Google amplamente adotaram e promoveram o uso de suas APIs, possibilitando a criação de uma infinidade de aplicações de terceiros e integrando-as em ecossistemas muito maiores.
A Era dos Proxies Reversos
O gerenciamento de tráfego na web para atender a grande demanda de APIs como citamos acima, teve que passar por uma série de transformações significativas ao longo das décadas. Em 1995, o Apache foi lançado e rapidamente se estabeleceu como o servidor web padrão, dominando a cena da internet no final dos anos 90 e início dos anos 2000. Entretanto, com a evolução das linguagens de programação e a necessidade de servidores de aplicação, em 1999 foi apresentado o Apache Tomcat, projetado para executar aplicações Java em ambiente web. Esta era também testemunhou o surgimento e a popularização das APIs, culminando na proliferação dos serviços baseados em nuvem.
Com essa rápida escalabilidade, houve a demanda por soluções mais performáticas e adaptadas às novas cargas de trabalho. Em 2004, o NGINX foi introduzido como uma alternativa leve ao Apache, e, com sua capacidade de lidar com um grande número de conexões simultâneas, viu seu pico de adoção nos anos 2010, superando muitos de seus concorrentes. Essa rápida ascensão e mudança no cenário tecnológico pressionaram os proxies reversos tradicionais a evoluir, enfrentando desafios adicionais e complexos apresentados pela era moderna da computação em nuvem com a gigante Amazon Web Services (AWS) iniciando em 2006 a pioneira e em seguida veio a Google Cloud Platform (GCP) em 2008 em 2010 Microsoft Azure.
Apache
Apache, surgindo nos primórdios da web, é mais do que um simples servidor. Com o mod_proxy, o Apache não apenas roteava o tráfego, mas também proporcionava balanceamento de carga. Esta capacidade inicial formou a base para o desenvolvimento subsequente de API Gateways.
A Apache Software Foundation, fundada em 1999, tem sido um farol de código aberto, e o servidor Apache é um testemunho disso.
Grandes empresas como IBM, Nokia e Salesforce usaram Apache em algum momento, evidenciando sua robustez.
Nginx
Nginx foi uma revolução. Sua arquitetura orientada a eventos permitiu que ele se destacasse em ambientes de alto tráfego.
Criado por Igor Sysoev em 2002, foi concebido como uma resposta às limitações percebidas no Apache.
Empresas como Netflix, WordPress e Zappos confiam no Nginx para servir bilhões de solicitações por dia.
Nginx trouxe um design orientado a eventos, tornando-o mais eficiente em ambientes com alto tráfego. Rápido e leve, ele logo se tornou uma escolha popular para proxy reverso, balanceamento de carga e cache de conteúdo.
Quando falamos que o Nginx ele é um proxy de "camada 7" ou um "proxy de aplicação", estamos nos referindo à sua capacidade de tomar decisões com base no conteúdo das mensagens HTTP/HTTPS. No entanto, com as capacidades de balanceamento de carga de TCP/UDP, ele também pode operar na camada 4 (camada de transporte).
Envoy
O Envoy é um servidor proxy de alto desempenho projetado para aplicações modernas orientadas a serviços, como microserviços. Foi originalmente desenvolvido pela Lyft, e posteriormente foi doado para a Cloud Native Computing Foundation (CNCF). Desde então, tem ganhado considerável tração e tornou-se uma parte central de muitas infraestruturas modernas de TI.
O Envoy foi introduzido pela primeira vez em 2016 pela Lyft para lidar com seus desafios específicos em escala, relacionados à decomposição de sua monolítica aplicação em microserviços.
O Envoy e o NGINX são ambos servidores proxy reversos de alto desempenho, e, em muitos cenários, podem ser usados de forma intercambiável. No entanto, eles têm origens e focos um pouco diferentes.
Linguagem Go e proxies reversos
A linguagem Go é conhecida por sua eficiência e capacidade de lidar com concorrência, o que a torna ideal para o desenvolvimento de proxies reversos e servidores web. Foi criada no Google por Robert Griesemer, Rob Pike e Ken Thompson e foi anunciada ao público em 2009. Desde então, ela ganhou uma adesão considerável no mundo do back-end.
A Concorrência Nativa em Go é usando goroutines, que são mais leves do que threads tradicionais. Isso permite que os desenvolvedores escrevam programas que lidam eficientemente com muitas tarefas simultâneas, tornando-a ideal para aplicações de rede, como proxies reversos, que podem precisar gerenciar muitas conexões simultâneas.
O Desempenho em Go é algo fascinante, é uma linguagem compilada, o que significa que o código é transformado diretamente em código de máquina. Isso garante que os programas escritos em Go tenham um desempenho comparável ao de linguagens como C e C++.
A Simplicidade e Legibilidade usada em Go foi projetada com uma sintaxe clara e um conjunto mínimo de recursos. Isso promove a escrita de código limpo e fácil de entender, facilitando a colaboração e a manutenção.
As Bibliotecas Padrão em Go são Robustas e muito poderosa, especialmente para tarefas relacionadas à rede e I/O. Isso facilita a construção de servidores web e proxies reversos sem a necessidade de bibliotecas externas.
A Distribuição Estática dos binários em Go é feita por padrão. Isso significa que, ao compilar um programa, todas as suas dependências são incluídas no binário final. Isso torna a distribuição e a implantação de aplicações Go extremamente simples, sem a necessidade de gerenciar dependências no ambiente de produção.
Aqui estão alguns proxies reversos escritos em Go:
.Caddy
Além de ser um servidor web, o Caddy é amplamente reconhecido por sua configuração automática de TLS. Lançado em abril de 2015.
.Traefik
Traefik é um proxy reverso moderno e um load balancer que facilita a implantação de microserviços. Lançado em 2014.
.GoProxy
É um proxy reverso simples escrito em Go, que pode ser usado para roteamento e balanceamento de carga. Foi lançado por volta 2013.
.Fabio
Fabio é um load balancer e proxy reverso rápido que se integra diretamente com o Consul para roteamento dinâmico e lançado em 2015.
Camada OSI ou TCP/IP
Proxies podem atuar em diferentes camadas do modelo OSI ou TCP/IP, dependendo da funcionalidade e design específicos da solução. No entanto, a maioria dos proxies reversos modernos, incluindo o NGINX e muitos escritos em Go, são projetados para operar primordialmente nas camadas de Transporte e Aplicação.
Modelo OSI (Open Systems Interconnection):
O Modelo OSI (Open Systems Interconnection) é um framework conceitual usado para compreender as interações de redes complexas. Ele divide as funções de comunicação de rede em sete camadas distintas, cada uma com um conjunto específico de responsabilidades. O propósito desse modelo é guiar os desenvolvedores de produtos e protocolos para que eles possam interoperar com produtos e protocolos de outros fabricantes. Em 1984 o modelo OSI foi formalmente aprovado.
Modelo TCP/IP
O Modelo TCP/IP, também conhecido como Modelo de Referência da Internet, é um framework mais simples e prático que o OSI, usado para descrever redes de computadores. Ele tem quatro camadas e foi desenvolvido junto com os protocolos que ele descreve, tornando-o extremamente relevante e aplicável ao mundo real da Internet. Em 1983 ARPANET migra oficialmente para o TCP/IP, solidificando sua posição como o conjunto padrão de protocolos para a Internet.
Modelo OSI:
Camada de Transporte (Layer 4)
O Proxies que operam nesta camada são frequentemente chamados de "proxies de camada 4" ou "load balancers de camada 4". Eles tomam decisões de roteamento baseadas principalmente em informações da camada de transporte, como endereços IP de origem e destino e números de portas. Um exemplo é o balanceamento de carga TCP/UDP.
Camada de Aplicação (Layer 7)
O Proxies que operam nesta camada são frequentemente chamados de "proxies de camada 7" ou "load balancers de camada 7". Eles tomam decisões de roteamento baseadas no conteúdo das mensagens na camada de aplicação. Para o tráfego HTTP/HTTPS, isso pode incluir o host, URL, cabeçalhos HTTP e até mesmo o corpo da mensagem. Estes proxies podem inspecionar, modificar e tomar decisões baseadas no conteúdo do tráfego.
Modelo TCP/IP:
Camada de Transporte
O Correspondente à Camada de Transporte no modelo OSI.
Camada de Aplicação
Inclui as funções das camadas de Aplicação, Apresentação e Sessão do modelo OSI. Proxies que operam aqui podem inspecionar e tomar decisões baseadas no conteúdo das mensagens.
A Ascensão dos API Gateways
Essa rápida adoção das APIs levou a novos desafios. À medida que as organizações começavam a oferecer múltiplas APIs, surgiu a necessidade de um sistema centralizado para gerenciar, monitorar e garantir a segurança dessas interfaces. Além disso, com a escalada de microserviços nos anos 2010 e 2020, o tráfego interno entre serviços em ambientes de nuvem também precisava ser eficientemente roteado e gerenciado.
O termo "API Gateway" tornou-se proeminente principalmente na década de 2010 com a ascensão dos microserviços e da computação em nuvem. Antes disso, as APIs existiam, e as organizações as usavam, mas o conceito de um "gateway" dedicado para gerenciar essas APIs, especialmente em uma arquitetura de microserviços, era menos comum.
A necessidade de um API Gateway surgiu de vários desafios associados ao desenvolvimento e operação de microserviços, incluindo:
Roteamento e Descoberta de Serviço
Como direcionar uma chamada de API para o serviço correto em um ambiente onde você tem muitos serviços.
Limitação de Taxa
Proteger os serviços de serem sobrecarregados por demasiadas chamadas.
Autenticação e Autorização
Verificar quem está fazendo a chamada e o que eles têm permissão para fazer.
Transformação de Requisições e Respostas
Converter entre diferentes formatos ou versões de API.
As primeiras soluções de API Gateway começaram a aparecer no mercado por volta de 2010-2012. A ascensão da computação em nuvem e plataformas como a AWS também desempenharam um papel fundamental na popularização do conceito. Por exemplo, em 2015, a AWS lançou o Amazon API Gateway, um serviço totalmente gerenciado para criar, publicar, manter, monitorar e proteger APIs.
No entanto, é importante notar que, embora o termo "API Gateway" tenha ganhado popularidade durante esse período, o conceito fundamental de intermediar e gerenciar chamadas de API não é novo e tem raízes em tecnologias anteriores, como os Enterprise Service Buses (ESBs) e soluções de integração.
API Gateways Kong
Um dos primeiros e mais notáveis API Gateways de código aberto a ganhar reconhecimento no mercado foi o Kong. Foi lançado em 2015 pela empresa Mashape (agora conhecida como Kong Inc.).
O Kong foi desenvolvido inicialmente como uma camada em cima do servidor NGINX e utilizou sua capacidade de processamento para lidar com o tráfego de API. Com uma arquitetura modular e suporte a plugins, o Kong ofereceu desde o início uma variedade de funcionalidades como limitação de taxa, autenticação, registro, transformações de solicitações/respostas e muitas outras.
Seu código aberto e capacidade de extensão rapidamente o tornaram popular entre as comunidades de desenvolvedores e operações, e ele desempenhou um papel significativo na definição do mercado de API Gateway.
Existiram outros produtos e ferramentas antes do Kong, mas muitos deles eram proprietários ou não eram estritamente API Gateways na definição moderna. O Kong é frequentemente reconhecido por popularizar o conceito e fornecer uma solução robusta e de código aberto para a comunidade.
O Kong foi desenvolvido principalmente em Lua, utilizando o framework LuaJIT (Just-In-Time Compiler para Lua). Ele é construído em cima do servidor NGINX, aproveitando a capacidade de processamento de alta performance do NGINX com a flexibilidade do Lua através do módulo ngx_http_lua_module, que permite a execução de código Lua dentro do contexto do NGINX. Esse design permite ao Kong ser altamente extensível através de plugins.
API Gateways desenvolvidos em Go
O KrakenD é uma API Gateway de alto desempenho que ajuda a agregar, transformar e filtrar os dados antes que eles cheguem ao cliente, otimizando assim o consumo de APIs.
O Gloo é uma API Gateway e proxy reverso baseado no Envoy. É otimizado para casos de uso centrados em microserviços, funções e aplicações em contêiner. Criado pela Solo-io, Gloo é um "Next Generation API Gateway" e ingress controller. Ele foi projetado para ajudar a conectar, proteger e controlar o tráfego de serviços em ambientes de microserviços e aplicativos monolíticos.
O Tyk é um API Gateway de código aberto e gerenciamento de API que também oferece uma versão comercial. Ele oferece muitos recursos avançados, incluindo quotas, limitação de taxa, e autenticação.
API Gateways CLOUD
As principais provedoras de nuvem têm suas próprias soluções de API Gateway, otimizadas para integrar-se perfeitamente com seus respectivos ambientes e serviços de nuvem. Tornou-se um grande negócio e a criação de produtos voltados ao gerenciamento e escala quando o assunto é desenvolvimento de APIs.
Amazon Web Services (AWS)
Na AWS usamos API Gateway Este serviço permite que os desenvolvedores criem, publiquem, mantenham, monitorizem e protejam APIs de forma escalável. É capaz de processar milhares de chamadas de API simultaneamente e suporta APIs RESTful e WebSockets. Também se integra facilmente com outros serviços da AWS, como AWS Lambda.
Google Cloud Platform (GCP)
A solução Apigee Adquirida pela Google em 2016, a Apigee oferece uma plataforma de gerenciamento de ciclo de vida completo para APIs, permitindo análises, desenvolvimento de portal de desenvolvedor, e outras características avançadas-Cloud Endpoints: É uma solução mais leve que a Apigee e é mais integrada com o ambiente de nuvem da Google. Permite que os desenvolvedores criem, implantem, protejam e monitorem APIs dentro do GCP.
Microsoft Azure
A solução Azure API Management: Esta é a solução da Microsoft para o gerenciamento de APIs na nuvem Azure. Ele fornece ferramentas para criar, gerenciar e analisar APIs, e também permite a criação de portais para desenvolvedores e outros recursos avançados.
Estas soluções diferem em características e capacidades, mas todas têm o objetivo comum de fornecer ferramentas robustas para o gerenciamento, proteção, e análise de APIs em ambientes de nuvem cada um com suas particularidades e características.
Conclusão
À medida que adentramos na era da digitalização, a conectividade entre sistemas e aplicações continua a se expandir em complexidade e escala. No centro desta revolução digital, os proxies e API Gateways emergem como componentes críticos para garantir que as comunicações sejam ágeis, seguras e eficientes.
As soluções modernas de proxies, como o Envoy, e os API Gateways construídos em linguagens de alto desempenho como Go, são peças de uma engrenagem bem maior e que vivenciou toda evolução contínua desta tecnologia. Eles não apenas atendem às necessidades atuais, mas também são projetados com flexibilidade para se adaptarem às mudanças futuras.
O uso crescente de microserviços, contêineres e soluções de nuvem amplifica ainda mais a necessidade de proxies eficientes e API Gateways robustos. Eles não só permitem a integração eficaz de múltiplos serviços, mas também oferecem segurança, balanceamento de carga, rate limit, transformações de requisições, autenticações e muito mais.
Enquanto olhamos para o futuro, é evidente que a demanda por proxies e API Gateways só aumentará. Assim, seja você um desenvolvedor, arquiteto ou entusiasta da tecnologia, é fundamental manter-se atualizado sobre estas ferramentas e práticas. Afinal, eles serão os pilares que sustentarão a próxima geração de aplicações e sistemas interconectados.
Top comments (0)