O passado, presente e futuro das API Gateways

A Internet se tornou uma parte onipresente das vidas das pessoas nas últimas décadas. A crescente variedade de serviços online tem impulsionado o desenvolvimento de aplicações web cada vez mais sofisticadas. A evolução dessas aplicações tem motivado a evolução na borda do data center - a pilha de hardware e software que conecta as aplicações web à internet, e o local no qual um cliente começa a interagir com os serviços de negócio de uma empresa. A borda evoluiu de simples balanceadores de carga de hardware para uma pilha completa de proxies de hardware e software que incluem API gateways, redes de entrega de conteúdo (Content Delivery Network - CDN) e balanceadores de carga. Neste artigo, mostraremos a evolução da borda do data center à medida que a arquitetura e os fluxos de trabalho das aplicações evoluíram.

Os primórdios da Internet

Em meados da década de 1990, a arquitetura de aplicações web estava engatinhando. O Ruby on Rails, o Django e outras estruturas web não haviam sido desenvolvidos e tecnologias como Apache Struts e J2EE estavam começando a engrenar.

A arquitetura clássica de múltiplas camadas, consistindo de uma camada de banco de dados, uma de aplicação e outra de apresentação (conhecida como MVC, model, view, controller), era de fato a arquitetura das aplicações naquele momento. A arquitetura multicamadas era escalável horizontalmente, ou seja, mais instâncias da arquitetura da aplicação (application) e camada de apresentação (view) poderiam ser adicionadas quando o tráfego aumentava.

Conectar múltiplas instâncias de uma aplicação ou camada de apresentação na internet necessitava da primeira iteração da borda do data center: Um balanceador de carga.

Naquele tempo, o balanceador de carga era responsável pelo roteamento de tráfego entre as instâncias da aplicação, garantindo disponibilidade e escalabilidade. O balanceador de carga era tipicamente um appliance de hardware, até que o lançamento do HAProxy em 2001 começou a popularizar o conceito de balanceador de carga por software.

Web 2.0

Darcy Dinucci cunhou o termo Web 2.0 em 1999 para se referir à evolução da Internet de uma mídia de caminho único para uma na qual os usuários podem interagir com os websites. Ao invés de serem consumidores passivos do conteúdo, os sites da Web 2.0 poderiam ter usuários contribuindo ativamente e se engajando com os demais.

Desenvolvimento com técnicas de AJAX (Asynchronous JavaScript and XML) se tornaram onipresentes durante esta época. Desacoplando a troca de dados da apresentação, o AJAX criou experiências de navegação mais ricas para os usuários finais. Esta arquitetura também criou clientes mais "comunicativos", porque podem constantemente enviar e receber dados de uma aplicação web.

Adicionalmente, o e-commerce começava a decolar na mesma época, e pela primeira vez, a transmissão segura de informação de cartão de crédito se tornou a principal preocupação. O Netscape introduziu o Secure Socket Layer (SSL), que evoluiu depois para o Transport Layer Security (TLS), para garantir conexões seguras entre cliente-servidor.

Essas mudanças na tecnologia de rede (comunicações encriptadas e muitas requisições em conexões de longa duração) orientaram uma evolução da borda a partir de balanceadores de carga baseados em hardware/software para Application Delivery Controllers (ADCs) mais especializados. Os ADCs incluem uma variedade de funcionalidades para o que chamamos de acelerador de aplicação, incluindo SSL offload, caching e compressão. Esse aumento na funcionalidade também significava um aumento na complexidade da configuração. Surgiram uma variedade de configurações proprietárias padronizadas, por exemplo o VCL e o SSI. O balanceador de carga não era mais apenas um balanceador de carga.

A era do web-scale

No começo da década de 2010, um grande número de empresas cloud-first experimentaram um crescimento exponencial na sua base de usuários. O software por trás destas empresas era originalmente arquitetado com aplicações web monolíticas usando frameworks de fácil uso como Ruby on Rails e Django. As bases de usuários cresceram para números astronômicos, e foi neste momento que essas empresas descobriram os problemas de escala na web, e também perceberam que necessitavam de uma arquitetura diferente para passar por este obstáculo. Uma antiga falha do Twitter, que mostrava a imagem de uma baleia quando o site não suportava a quantidade de usuários, foi possivelmente o exemplo mais icônico do desafio enfrentado por essas empresas quando tentavam criar aplicações de escala na web pela primeira vez.

Empresas como Twitter, Facebook e New Relic começaram a refatorar partes chave da funcionalidade dos seus monólitos em serviços implantados independentemente. Implantando funcionalidades críticas do negócio como serviços, essas empresas estão prontas para escalar de maneira independente e gerenciar diferentes aspectos de sua aplicação geral. O tráfego para esses serviços independentes eram roteados através do monólito. Quaisquer mudanças no roteamento significava que muito provavelmente os desenvolvedores tinham que fazer o deploy do monolito inteiro novamente. Isso era um gargalo para a velocidade da mudança.

