Atores de gateway distribuído: a evolução do gerenciamento de APIs

Por Rajesh Narayanan

Revisado por e com contribuições de: Ian Smith, Sam Bisbee, Andrew Stiefel, Lori MacVittie, Mike Wiley e outros.

Opinião do Escritório do CTO da F5

A equipe do Office of the CTO da F5 vem explorando há mais de um ano o campo tecnológico relacionado às APIs. Este novo white paper dá continuidade aos nossos esforços para compreender o ecossistema de APIs em constante evolução.

Os desafios que detalhamos no gerenciamento da proliferação de APIs levarão a desafios relacionados à proliferação de gateways de API, e as abordagens tradicionais para lidar com esses desafios não serão suficientes. Embora tecnologias de grafos como o GraphQL sejam muito promissoras para controlar a complexidade associada às APIs, elas são apenas parte da solução, pois os desafios vão além da conectividade, da segurança e do roteamento. A abordagem correta, baseada em quase trinta anos de experiência no dimensionamento de sistemas e aplicações, fundamenta-se em uma arquitetura distribuída — e não federada — que utiliza o GraphQL, mas não depende exclusivamente dele.

Este artigo explora uma abordagem de arquitetura distribuída para enfrentar os desafios da proliferação de gateways de API.

Resumo

A economia digital será impulsionada por APIs, dando origem a uma economia orientada por APIs. Após a publicação do white paper sobre a proliferação de APIs, buscamos entender como eliminar ou mitigar o impacto da proliferação de APIs. Embora o GraphQL parecesse promissor para reduzir as consequências dessa proliferação, ele tende a atribuir aos desenvolvedores a responsabilidade de reescrever grande parte da base de código de suas APIs. No entanto, uma perspectiva emergente sobre o GraphQL é sua capacidade de ser usado como um agente de gateway eficaz. O agente de gateway é uma função ou um processo criado próximo ao cliente que inicia uma solicitação de API. Esse agente atua como o gateway de API inicial que encerra a solicitação. Ele também pode ser efêmero, podendo ser destruído após atender à solicitação.

Além de desenvolvedores e equipes de operações priorizarem o gerenciamento de APIs em vez de gateways de API, também identificamos o problema da proliferação de gateways de API decorrente da proliferação de APIs. Do ponto de vista do desenvolvedor, a principal preocupação é garantir que a API funcione corretamente e em tempo hábil. Por outro lado, a equipe de operações está mais focada em aspectos como descoberta, segurança, usabilidade e controles de acesso. Como os gateways de API são hoje um componente essencial da infraestrutura de APIs, ficou evidente que a proliferação de APIs aumenta a implantação de gateways de API, levando à proliferação de gateways de API.

O futuro da arquitetura de APIs precisa evoluir para comportar a proliferação de APIs e, ao mesmo tempo, simplificar a implantação e as operações. A arquitetura proposta representa o próximo estágio de evolução dos padrões de design de gateways de API. Embora o GraphQL não seja um elemento central da arquitetura nem uma necessidade, ele pode aprimorar o padrão de ator de gateway.

Resumo

O ecossistema de gerenciamento de APIs deve deixar de gerenciar gateways de API monolíticos e adotar uma abordagem mais moderna de design de sistemas. Isso resultará em um ecossistema de gerenciamento de APIs mais ágil e eficaz.

Proliferação de gateways de API – Gerenciando monólitos distribuídos

A proliferação de APIs, que já é um desafio na economia de APIs, também resulta na proliferação de gateways de API, uma situação em que o gerenciamento de APIs se tornou incontrolável devido à diversidade de tecnologias dos fornecedores de gateways de API e às equipes com abordagens próprias que gerenciam esses gateways. Estamos em um ponto de inflexão nas arquiteturas de API, pois o gateway de API legado (API-GWs) — uma camada de software dedicada que atua como ponto de entrada para chamadas de API — já não é suficiente para gerenciar a escala e a complexidade do ecossistema de APIs emergente.

A Figura 1 ilustra como passamos do gerenciamento da proliferação de APIs para o gerenciamento da proliferação de gateways de API.

Figura 1: Da proliferação de APIs à proliferação de gateways de API

O padrão de design acima remete a um plano de controle centralizado, com os gateways de API formando o plano de dados distribuído, conforme mostrado na Figura 2.

Os gateways de API são um componente essencial das arquiteturas de software modernas, pois fornecem um ponto central de controle e segurança para as APIs. No entanto, à medida que o número de recursos oferecidos pelos gateways de API aumentou, eles se tornaram cada vez mais complexos e difíceis de gerenciar. Em muitos casos, esses gateways evoluíram para sistemas monolíticos, com uma ampla variedade de funcionalidades reunidas em um único pacote.