A ascenção da API gateway

Essas empresas e muitas outras, compartilhavam suas descobertas com toda a comunidade de tecnologia. Muitos dos antigos engenheiros destas empresas foram trabalhar em outras ou fundaram startups baseadas em seus conhecimentos. Um dos conhecimentos dessas arquiteturas era bastante óbvio: Para os serviços refatorados, o monólito estava funcionando apenas como um roteador.

Essa observação provocou o desenvolvimento dos antigos API gateways, que realizam a funcionalidade de roteamento que existia no monólito original, criando um ponto de entrada comum para a aplicação inteira. Funcionalidades transversais no nível da aplicação, como limitação de taxa, autenticação e roteamento, foram centralizadas na API gateway. Isso reduziu a quantidade de funcionalidades duplicadas necessárias em cada um dos serviços.

A era Cloud-Native: Os microservices

Hoje, nós estamos na era cloud-native. A chave para este novo momento é a proliferação dos microservices, que representam outra mudança na arquitetura das aplicações. Cada microservice representa uma função auto-contida do negócio, e é desenvolvida e lançada independentemente de outros microservices de uma aplicação. Desacoplando os ciclos de desenvolvimento, os microservices permitem que as empresas escalem com mais eficiência os processos de desenvolvimento de software para a nuvem.

Considerando que os microservices podem ser implantados em múltiplos ambientes, como máquinas virtuais, servidores cloud dedicados, containers, e como funções, as APIs de gateway têm um papel crítico no roteamento de tráfego para o microservice correto.

As APIs gateway evoluíram para atender as necessidades dos microservices em algumas áreas diferentes. Em particular, as APIs gateway modernas:

• Continuam a dar suporte às questões transversais no nível da aplicação como autenticação, limitação de taxas, publicação de APIs e coleta de métricas;
• Têm incorporado funcionalidades de gerenciamento de tráfego que historicamente são vistas nos Application Delivery Controllers. Isso inclui balanceamento de carga avançado, caching, e semântica de resiliência, como repetições e tempos limite automáticos;
• Dão suporte a descoberta de serviço em tempo real. Cada vez mais, os microservices são implantados em ambientes efêmeros como Kubernetes ou serverless. Portanto, descobrir em tempo real a localização da rede de todas as instâncias de um microservice é algo crítico.

Desenvolvimento do ciclo completo: O fluxo de trabalho do Cloud-Native

Os microservices não são apenas uma mudança na arquitetura das aplicações, são também uma mudança no fluxo de trabalho do desenvolvimento. Com os microservices, as equipes individuais são empoderados para entregar o software. Mais importante, essas equipes são responsáveis pelo ciclo de vida completo do desenvolvimento, que abrange desde o projeto, passando pelo desenvolvimento, teste, implantação, chegando até a release. Algumas empresas colocam essas equipes como em um plantão rotativo (vulgo, "você construiu, você executa"). Esse modelo de desenvolvimento, popularizado pelo nome ciclo completo de desenvolvimento da Netflix é uma mudança transformacional em como o software é desenvolvido e distribuído.

Essa mudança no fluxo de trabalho também possui implicações para a borda do data center. Os API gateways (e outros elementos da pilha da borda) precisam não só se adaptar à arquitetura dos microservices, mas também é necessário que a borda esteja acessível e gerenciável pelas equipes do ciclo completo de desenvolvimento. As duas principais considerações para o gerenciamento da borda na atual era cloud-native são as seguintes:

Consideração 1: Escalar a release e a implantação

A implantação é o processo de instalar uma atualização de código na infraestrutura de produção. O release é o processo de realmente expor uma atualização de código para os usuários finais em produção. As empresas podem tratar ambos ao mesmo tempo (chamado de modelo release-in-place, quando a release é feita junto à implantação), o que expõe os riscos da implantação aos usuários da produção. Por exemplo, um parâmetro obrigatório de configuração pode causar uma interrupção visível aos usuários finais neste modelo release-in-place. Com a separação em duas fases, o risco da implantação nunca fica exposto para o usuário final.

A borda do data center tem uma função crucial na release. Com o controle do fluxo do tráfego para versões específicas dos microservices, na realidade a borda é responsável por fazer o release de uma versão para os usuários finais. Além disso, os serviços modernos da borda suportam estratégias para lançamento incremental como o lançamento canary (no qual um percentual do tráfego vai para uma nova atualização com o passar do tempo), ou planos de lançamento blue/green.

As equipes de ciclo completo de desenvolvimento precisam ter controle sobre a borda para orquestrar o release. Esses controles incluem o roteamento (qual versão de um serviço deve receber o tráfego de produção) tanto quanto controles mais específicos como roteamento ponderado (necessário para o lançamento canary) e sombreamento de tráfego (criar uma cópia do tráfego para uma versão teste de um serviço com este propósito). Ao dar às equipes de desenvolvimento a capacidade de gerenciar a release e a implantação, as empresas podem escalar esses processos para suportar aplicações ainda mais complexas.