Figura 2: Gerencie monólitos distribuídos

Embora o gerenciamento de vários gateways possa parecer um design distribuído, na prática, ele não chega a ser uma distribuição de fato. Isso ocorre porque os gateways ainda são fortemente acoplados, compartilhando recursos e configurações difíceis de separar. Como resultado, muitas empresas acabam gerenciando monólitos distribuídos e todos os desafios decorrentes disso.

Arquiteturas legadas de gateways de API

A Figura 3 mostra a arquitetura dos gateways de API existentes. As solicitações de API originadas no cliente são primeiro transmitidas por uma rede compartilhada ou dedicada, passando por um firewall antes de chegar ao gateway de API. O gateway de API, que atua como um proxy reverso, encaminha então o tráfego para a carga de trabalho da API.

Figura 3: Arquiteturas legadas de gateway de API

O API-GW legado se torna um gargalo no gerenciamento de APIs quando gateways de API são implantados em toda a empresa ou quando as cargas de trabalho de API são transferidas operacionalmente entre regiões, zonas, várias nuvens ou para a borda, ao mesmo tempo que se lida com a proliferação de APIs. Vários API-GWs são criados por diferentes equipes sem um ponto único de gerenciamento e controle corporativo. Se um serviço de API ou um grupo deles for transferido para uma infraestrutura diferente (na nuvem ou não), a equipe de operações deverá dispor de um método para migrar todos os aspectos do gerenciamento de APIs — registro, descoberta, autenticação, rede, segurança e políticas de governança, risco e conformidade (GRC).

A arquitetura apresentada na Figura 3, portanto, não é escalável nem viável no longo prazo, pois, com o tempo, leva ao gerenciamento de monólitos distribuídos (Figura 2).

Há dois problemas que criam o gargalo no gateway de API: (1) a proliferação de fornecedores de gateways de API e (2) a necessidade de escalar continuamente à medida que uma empresa passa a ter mais aplicações em execução em mais ambientes.

1. Proliferação de fornecedores de gateways de API: Lidar com a proliferação de fornecedores de gateways de API é um desafio humano, pois pode ser difícil convencer todas as equipes a adotar um único fornecedor de gateway de API, e migrar para um novo fornecedor pode ser uma tarefa trabalhosa. Como resultado, as organizações acabam gastando tempo e recursos gerenciando vários fornecedores de gateways. Embora esse problema possa ser resolvido, isso talvez não seja totalmente viável na prática.
2. Escalabilidade de aplicações: Escalar aplicações é um desafio quando elas precisam atender a mais usuários em um único local ou ser implantadas em vários locais. Isso exige que a aplicação seja escalada horizontal ou verticalmente. No entanto, à medida que a aplicação é escalada, os gateways de API também precisam ser escalados e, em alguns casos, implantados em vários locais para viabilizar a escalabilidade com base nos padrões de arquitetura atuais. Isso pode tornar o gerenciamento operacional dos gateways de API mais complexo.

Solução: um padrão de ator de gateway distribuído

A Figura 4 apresenta um padrão de atores de gateway distribuídos para lidar com a proliferação de gateways de API. Embora o padrão distribuído em si não seja novo, este artigo o formaliza no contexto de gateways de API. Os clientes iniciam a solicitação de API. Os atores de gateway distribuídos são efêmeros e instanciados sob demanda, o mais próximo possível do cliente. Cabe à camada de transporte da API enviar a solicitação de API do ator de gateway para o gateway de API simplificado, que então encaminha a solicitação para a carga de trabalho de API apropriada. Embora o suporte a GraphQL nos atores distribuídos seja mais um detalhe do que um requisito para o funcionamento desse padrão, ele permite oferecer recursos como a orquestração de serviços. Assim, em vez de criar uma nova camada de orquestração de serviços, o GraphQL poderia fornecer esse suporte.

Figura 4: Atores de gateway distribuídos baseados em GraphQL

Para esclarecer, o fluxo de tráfego ocorre da direita para a esquerda. Ou seja, os clientes estão à direita, e as solicitações à API são iniciadas pelo cliente, conforme mostrado na Figura 5.

Figura 5: O tráfego flui do cliente (à direita) para a carga de trabalho da API (à esquerda)

Está surgindo um padrão de implantação que utiliza atores de gateway para substituir ou reduzir a dependência excessiva de gateways de API no gerenciamento de APIs dentro de uma empresa e entre diferentes empresas. Embora o GraphQL não seja necessário para a arquitetura, sua introdução é oportuna, pois o ator de gateway é o mecanismo adequado para oferecer suporte ao GraphQL.

O papel dos gateways de API no gerenciamento de APIs

Para entender melhor os gateways de API, é importante primeiro analisar os diversos componentes da infraestrutura moderna de gerenciamento de APIs.

Infraestrutura e funções de gerenciamento de APIs

A Figura 6 apresenta uma representação visual abrangente dos diversos recursos e componentes essenciais ao gerenciamento de APIs. Além dos gateways de API, necessários para rotear e gerenciar o tráfego direcionado aos serviços de backend, há vários outros componentes importantes de infraestrutura. Entre eles, podem estar soluções de autenticação, limitação de taxa, armazenamento em cache e malha de serviços, entre outras. Ao incorporar esses recursos, as organizações podem obter maior controle sobre suas APIs, reforçar a segurança e otimizar o desempenho.

Figura 6: Recursos de gerenciamento de APIs e infraestrutura

Recursos comuns de gateways de API

Vamos examinar os recursos mais conhecidos e comuns dos gateways de API:

1. Roteamento: Encaminha as solicitações ao serviço de backend apropriado com base no caminho ou no conteúdo da solicitação.
2. Autenticação e autorização: Autentica e autoriza solicitações como um único ponto de entrada, garantindo que apenas clientes autorizados possam acessar os serviços de backend.
3. Limitação de taxa: Limita a frequência com que os clientes podem fazer solicitações às APIs subjacentes, evitando o uso excessivo e protegendo os serviços de backend contra sobrecarga.
4. Cache: Armazena em cache as respostas das APIs subjacentes, reduzindo o número de solicitações aos serviços de backend e melhorando o desempenho.
5. Tradução de protocolos: Faz a tradução entre diferentes protocolos, como HTTP e WebSockets, permitindo que os clientes acessem as APIs subjacentes usando diferentes protocolos.
6. Balanceamento de carga: Distribui as solicitações entre vários serviços de backend, melhorando a escalabilidade e a confiabilidade.
7. Segurança: Lida com tarefas de segurança, como criptografia e descriptografia, para garantir que os dados sejam transmitidos com segurança.
8. Análise e monitoramento: Rastreia e relata métricas de uso e informações sobre erros, oferecendo visibilidade sobre como o sistema está sendo utilizado e ajudando a identificar gargalos de desempenho e erros.
9. Versionamento: Gerencia o versionamento das APIs subjacentes, permitindo que os clientes acessem diferentes versões da API de acordo com suas necessidades.
   
10. Descoberta de serviços: Descobre os serviços de backend disponíveis e encaminha dinamicamente as solicitações para eles, permitindo uma descoberta de serviços mais dinâmica e flexível.

Contexto: foco nos gateways de API

Após analisar os recursos da infraestrutura de gerenciamento de APIs, identificamos a necessidade de compreender melhor o papel dos gateways de API e explorar alternativas ao atual design monolítico de gateway de API.

Com o crescimento do número de APIs já levando à proliferação de APIs e de gateways de API, um número cada vez maior de clientes está se tornando móvel ou altamente distribuído, e a infraestrutura computacional passou a estar disponível em todos os lugares, inclusive na borda. Portanto, precisamos de uma abordagem que possa melhorar a agilidade, a flexibilidade, a escalabilidade, o desempenho e a segurança do ecossistema de APIs.

Essa nova abordagem exige um design simplificado, capaz de aproveitar plenamente os benefícios de uma arquitetura verdadeiramente distribuída.

Gateways de API

Analisamos mais a fundo a funcionalidade e o escopo de um gateway de API para identificar suas nuances e limitações.

Um gateway de API é um componente essencial da infraestrutura atual de gerenciamento de APIs. Em sua essência, o gateway de API é um proxy reverso: ele atua como intermediário entre os clientes e os serviços de backend, executando diversas tarefas na solicitação recebida. Por exemplo, o gateway pode realizar autenticação, limitar a taxa de requisições, rotear solicitações, aplicar políticas de segurança, monitorar e gerenciar o versionamento antes de encaminhar a solicitação a um serviço de backend apropriado. Depois que o serviço de backend processa a solicitação e retorna uma resposta, o gateway de API pode executar tarefas como armazenamento em cache, tradução de protocolos e tratamento da resposta antes de encaminhá-la de volta ao cliente.

À medida que o número de APIs cresceu, os gateways de API evoluíram para incluir diversas novas funcionalidades além do roteamento básico, tornando-se, na prática, sistemas monolíticos. Esses gateways agora gerenciam tarefas como autenticação e limitação de taxa para melhorar o desempenho e reduzir a carga sobre os serviços de backend. No entanto, mesmo com essa funcionalidade ampliada, os gateways de API continuam sendo um ponto único de acesso ao serviço de backend, o que pode representar desafios em ambientes altamente distribuídos.