Consideração 2: Monitorando o espectro dos serviços

As equipes de ciclo completo de desenvolvimento têm responsabilidade operacional por seus microservices. Uma crítica a este sucesso é a visibilidade em tempo real do desempenho destes serviços. A borda fornece informações importantes sobre o comportamento em virtude da análise de todo o tráfego que flui para e a partir de um microservice. Isso permite que a borda reporte sobre métricas como latência, taxa de transferência e taxas de erros, fornecendo informações sobre a saúde da aplicação.

Essas métricas precisam ser correlacionadas com as métricas coletadas em outras partes da aplicação para antecipar uma visão completa do comportamento. Essa correlação ocorre hoje ao introduzir identificadores de correlação nas requisições de dados usando um padrão como o OpenTracing. Por fim, todas essas métricas coletadas pela pilha de bordas moderna precisam ser expostas a essas equipes de desenvolvimento de ciclo completo como dashboards configuráveis.

Gerenciamento de políticas da borda

Dada a importância da borda nos fluxos de trabalho modernos no cloud-native, como podemos fazer as equipes de ciclo de desenvolvimento completo gerenciarem a borda? Infelizmente, todos os componentes da pilha da borda têm sido tradicionalmente gerenciado pelo pessoal de operações, e interfaces operacionais não são adequadas para os desenvolvedores da aplicação nas equipes de ciclo completo de desenvolvimento. Além disso, componentes da borda são frequentemente operados isoladamente, sem uma interface operacional coesa. Depois de tudo, os desenvolvedores de ciclo completo não são operadores full-time, ou seja, eles precisam apenas estar preparados para operar tudo que for necessário da borda para suas necessidades específicas.

Felizmente, o ecossistema Kubernetes pode fornecer orientação e inspiração. No modelo Kubernetes, usuários declaram suas intenções como sendo políticas por meio de uma linguagem de configuração com um arquivo YAML. Diferentemente das interfaces REST ou baseadas em usuário, o modelo declarativo permite o uso de políticas codificadas e gerenciadas via sistema de controle de fonte (como GitOps). Isso fornece auditabilidade, versionamento e transparência para todos os usuários. Além disso, o modelo Kubernetes suporta políticas descentralizadas, onde múltiplos arquivos de políticas são agregados em uma configuração global de política para o cluster como um todo. API gateways estão também adotando este modelo, como mostrado pelo desenvolvimento de controladores de entrada para o Azure Application Gateway e Kong. Enquanto esses produtos começaram com APIs REST para gerenciamento, a mudança para uma paradigma declarativo está lentamente levando esta abordagem para o desuso. Além disso, cloud-native gateways mais novos como o Ambassador Edge Stack parecem que foram projetados com este paradigma em mente.

Estender esse modelo de configuração descentralizada e declarativa para a borda é importante para as equipes de desenvolvimento de ciclo completo. Cada equipe pode manter sua própria política de borda, independente das demais. Essa política pode ser gerenciada no sistema de controle de versão juntamente com o código para o microservice. Isso permite que a política seja gerenciada como parte do processo de desenvolvimento atual, ao invés de ser uma configuração adicional e separada que precisa ser gerenciada.

Sumário

Ao longo das décadas, a borda tem evoluído de um simples balanceador de carga para uma pilha completa de software e hardware que inclui balanceadores de carga, API gateways, e muito mais. Essa evolução tem sido orientada pela arquitetura de aplicação e, mais recentemente, pelo fluxo de trabalho do desenvolvimento da aplicação.

As arquiteturas cloud-native atuais exigem uma pilha de borda que é acessível para as equipes de ciclo completo de desenvolvimento. Com a exposição declarativa das funcionalidades completas da borda, configuração descentralizada, equipes de ciclo completo de desenvolvimento podem tirar vantagem da borda para acelerar os fluxos de trabalho de desenvolvimento. Isso inclui a melhora na observabilidade, bem como o desacoplamento entre release e implantação. Por fim, isso torna as iterações mais rápidas, aumentando a estabilidade das releases, assim como aumentando o valor entregue aos consumidores.

Sobre o autor

Richard Li é o co-fundador e CEO da Datawire, que fornece várias ferramentas open source populares para acelerar o desenvolvimento no Kubernetes, incluindo Telepresence (desenvolvimento local) e Ambassador API Gateway. Richard é um veterano de múltiplas startups de tecnologias incluindo Duo Security, Rapid7 e Red Hat. Ele é reconhecido como um expert em Kubernetes e microservices, e tem sido palestrante em várias conferências incluindo ApacheCon, Microservices Practitioner Summit, KubeCon e O'Reilly Velocity. Ele é bacharel e possui mestrado em ciência da computação pelo MIT.