Em particular, a ascensão das infraestruturas de nuvem, multinuvem híbrida e edge tornou mais difícil manter a agilidade, a segurança e a capacidade de gerenciamento com uma abordagem baseada em gateway de API. Como clientes, dispositivos e cargas de trabalho de aplicações podem estar distribuídos por uma ampla variedade de locais, um gateway de API talvez não seja adequado para oferecer o nível necessário de arquitetura compatível com ambientes de edge.

Desafios dos gateways de API

Como lidam com uma ampla variedade de tarefas e precisam se integrar a vários sistemas, os gateways de API geralmente são difíceis de implantar e gerenciar. Embora o gerenciamento de gateways de API possa ser complexo, ele é uma tarefa essencial para garantir a disponibilidade, a segurança e a escalabilidade de uma API. As empresas costumam usar ferramentas especializadas, como plataformas de gerenciamento de APIs, para gerenciar e monitorar seus gateways de API com mais eficiência.

A lista abaixo não é exaustiva, mas alguns dos elementos que contribuem para a complexidade dos gateways de API incluem:

1. Gerenciamento de configurações: os gateways de API geralmente têm uma ampla variedade de opções e definições de configuração que precisam ser gerenciadas e mantidas, como regras de roteamento, limitação de taxa e configurações de segurança. Gerenciar essas configurações pode ser complexo e demorado, especialmente à medida que aumenta o número de APIs subjacentes e clientes.
2. Integração com outros sistemas: Os gateways precisam se integrar a uma ampla variedade de outros sistemas, como sistemas de autenticação e autorização, balanceadores de carga e bancos de dados. Isso pode ser complexo, especialmente quando os sistemas subjacentes não estão bem integrados ou quando o gateway de API precisa lidar com vários protocolos ou formatos de dados. A situação se torna ainda mais problemática quando uma empresa tem várias implantações de gateways de API de diferentes fornecedores.
3. Escalabilidade e disponibilidade: os gateways de API precisam ser capazes de processar um grande volume de solicitações e garantir alta disponibilidade, o que pode ser complexo de gerenciar, especialmente quando há um grande número de serviços de backend e clientes.
4. Segurança: Como componentes essenciais da segurança de APIs, os gateways de segurança de APIs devem ser configurados e gerenciados para garantir a proteção de dados confidenciais e o controle de acesso. Isso pode ser complexo e exige monitoramento e gerenciamento contínuos.
5. Versionamento: À medida que o número de APIs subjacentes e clientes aumenta, pode se tornar cada vez mais difícil gerenciar diferentes versões da API e garantir que os clientes estejam acessando a versão correta.
6. Monitoramento e solução de problemas: os gateways de API podem coletar e gerar grandes volumes de dados. Em uma grande empresa, os gateways podem estar distribuídos em vários locais, dificultando a correlação de eventos que afetam a integridade geral da aplicação e a solução de problemas.

Proliferação de gateways de API

A proliferação de gateways de API refere-se à multiplicação de gateways de API independentes dentro de uma organização. Diferentes equipes ou unidades de negócios costumam criar suas próprias APIs, o que pode levar à criação de vários gateways independentes para gerenciá-las. As equipes também podem usar gateways de API de diferentes fornecedores ou soluções para lidar com diferentes tipos de API.

Isso leva à implantação de vários gateways de API, cada um com diferentes conjuntos de recursos.

A proliferação de gateways de API cria vários desafios adicionais:

1. Escalabilidade do gerenciamento de gateways de API: Ter vários gateways de API independentes pode dificultar seu gerenciamento e sua manutenção, especialmente à medida que aumenta o número de APIs subjacentes e clientes.
2. Ineficiências no tráfego leste-oeste: Vários gateways podem fazer com que as solicitações precisem passar por diversos gateways, aumentando a latência e reduzindo o desempenho.
3. Uniformidade das políticas de segurança: Gerenciar vários gateways pode ser difícil e resultar em políticas de segurança inconsistentes, dificultando a proteção de dados confidenciais e o controle de acesso.
4. Governança padronizada: Com vários gateways, pode ser difícil garantir que todas as APIs sejam devidamente governadas e estejam em conformidade com os padrões e as melhores práticas.
5. Aumento de custos: Ter vários gateways pode resultar em custos mais altos de infraestrutura, recursos de desenvolvimento e manutenção.
6. Desafios de integração ampliados: Ter vários gateways dificulta a integração com outros sistemas e tecnologias, como outros bancos de dados, data warehouses e ferramentas de análise de dados.

As empresas devem se empenhar em centralizar o gerenciamento e a governança de suas APIs e usar um único tipo de gateway de API. Embora isso ajude a mitigar os desafios mencionados acima decorrentes da proliferação de gateways de API, adotar uma estratégia homogênea para esses gateways está longe de ser simples.

Desafios da padronização de gateways de API em uma empresa

À medida que as empresas crescem organicamente ou por meio de aquisições, as equipes internas vinculadas a unidades de negócios (BUs) específicas podem entrar em conflito ao escolher uma tecnologia ou um fornecedor de gateway de API. Alguns dos motivos para isso incluem:

• Tecnologia: Diferentes equipes ou unidades de negócios usam stacks de tecnologia distintos ou preferem soluções de gateway de API diferentes, o que dificulta a padronização em um único tipo de gateway.
• Sistemas legados: Algumas equipes têm sistemas existentes que foram desenvolvidos usando um tipo diferente de gateway de API, e seria difícil substituir esses sistemas por um novo gateway, especialmente se ainda estiverem em uso.
• Personalização: Algumas equipes personalizam seus gateways de API existentes para atender a requisitos específicos e têm dificuldade para replicar essas personalizações em um novo gateway.
• Custo de substituição: Substituir gateways de API existentes por um gateway novo e padronizado pode ser caro, tanto em termos de desenvolvimento quanto de manutenção.
• Treinamento de desenvolvedores: As equipes têm diferentes níveis de conhecimento e talvez precisem se familiarizar com uma nova tecnologia de gateway de outro fornecedor ou receber treinamento sobre ela — um processo que pode ser demorado e caro.
• Recursos limitados: As organizações têm recursos limitados em termos de desenvolvedores, orçamento e tempo para realizar a mudança, o que dificulta a implementação de um novo gateway.
• Dependências de aplicações: Diferentes equipes ou unidades de negócios têm dependências distintas em relação aos gateways existentes, como integrações com sistemas específicos ou outras integrações personalizadas, o que dificulta a migração para um novo gateway.
• Soluções de terceiros: As equipes que usam soluções de terceiros integradas ao gateway terão dificuldade para migrar para uma nova solução que não ofereça suporte a essas soluções de terceiros.

Assim, se uma aplicação existente tiver uma equipe bem estabelecida e com opiniões firmes, ela não desejará migrar para um padrão de implantação diferente, a fim de evitar interrupções no serviço.

Podemos, portanto, concluir que é necessária uma nova abordagem que leve em consideração as diversas limitações da infraestrutura de API existente, destacando a proliferação de gateways de API como um dos aspectos mais importantes.

Considerações de design

A lista a seguir não é exaustiva, mas resume algumas das considerações de design de alto nível que acreditamos que devam ser incorporadas ao desenvolver a solução:

1. Coexistir com as implantações atuais: À medida que as organizações se esforçam para acompanhar um cenário tecnológico em constante evolução, é comum que as empresas tenham uma ampla variedade de implantações de gateways de API. Não é viável substituir de uma só vez a infraestrutura de API existente, pois isso pode interromper operações comerciais críticas. Portanto, qualquer nova implantação deve ser projetada de modo a coexistir com a arquitetura atualmente implantada.
2. Padronizar as funções do gateway de API: O principal objetivo da estratégia de APIs de uma empresa deve ser padronizar as funcionalidades de seu gateway de API, o que pode ser uma tarefa desafiadora devido à diversidade de APIs e às diferentes necessidades das unidades de negócios. Ainda assim, essa padronização é fundamental para criar uma infraestrutura estável e segura, capaz de dar suporte à transformação digital da organização.
3. Aproveite as implantações na borda: A infraestrutura de borda não só tem o potencial de aumentar exponencialmente o número de APIs, como também oferece às empresas a oportunidade de aproximar seus componentes de gateway da borda. Isso é possível porque a mesma infraestrutura usada para criar APIs também pode ser utilizada para criar componentes de gateway distribuídos. Portanto, a solução deve aproveitar ao máximo a proximidade entre a infraestrutura de borda e os clientes que iniciam a solicitação de API.
4. Independente de transporte: Uma consideração importante para a implementação da arquitetura de atores de gateway distribuídos é que ela não deve depender de nenhum mecanismo de transporte específico. Independentemente de uma empresa optar por utilizar redes IP tradicionais, redes de sobreposição, VPNs ou uma infraestrutura de mensagens de baixa latência, a solução deve ser independente do mecanismo de transporte. Isso proporciona maior flexibilidade e permite que as empresas escolham o mecanismo de transporte mais adequado às suas necessidades e aos seus requisitos específicos.
5. Suporte a GraphQL: o GraphQL está se tornando uma opção cada vez mais popular para o desenvolvimento de APIs devido às suas muitas vantagens em relação às APIs REST tradicionais. Uma das principais vantagens é a capacidade de fornecer acesso granular aos dados, permitindo que os clientes especifiquem exatamente quais dados precisam em uma única solicitação. Além disso, o GraphQL pode simplificar o processo de agregação de dados de vários serviços, tornando-se a arquitetura ideal para a composição e a orquestração de serviços. Isso pode reduzir a sobrecarga da rede e melhorar o desempenho, especialmente em um sistema distribuído no qual vários serviços de API são usados para atender a uma única solicitação. Por fim, com seu esquema fortemente tipado e sua linguagem de consulta, o GraphQL pode facilitar a descoberta de APIs e o desenvolvimento de clientes.
6. Segurança é um requisito básico: O principal objetivo do projeto é reforçar a postura de segurança de APIs da empresa. A solução pode incorporar algumas funcionalidades, como a capacidade de autenticar e autorizar solicitações de API, implementar controles de acesso e oferecer proteção contra ameaças comuns à segurança, como ataques de cross-site scripting (XSS) e injeção de SQL. Em nenhuma circunstância a nova solução deve comprometer o modelo de ameaças existente ou alterá-lo de forma tão significativa que modifique a superfície de ataque. Ao priorizar a segurança como objetivo do projeto, a arquitetura deve proporcionar um ambiente mais seguro para a comunicação entre APIs, reduzindo o risco de violações de dados e outros incidentes de segurança.

Requisitos específicos podem ser definidos com base nessas considerações de design, que incorporamos à nossa solução de atores de gateway distribuído (DGA).

Atores de Gateway Distribuído

Agora que exploramos completamente os gateways de API, podemos explicar a solução de atores de gateway distribuído.

Projeto de atores de gateway distribuídos

O padrão de projeto de atores de gateway distribuído (DGA) inspira-se na computação de borda e nos recursos computacionais disponíveis próximos ao cliente. A essência da ideia está em hiperdistribuir cada ator de gateway o mais próximo possível do cliente e fazer com que ele exista apenas durante a transação, sendo removido ao final dela.

Premissas

Veja algumas das premissas subjacentes a esta solução.

A computação de borda tornou-se mais difundida, e agora podemos encontrar algum tipo de recurso computacional geograficamente disponível mais próximo do cliente. Os atores de gateway podem ser instanciados nesses nós de computação de borda. O objetivo é ter uma implementação em que o DGA seja muito leve e efêmero, para que possa ser instanciado em qualquer recurso de computação de borda.

O transporte de API é um componente crucial da infraestrutura, pois envolve o estabelecimento de uma rede entre os atores de gateway e o gateway de API. O tipo de infraestrutura necessária depende do fornecedor ou da empresa e pode variar. Por exemplo, uma grande nuvem pública pode usar sua própria rede de backbone para executar o transporte de API. Outra implementação possível seria um barramento de mensagens de baixa latência sobre uma rede existente de alta largura de banda e baixa latência em um data center corporativo.

Funções do gateway de API

Reiterando, o gateway de API é essencialmente um proxy reverso cuja principal função é encaminhar o tráfego HTTP para as cargas de trabalho de API apropriadas. Essa abordagem faz sentido quando todas as APIs estão no mesmo local, como em uma rede local on-premises ou em uma nuvem privada virtual (VPC) dentro de uma zona de disponibilidade. No entanto, à medida que o número de APIs aumenta, elas passam a operar em uma infraestrutura híbrida ou simplesmente se tornam móveis, essa abordagem de design de gateway de API se torna ineficiente, complexa de operar e cara.

Embora possa haver diferentes opiniões sobre como classificar todos os recursos descritos na Figura 6, podemos concordar que a infraestrutura de gerenciamento de APIs se tornou uma implantação complexa de muitos componentes que precisam ser cuidadosamente orquestrados. 

Figura 7: Atores de gateway distribuído baseado em GraphQ-

A Figura 7 mapeia os diversos recursos e funções do gerenciamento de APIs apresentados na Figura 6 para a arquitetura de atores de gateway distribuído. Esse mapeamento ilustra visualmente como cada recurso e função está alinhado à abordagem DGA, destacando a integração perfeita dos componentes de gerenciamento de APIs à arquitetura.

Funções centralizadas

A maioria dos recursos listados acima possui algum componente de gerenciamento que pode ser centralizado de forma lógica. Nosso objetivo não é reprojetar o plano de gerenciamento, mas, se possível, remover determinadas funções.

Funções principais do gateway de API

Essas são funções do plano de dados e, portanto, são mais bem implementadas na API e alocadas junto às cargas de trabalho das aplicações. Os gateways de API são um componente essencial da arquitetura moderna de microsserviços, servindo como ponto de entrada para todo o tráfego externo. Classificamos suas principais funções como roteamento, balanceamento de carga, roteamento dinâmico, verificações de integridade, novas tentativas e mecanismos de contingência.

Um gateway de API direciona as solicitações recebidas ao microsserviço apropriado, distribui o tráfego entre várias instâncias, oferece suporte ao roteamento dinâmico, monitora a integridade dos microsserviços e de suas instâncias, tenta novamente as solicitações que falharam e fornece respostas alternativas quando um microsserviço está indisponível ou apresenta falha. Outras funções, como autenticação, autorização, limitação de taxa, armazenamento em cache e registro de logs, podem ser distribuídas para a borda ou centralizadas, dependendo dos requisitos específicos do sistema.

Essa abordagem modular permite uma arquitetura mais flexível e otimizada e está no cerne da nossa recomendação para simplificar, modernizar e dimensionar a infraestrutura de APIs corporativas.

Combinado

Gateway de API e gerenciamento de APIs são frequentemente confundidos pelos fornecedores, que tratam o gerenciamento de APIs como parte da função do gateway de API. No entanto, são duas funções distintas que devem ser tratadas separadamente. Um gateway de API é responsável por encaminhar solicitações dos clientes aos serviços de backend, enquanto o gerenciamento de APIs abrange um conjunto mais amplo de recursos, como controle de acesso, limitação de taxa, análises e gerenciamento do portal do desenvolvedor.

Embora alguns fornecedores possam oferecer funções de gateway de API e de gerenciamento de APIs como parte de um único produto, é importante entender as diferenças entre essas funções e avaliá-las separadamente com base em seus requisitos específicos. Combinar essas funções pode gerar confusão e potencialmente limitar a flexibilidade e a escalabilidade da infraestrutura de APIs de uma organização. Isso também é fundamental para entender nossa posição sobre a distribuição da funcionalidade de gateway de API.

Ator do Gateway – Recursos Inline

Os recursos listados aqui são funções essenciais que precisam estar integradas ao caminho dos dados. Em um padrão de gateway distribuído, algumas das funções integradas do gateway de API também se tornam distribuídas. Essas funções incluem controle de acesso, limitação de taxa, validação de solicitações, análise de APIs, relatórios de uso, monitoramento da taxa de erros, alertas e eventos, integração de autenticação, integração com terceiros, integração de monitoramento e registro de logs, cache na borda e compactação.

A migração dessas funções para o padrão de gateway distribuído oferece os seguintes benefícios:

• Redução da carga no gateway de API: Ajuda a reduzir a carga no gateway de API centralizado e a melhorar o desempenho e a escalabilidade do sistema.
• Permita tempos de resposta mais rápidos: Permita tempos de resposta mais rápidos e reduza a latência implantando essas funções mais perto dos clientes. Ao utilizar o cache dos dados e da função, os gateways de API hospedados na borda podem responder rapidamente às solicitações recebidas.

Por exemplo, o controle de acesso, a limitação de taxa e a validação de solicitações podem ser realizados por um ator de gateway de borda, implantado mais próximo dos clientes. Isso pode ajudar a reduzir o número de solicitações que precisam ser processadas pelo gateway de API centralizado, melhorando seu desempenho e sua escalabilidade. Da mesma forma, a análise de APIs, os relatórios de uso, o monitoramento da taxa de erros, os alertas e eventos e a integração com sistemas de monitoramento e registro podem ser realizados por gateways de borda, que podem coletar e agregar dados de vários microsserviços.

Atores de gateway – candidatos a GraphQL

Atualmente, um recurso importante oferecido pelos gateways de API é a composição e a orquestração de serviços. Embora isso possa se tornar bastante complexo, seria preocupante se esse recurso não fosse compatível com o gateway de API simplificado. Acreditamos que o GraphQL pode ser uma abordagem interessante para a composição de serviços, atuando como uma espécie de middleware para APIs existentes.

Por ter visibilidade de todas as APIs, o gateway de API torna-se um local natural para realizar a composição de serviços, permitindo que os desenvolvedores combinem as APIs por trás do gateway para aprimorar a lógica de negócios sem precisar criar novos serviços, que podem ser combinados com mais facilidade em uma camada de composição de serviços.

A composição de serviços no GraphQL é possível graças ao uso de um esquema fortemente tipado, que define a estrutura dos dados disponíveis para os clientes. Os clientes podem usar esse esquema para criar consultas que especifiquem exatamente os dados de que precisam, independentemente dos serviços ou das fontes que os forneçam. Os resolvers, que são funções que mapeiam consultas para fontes de dados, são usados para recuperar dados do serviço ou da fonte apropriada. No entanto, embora o GraphQL prometa maior segurança, ela depende da qualidade do código escrito pelo desenvolvedor.

Outros recursos e funções

Ainda há alguns recursos restantes não destacados na Figura 6: Recursos de gerenciamento de APIs e infraestrutura. Esses recursos e funções restantes podem ser transferidos para funções individuais de gerenciamento e operações ou do plano de dados.

Optamos deliberadamente por usar o termo “ator” para evitar sugerir uma implementação específica ou uma tecnologia de determinado fornecedor. A implementação do ator do gateway pode se basear em métodos, funções, workers, threads e processos, usando infraestruturas baseadas em VMs, contêineres, computação sem servidor ou outras abordagens específicas de um fornecedor.

Recursos e comportamento do componente

A abordagem adotada com a arquitetura de atores de gateway distribuído (DGA) simplifica as funções do gateway de API e transfere outros recursos em linha para a borda ou para o plano de controle.

Plano de controle

Além dos recursos do gateway de API, a arquitetura DGA também recomenda identificar funções que poderiam ser mais bem atendidas no plano de controle como um componente logicamente centralizado, em vez de serem implementadas em um gateway de API monolítico. O gerenciamento e o controle da infraestrutura de API existente podem ser ampliados para incluir essa funcionalidade adicional.

Gateway de API simplificado

A simplificação do gateway de API torna-se, portanto, um exercício de definição de um conjunto padrão de funções essenciais que todos os fornecedores de gateways de API possam gerenciar por meio de um conjunto comum de parâmetros de configuração.

Uma empresa que deseje realizar essa transformação pode implementar a arquitetura DGA em um aplicativo por vez, sem interferir nas implantações existentes e sem a necessidade de uma migração completa de uma só vez.

Atores de Gateway Distribuído

Um aspecto importante da DGA é que cada ator de gateway é efêmero, sendo instanciado apenas durante uma sessão de API (ou seja, enquanto um cliente faz uma chamada à API). 

Um ator de gateway distribuído pode ser mais flexível, escalável e econômico do que um gateway de API tradicional. Em vez de depender de vários gateways de API monolíticos de diferentes fornecedores para agregar e processar o tráfego de APIs, o ator de gateway permite que os desenvolvedores especifiquem e implantem instâncias individuais de gateway para cada API mais próximas da borda da rede. As próprias APIs podem oferecer maior controle e personalização para atender às suas necessidades específicas.

Essa nova abordagem também oferece maior escalabilidade, pois os desenvolvedores podem facilmente criar instâncias do ator de gateway conforme necessário para lidar com o aumento do tráfego, sem se preocupar com a sobrecarga de gerenciar um gateway grande e centralizado.

Além dos benefícios técnicos, o ator de gateway também proporciona economia de custos em comparação com o gateway de API tradicional, permitindo que as empresas paguem apenas pelas instâncias efêmeras do ator de gateway que utilizarem. Esse modelo de implantação pode abrir oportunidades para novas fontes de receita.

Posicionamento do ator de gateway

Ao utilizar uma camada de transporte de API, os DGAs basicamente desacoplam o local de entrada da API do gateway de API. Os DGAs podem ser movidos para a borda, ou seja, para mais perto do cliente que faz a chamada à API. As APIs podem ser encerradas nos DGAs e, em seguida, transportadas por qualquer meio. Isso difere da Figura 3: Arquiteturas legadas de gateway de API em que o tráfego do cliente entra em um ponto topologicamente adjacente aos gateways de API. 

Conclusão

Nossa intenção, portanto, foi propor uma abordagem independente de fornecedor e de modelo de implantação, uma vez que diferentes fornecedores podem ter sua própria propriedade intelectual para desenvolver esses componentes e alcançar objetivos semelhantes aos descritos.

Neste artigo, resumimos os aprendizados obtidos ao longo de vários trimestres de pesquisa sobre a proliferação de APIs, as arquiteturas Edge 2.0, a economia de APIs (https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy) e as investigações sobre GraphQL. Embora ainda não haja uma conclusão definitiva em relação à infraestrutura de APIs legada, acreditamos que seja necessária uma nova abordagem.

A simples promessa de liberar o valor de cada dispositivo ou entidade individual em todo o mundo já é motivo suficiente para explorar uma nova abordagem. Precisamos abandonar a atual infraestrutura legada de APIs, pois, embora pareça distribuída, ela é monolítica nos bastidores.

Propomos a abordagem de atores de gateway distribuídos baseados em GraphQL como uma forma independente de fornecedor para liberar todo o potencial da emergente economia de APIs.