Atores de Gateway Distribuído: Evolução do gerenciamento de API
Índice
F5 Gabinete do CTO Opinião
A equipe do Escritório do CTO da F5 vem explorando o campo de tecnologia relacionado a APIs há mais de um ano. Este último white paper é uma continuação de nossos esforços para entender o ecossistema de API em constante evolução.
Os desafios que detalhamos com o gerenciamento da proliferação de APIs levarão a desafios com a proliferação de gateways de API, e as abordagens tradicionais para lidar com esses desafios não serão suficientes. Embora tecnologias gráficas como GraphQL sejam muito promissoras no que diz respeito à redução da complexidade associada às APIs, elas são apenas parte da solução, pois os desafios vão além da conectividade, segurança e roteamento. A abordagem correta, baseada em quase trinta anos de experiência com sistemas e aplicativos de dimensionamento, é baseada em uma arquitetura distribuída — não federada — que emprega GraphQL, mas não depende exclusivamente dele.
Este artigo explora uma abordagem arquitetônica distribuída para enfrentar os desafios da proliferação de gateways de API.
Resumo
A economia digital será alimentada por APIs, o que nos dará uma economia orientada por APIs . Após o white paper sobre a proliferação de APIs , nossa busca foi entender como eliminar ou aliviar o impacto da proliferação de APIs. Embora o GraphQL pareça promissor para reduzir as ramificações da proliferação de APIs, ele tende a colocar sobre os desenvolvedores o ônus de reescrever grande parte de sua base de código de API. No entanto, um ponto de vista emergente sobre o GraphQL é sua capacidade de ser usado como um agente de gateway eficaz. O ator de gateway é uma função ou processo criado próximo ao cliente que inicia uma solicitação de API. Este ator de gateway atua como o gateway de API inicial, encerrando a solicitação de API. Ele também pode ser efêmero, de modo que pode ser destruído após o atendimento da solicitação.
Além de desenvolvedores e equipes de operações priorizarem o gerenciamento de API em vez de gateways de API, também descobrimos o problema da proliferação de gateways de API devido à proliferação de API. Da perspectiva 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 hoje são um componente crítico da infraestrutura de API, 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 API precisa evoluir para aceitar a proliferação de API e, ao mesmo tempo, simplificar a implantação e as operações. A arquitetura proposta é a próxima evolução de onde os padrões de design de gateway de API precisam estar. Embora o GraphQL não seja essencial para a arquitetura, nem uma necessidade, ele tem a capacidade de aprimorar o padrão de ator do gateway.
Resumo
O ecossistema de gerenciamento de API deve deixar de gerenciar monolitos de gateway de API e adotar uma abordagem de design de sistema mais contemporânea. Isso resultará em um ecossistema de gerenciamento de API mais ágil e eficaz.
API Gateway Sprawl – 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 APIs , uma situação em que o gerenciamento de APIs se tornou incontrolável devido às diversas tecnologias de fornecedores de gateways de API e às equipes opinativas que gerenciam os gateways de API. 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 — não é mais suficiente para gerenciar a escala e a complexidade do ecossistema de API emergente.
A Figura 1 ilustra como passamos do gerenciamento da proliferação de APIs para o gerenciamento da proliferação de gateways de APIs.
O padrão de design acima faz alusão 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, fornecendo um ponto central de controle e segurança para APIs. No entanto, à medida que o número de recursos oferecidos pelos gateways de API cresceu, 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 gama de funcionalidades reunidas em um único pacote.
Embora o gerenciamento de múltiplos gateways possa parecer um projeto distribuído, a realidade é que ele fica aquém da distribuição verdadeira. Isso ocorre porque os gateways ainda estão fortemente acoplados, compartilhando recursos e configurações que são difíceis de separar. Como resultado, muitas empresas acabam gerenciando monólitos distribuídos e todos os desafios que isso cria.
Arquiteturas de gateway de API legadas
A Figura 3 mostra a arquitetura dos gateways de API existentes. As solicitações de API originadas do cliente são primeiramente transmitidas por uma rede compartilhada ou dedicada, passando por um firewall antes de chegar ao gateway de API. O gateway da API, que atua como um proxy reverso, encaminha o tráfego para a carga de trabalho da API.
O API-GW legado se torna um ponto de estrangulamento no gerenciamento de API quando os gateways de API são implantados em toda a empresa ou quando as cargas de trabalho de API se movem operacionalmente entre regiões, zonas, várias nuvens ou para a borda, ao mesmo tempo em que enfrentam a proliferação de API. Vários API-GWs são criados por diferentes equipes sem um único ponto de gerenciamento e controle empresarial. Se um indivíduo ou grupo de serviços de API migrar para uma infraestrutura diferente (nuvem ou outra), a equipe de operações deve ter um método para migrar todos os aspectos do gerenciamento de API: registro, descoberta, autenticação, rede, segurança e políticas de governança, risco e conformidade (GRC).
A arquitetura representada na Figura 3 não é, portanto, escalável nem prática a longo prazo, pois, com o tempo, leva ao gerenciamento de monólitos distribuídos (Figura 2).
Há dois problemas ao criar o ponto de estrangulamento do gateway da API: (1) proliferação de fornecedores de gateway de API e (2) escala conforme o uso quando uma empresa tem mais aplicativos em execução em mais lugares.
- Proliferação de fornecedores de gateway de API : Lidar com a proliferação de fornecedores de gateway 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 complicada. Como resultado, as organizações acabam gastando tempo e recursos gerenciando vários fornecedores de gateway. Embora esse problema possa ser resolvido, ele pode não ser totalmente viável na realidade.
- Dimensionamento de aplicação: O dimensionamento de aplicativos é um problema quando o aplicativo precisa oferecer suporte a mais usuários em um único local ou precisa ser implantado em vários locais. Isso requer que o aplicativo seja dimensionado horizontal ou verticalmente. No entanto, à medida que o aplicativo é dimensionado, os gateways de API também precisam ser dimensionados e, em alguns casos, precisam ser implantados em vários locais para dar suporte ao dimensionamento com base nos padrões de arquitetura atuais. Isso pode tornar o gerenciamento dos gateways de API operacionalmente complexo.
Solução: Um Padrão de Ator de Gateway Distribuído
A Figura 4 descreve 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 dentro do contexto de gateways de API. Os clientes iniciam a solicitação da API. Os atores de gateway distribuídos são efêmeros e instanciados sob demanda, o mais próximo possível do cliente. Torna-se responsabilidade da camada de transporte da API enviar a solicitação da API do ator do gateway para o gateway da API simplificado, que então encaminha a solicitação para a carga de trabalho da API apropriada. Embora o uso do suporte GraphQL nos atores distribuídos seja mais um detalhe do que um requisito para que esse padrão funcione, ele permite recursos de suporte como orquestração de serviços. Então, em vez de criar uma nova camada de orquestração de serviços, o GraphQL poderia fornecer esse suporte.
Para esclarecer, o padrão de tráfego é da direita para a esquerda. Ou seja, os clientes ficam à direita e as requisições de API são iniciadas pelo cliente, conforme mostrado na Figura 5.
Há um padrão de implantação emergente usando agentes de gateway para substituir ou reduzir a dependência excessiva de gateways de API para gerenciar APIs dentro e entre uma empresa. Embora o GraphQL não seja necessário para a arquitetura, sua introdução é oportuna, pois o ator de gateway é o veículo certo para dar suporte ao GraphQL.
Para obter uma compreensão mais profunda do gateway como uma solução potencial, é necessário examinar de perto o estado atual das infraestruturas de API, particularmente os gateways de API. Isso ocorre porque identificamos a proliferação de gateways como um fator significativo que contribui para os desafios de operação e dimensionamento de infraestruturas de API.
Para entender melhor os gateways de API, é importante primeiro examinar os vários componentes da infraestrutura moderna de gerenciamento de API.
A Figura 6 oferece uma representação visual abrangente dos vários recursos e componentes que são essenciais para o gerenciamento de API. Além dos gateways de API, que são necessários para roteamento e gerenciamento de tráfego para serviços de backend, há vários outros componentes de infraestrutura importantes. Isso pode incluir soluções para autenticação, limitação de taxa, cache e malha de serviço, entre outros. Ao incorporar esses recursos, as organizações podem obter controle sobre suas APIs, aumentar a segurança e otimizar o desempenho.
Vamos examinar os recursos comumente reconhecidos e familiares dos gateways de API:
- Roteamento : Encaminha solicitações para o serviço de backend apropriado com base no caminho ou conteúdo da solicitação.
- Autenticação e autorização : Autentica e autoriza solicitações como um único ponto de entrada, garantindo que somente clientes autorizados possam acessar os serviços de backend.
- Limitação de taxa : Limita a taxa na qual os clientes podem fazer solicitações às APIs subjacentes, evitando o uso excessivo e protegendo os serviços de backend contra sobrecarga.
- Armazenamento em cache : Armazena em cache as respostas das APIs subjacentes, reduzindo o número de solicitações necessárias aos serviços de backend e melhorando o desempenho.
- Tradução do protocolo : Traduz entre diferentes protocolos, como HTTP e WebSockets, permitindo que clientes acessem as APIs subjacentes usando diferentes protocolos.
- Balanceamento de carga : Distribui solicitações para vários serviços de backend, melhorando a escalabilidade e a confiabilidade.
- Segurança: Lida com tarefas de segurança, como criptografia e descriptografia, para garantir que os dados sejam transmitidos com segurança.
- Análise e monitoramento: Rastreia e relata métricas de uso e informações de erros, fornecendo visibilidade sobre como o sistema está sendo usado e ajudando a identificar gargalos de desempenho e erros.
- Controle de versão : Lida com o controle de versão das APIs subjacentes, permitindo que os clientes acessem diferentes versões da API, dependendo de suas necessidades.
- Descoberta de serviço : Descobre serviços de backend disponíveis e encaminha solicitações dinamicamente para eles, permitindo uma descoberta de serviços mais dinâmica e flexível.
Após analisar os recursos de infraestrutura de gerenciamento de API, identificamos a necessidade de entender melhor a função dos gateways de API e explorar alternativas ao atual design de gateway de API monolítico.
Com o crescimento no número de APIs já levando à proliferação de APIs e de gateways de API, um número crescente de clientes está se tornando móvel ou altamente distribuído, e a infraestrutura de computação se tornou disponível em todos os lugares, inclusive na borda. Precisamos, portanto, de uma abordagem que possa melhorar a agilidade, flexibilidade, escalabilidade, desempenho e segurança do ecossistema de API.
Essa nova abordagem requer um design simplificado, capaz de aproveitar totalmente os benefícios de uma arquitetura verdadeiramente distribuída.
Analisamos ainda mais a funcionalidade e o escopo de um gateway de API para descobrir suas nuances e limitações.
Um gateway de API é um componente crítico da infraestrutura de gerenciamento de API atual. Em essência, o gateway de API é um proxy reverso; ele atua como um intermediário entre clientes e serviços de backend enquanto executa uma variedade de tarefas na solicitação recebida. Por exemplo, o gateway pode autenticar, limitar taxas, solicitar rotas, aplicar políticas de segurança, monitorar e aplicar controle de versão antes de encaminhar a solicitação para 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 protocolo e tratamento de resposta antes de encaminhar a resposta de volta ao cliente.
À medida que o número de APIs cresceu, os gateways de API evoluíram para incluir uma variedade de novas funcionalidades além do roteamento básico, tornando-se efetivamente 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 aprimorada, os gateways de API continuam sendo um único ponto de acesso ao serviço de backend, o que pode apresentar desafios em ambientes altamente distribuídos.
Em particular, o surgimento de infraestruturas de nuvem, multinuvem híbrida e de ponta tornou mais difícil manter a agilidade, a segurança e a capacidade de gerenciamento com uma abordagem de gateway de API. Com clientes, dispositivos e cargas de trabalho de aplicativos potencialmente espalhados por uma ampla variedade de locais, um gateway de API pode não ser adequado para fornecer o nível necessário de arquitetura amigável à borda.
Como eles lidam com uma ampla gama de tarefas e precisam ser integrados a vários sistemas, os gateways de API geralmente são difíceis de implantar e gerenciar. Embora gerenciar gateways de API possa ser complexo, é, no entanto, uma tarefa crítica para garantir a disponibilidade, segurança e escalabilidade de uma API. As empresas tendem a usar ferramentas especializadas, como plataformas de gerenciamento de API, para ajudar a gerenciar e monitorar seus gateways de API de forma mais eficaz.
A lista abaixo não é abrangente, mas alguns dos elementos que contribuem para a complexidade do gateway de API incluem:
- Gerenciamento de configuração : Os gateways de API geralmente têm uma ampla gama de opções de configuração e definições 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 o número de APIs e clientes subjacentes aumenta.
- Integração com outros sistemas : Os gateways precisam se integrar a uma ampla gama 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. Isso se torna mais problemático quando uma empresa tem várias implantações de gateway de API de vários fornecedores.
- Escalabilidade e disponibilidade : Os gateways de API precisam ser capazes de lidar com um grande número de solicitações e garantir alta disponibilidade, o que pode ser complexo de gerenciar, especialmente ao lidar com um grande número de serviços de back-end e clientes.
- Segurança : Sendo um componente crítico de segurança de API, os gateways de API de segurança devem ser configurados e gerenciados para garantir que dados confidenciais sejam protegidos e o acesso seja controlado. Isso pode ser complexo e requer monitoramento e gerenciamento contínuos.
- Controle de versão : À medida que o número de APIs e clientes subjacentes 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.
- Monitoramento e solução de problemas : Os gateways de API podem coletar e gerar grandes quantidades de dados. Em uma grande empresa, os gateways podem ser distribuídos em muitos locais, dificultando a correlação de eventos que afetam a integridade geral do aplicativo e a solução de problemas.
Expansão do Gateway de API
A proliferação de gateways de API se refere à proliferação de vários gateways de API independentes dentro de uma organização. Diferentes equipes ou unidades de negócios geralmente criam suas próprias APIs, o que pode levar à criação de vários gateways de API independentes para lidar com essas diferentes APIs. Diferentes equipes também podem usar gateways de API de diferentes fornecedores ou soluções para lidar com diferentes tipos de APIs.
Isso leva à implantação de vários gateways de API, todos com conjuntos variados de recursos.
A proliferação de gateways de API cria vários desafios adicionais:
- Escalonamento do gerenciamento de gateway de API : Ter vários gateways de API independentes pode dificultar o gerenciamento e a manutenção dos gateways, especialmente à medida que o número de APIs e clientes subjacentes aumenta.
- Ineficiências no tráfego leste-oeste : Vários gateways podem fazer com que solicitações precisem passar por eles, aumentando a latência e reduzindo o desempenho.
- Uniformidade das políticas de segurança : Gerenciar vários gateways pode ser difícil e pode levar a políticas de segurança inconsistentes, dificultando a garantia de que dados confidenciais sejam protegidos e que o acesso seja controlado.
- Governança padronizada : Com vários gateways, pode ser difícil garantir que todas as APIs sejam governadas adequadamente e estejam em conformidade com os padrões e práticas recomendadas.
- Aumento de custo : Ter vários gateways pode levar a custos mais altos de infraestrutura, recursos de desenvolvimento e manutenção.
- Desafios de integração amplificados : 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 esforçar para centralizar o gerenciamento e a governança de API e usar um único tipo de gateway de API. Embora isso alivie os desafios acima da proliferação de gateways de API, uma estratégia homogênea para gateways de API não é nada simples.
Desafios na padronização de API Gateways em uma empresa
À medida que as empresas crescem organicamente ou por meio de aquisições, as equipes internas alinhadas a unidades de negócios (BUs) específicas entrarão em conflito entre si ao selecionar uma tecnologia ou fornecedor de gateway de API. Algumas razões para isso incluem o seguinte:
- Tecnologia : Diferentes equipes ou unidades de negócios têm diferentes pilhas de tecnologia ou preferem diferentes soluções de gateway de API, dificultando a padronização em um único tipo de gateway.
- Sistemas legados : Algumas equipes têm sistemas existentes que foram criados usando um tipo diferente de gateway de API, e seria difícil substituir esses sistemas por um novo gateway, especialmente se eles ainda estiverem em uso.
- Personalização : Algumas equipes personalizarão seus gateways de API existentes para atender a requisitos específicos e acharão difícil replicar essas personalizações em um novo gateway.
- Custo de substituição : Substituir gateways de API existentes por um novo gateway padronizado pode ser caro, tanto em termos de desenvolvimento quanto de manutenção.
- Treinamento de desenvolvedores : As equipes variam em seus níveis de especialização e podem precisar se familiarizar ou passar por treinamento em uma nova tecnologia de gateway de um fornecedor diferente, 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 fazer a mudança, dificultando a implementação de um novo gateway.
- Dependências do aplicativo : Diferentes equipes ou unidades de negócios têm diferentes dependências em seus gateways existentes, como integração com sistemas específicos ou outras integrações personalizadas, dificultando a mudança para um novo.
- Soluções de terceiros : As equipes que usam soluções de terceiros que se integram ao gateway terão dificuldade em migrar para uma nova solução que não ofereça suporte a essas soluções de terceiros.
Portanto, se um aplicativo existente tiver uma equipe bem estabelecida e opinativa, a equipe não desejará migrar para um padrão de implantação diferente para não causar interrupção em seu serviço.
Podemos concluir, portanto, que há necessidade de uma nova abordagem que leve em consideração as múltiplas limitações da infraestrutura de API existente, ao mesmo tempo em que destaca a proliferação de gateways de API como uma das considerações mais importantes.
Considerações sobre o projeto
A lista a seguir não é exaustiva, mas resume algumas das considerações de design de alto nível que acreditamos que devem ser incorporadas ao criar a solução:
- Coexistir com as implantações atuais : À medida que as organizações se esforçam para acompanhar o cenário tecnológico em constante mudança, é comum que as empresas tenham uma gama diversificada de implantações de gateway de API. Não é viável transferir a infraestrutura de API existente, pois isso pode interromper operações comerciais críticas. Portanto, qualquer nova implantação deve ser projetada de forma que possa coexistir com a arquitetura implantada atualmente.
- Padronizar funções de gateway de API : O objetivo principal da estratégia de API de uma empresa deve ser padronizar a funcionalidade do gateway de API, o que pode ser uma tarefa desafiadora devido à diversidade de APIs e às diferentes necessidades de diferentes unidades de negócios. No entanto, essa padronização é crucial para criar uma infraestrutura estável e segura que possa dar suporte à transformação digital da organização.
- Aproveite as implantações de ponta : A infraestrutura de ponta não só tem o potencial de aumentar exponencialmente o número de APIs, mas também oferece uma oportunidade para as empresas moverem seus participantes de gateway para mais perto da ponta. Isso é possível porque a mesma infraestrutura usada para criar APIs também pode ser utilizada para criar atores de gateway distribuídos. Portanto, a solução deve aproveitar totalmente a proximidade da infraestrutura de ponta aos clientes que iniciam a solicitação de API.
- Agnóstico em relação ao 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 querer utilizar redes IP tradicionais, redes de sobreposição, VPNs ou infraestrutura de mensagens de baixa latência, a solução deve ser independente do mecanismo de transporte. Isso permite maior flexibilidade e permite que as empresas escolham o mecanismo de transporte que melhor se adapta às suas necessidades e requisitos específicos.
- Suporte GraphQL : O GraphQL está se tornando uma escolha cada vez mais popular para desenvolvimento de APIs devido às suas muitas vantagens em relação às APIs REST tradicionais. Uma vantagem importante é sua capacidade de fornecer acesso detalhado 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 certa para componibilidade e orquestração de serviços. Isso pode reduzir a sobrecarga da rede e melhorar o desempenho, especialmente em um sistema distribuído onde vários serviços de API são usados para atender a uma única solicitação. Por fim, com seu esquema fortemente tipado e linguagem de consulta, o GraphQL pode melhorar a capacidade de descoberta da API e facilitar o desenvolvimento do cliente.
- A segurança é a aposta básica : O principal objetivo do design é que ele seja um complemento à postura de segurança da API da empresa. A solução poderia incorporar algumas das funcionalidades, como a capacidade de autenticar e autorizar solicitações de API, implementar controles de acesso e proteger contra ameaças comuns de segurança, como ataques de script entre sites (XSS) e injeção de SQL. Sob nenhuma circunstância a nova solução deve comprometer o modelo de ameaça existente ou alterá-lo de forma tão significativa que a superfície de ataque mude. Ao priorizar a segurança como uma meta de design, a arquitetura deve fornecer um ambiente mais seguro para comunicação de API, reduzindo o risco de violações de dados e outros incidentes de segurança.
Requisitos específicos podem ser derivados com base nessas considerações de design, que incorporamos em nossa solução de atores de gateway distribuídos (DGA).
Atores de Gateway Distribuídos
Agora que exploramos completamente os gateways de API, podemos explicar a solução do ator de gateway distribuído.
Design de Atores de Gateway Distribuídos
O padrão de design de atores de gateway distribuídos (DGA) se inspira na computação de ponta e na computação disponível perto de um cliente. O ponto crucial da ideia está na hiperdistribuição de cada ator de gateway o mais próximo possível do cliente e em fazer com que o ator de gateway exista apenas durante a transação antes de ser compensado no final.
Suposições
Aqui estão algumas das suposições subjacentes a esta solução.
A computação de ponta se tornou mais difundida e agora podemos encontrar algum tipo de computação que esteja geograficamente disponível mais perto do cliente. Os atores do gateway podem ser instanciados nesses nós de computação de ponta. A intenção é ter uma implementação em que o DGA seja muito leve e efêmero para que possa ser instanciado em qualquer computação de ponta.
O transporte de API é um componente crucial da infraestrutura, pois envolve o estabelecimento de uma rede entre os atores do gateway e o gateway da 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 seu próprio backbone para executar o transporte de API. Outra implementação poderia ser um barramento de mensagens de baixa latência sobreposto a uma rede existente de alta largura de banda e baixa latência dentro de um data center empresarial.
Funções do API Gateway
Para reiterar, o gateway de API é essencialmente um proxy reverso cuja função principal é rotear o tráfego HTTP para as cargas de trabalho de API apropriadas. Essa abordagem faz sentido onde todas as APIs são colocadas juntas, como em uma rede local no local ou em uma nuvem privada virtual (VPC) dentro de uma zona de disponibilidade. Mas, à medida que o número de APIs aumenta, se move por uma infraestrutura híbrida ou simplesmente se torna móvel, essa abordagem de design de gateway de API se torna ineficiente, complexa de operar e cara.
Embora possa haver diferentes visões sobre como classificar todos os recursos descritos na Figura 6, podemos concordar que a infraestrutura de gerenciamento de API se tornou uma implantação complexa de muitos componentes que precisam ser cuidadosamente orquestrados.
A Figura 7 mapeia os vários recursos e funções do gerenciamento de API da Figura 6 para a arquitetura de atores de gateway distribuídos. Este mapeamento ilustra visualmente como cada recurso e função está alinhado com a abordagem DGA, destacando a integração perfeita dos componentes de gerenciamento de API dentro da arquitetura.
Funções Centralizadas
A maioria dos recursos listados acima tem algum componente de gerenciamento que pode ser centralizado logicamente. Nosso objetivo não é reestruturar o plano de gerenciamento, mas, se possível, remover certas funções.
Funções principais do API Gateway
Essas são funções do plano de dados e, portanto, melhor implementadas na API e colocadas junto com cargas de trabalho do aplicativo. Os gateways de API são um componente crucial da arquitetura moderna de microsserviços que serve como ponto de entrada para todo o tráfego externo. Categorizamos suas principais funções para incluir roteamento, balanceamento de carga, roteamento dinâmico, verificação de integridade, novas tentativas e fallbacks.
Um gateway de API direciona solicitações recebidas para o 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 suas instâncias, repete solicitações com falha e fornece respostas de fallback quando um microsserviço não está disponível ou falhou. Outras funções, como autenticação, autorização, limitação de taxa, armazenamento em cache e registro, podem ser distribuídas para funções de ponta ou centralizadas, dependendo dos requisitos específicos do sistema.
Essa abordagem modular permite uma arquitetura mais flexível e otimizada e está no centro de nossa recomendação para simplificar, modernizar e dimensionar a infraestrutura de API corporativa.
Confundido
O gateway de API e o gerenciamento de API são frequentemente confundidos erroneamente pelos fornecedores como parte da função do gateway de API, mas, na verdade, são duas funções distintas que devem ser tratadas separadamente. Um gateway de API é responsável por rotear solicitações de clientes para serviços de backend, enquanto o gerenciamento de API abrange um conjunto mais amplo de recursos, como controle de acesso, limitação de taxa, análise e gerenciamento de portal do desenvolvedor.
Embora alguns fornecedores possam oferecer funções de gateway de API e gerenciamento de API 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. A combinação dessas funções pode causar confusão e potencialmente limitar a flexibilidade e a escalabilidade da infraestrutura de API de uma organização. Isso também é fundamental para entender nossa posição sobre a distribuição da funcionalidade do gateway de API.
Gateway Actor – Recursos em linha
Os recursos listados aqui são funções principais que precisam estar alinhadas ao caminho de dados. Em um padrão de gateway distribuído, algumas das funções inline 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ção, análise de API, relatórios de uso, monitoramento de taxa de erro, alertas e eventos, integração de autenticação, integração de terceiros, monitoramento e integração de registro, cache de borda e compactação.
Mover essas funções para o padrão de gateway distribuído tem os seguintes benefícios:
- Carga reduzida no gateway da API : Ajude a reduzir a carga no gateway de API centralizado e melhore o desempenho e a escalabilidade do sistema.
- Permita tempos de resposta mais rápidos : Permita tempos de resposta mais rápidos e latência reduzida implantando essas funções mais perto dos clientes. Ao aproveitar 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 gerenciados por um agente de gateway de ponta, que é implantado mais próximo dos clientes. Isso pode ajudar a reduzir o número de solicitações que precisam ser tratadas pelo gateway de API centralizado, melhorando seu desempenho e escalabilidade. Da mesma forma, análises de API, relatórios de uso, monitoramento de taxa de erros, alertas e eventos, e integração de monitoramento e registro podem ser gerenciados por gateways de ponta, que podem coletar e agregar dados de vários microsserviços.
Atores de Gateway – Candidatos GraphQL
Hoje, um recurso importante que os gateways de API oferecem suporte é a composição e orquestração de serviços. Embora isso possa ser bastante complexo, seria uma preocupação se esse recurso não fosse suportado pelo gateway de API simplificado. Acreditamos que o GraphQL pode ser uma abordagem interessante para composição de serviços, atuando como uma espécie de middleware para APIs existentes.
Devido à visibilidade de todas as APIs, o gateway de API se torna um local lógico para executar 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 escrever novos serviços que podem ser combinados mais facilmente em uma camada de composição de serviços.
A composição de serviços no GraphQL é possível por meio do uso de um esquema fortemente tipado, que define o formato dos dados disponíveis aos clientes. Os clientes podem usar esse esquema para construir consultas que especifiquem os dados exatos de que precisam, independentemente de quais serviços ou fontes os fornecem. Resolvedores, que são funções que mapeiam consultas para fontes de dados, são usados para recuperar dados do serviço ou fonte apropriados. No entanto, embora o GraphQL prometa melhor segurança, sua qualidade depende do desenvolvedor que escreve o código.
Outros recursos e funções
Ainda há algumas características restantes não destacadas na Figura 6: Recursos de infraestrutura e gerenciamento de API . Esses recursos e funções restantes são candidatos que podem ser movidos para funções individuais de gerenciamento e operações ou de plano de dados.
Escolhemos deliberadamente usar o termo “ator” para evitar sugerir uma implementação específica ou tecnologia de fornecedor. A implementação do ator do gateway pode ser baseada em métodos, funções, trabalhadores, threads e processos, implementados usando infraestruturas baseadas em VMs, contêineres, serverless ou outras abordagens específicas de um fornecedor.
Características e comportamento do componente
A abordagem adotada com a arquitetura de atores de gateway distribuídos (DGA) simplifica as funções do gateway de API e move 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 melhor atendidas no plano de controle como um componente logicamente centralizado em vez de implementadas em um gateway de API monolítico. O gerenciamento e o controle da infraestrutura de API já existente podem ser estendidos e expandidos para incluir esta funcionalidade adicional.
Gateway de API simplificado
A simplificação do gateway de API torna-se, portanto, um exercício para derivar um conjunto padrão de funções principais que todos os fornecedores de gateway de API podem gerenciar por meio de um conjunto comum de parâmetros de configuração.
Uma empresa que quisesse fazer essa transformação poderia implementar a arquitetura DGA um aplicativo por vez, sem interromper as implantações existentes e sem a necessidade de uma operação empilhadeira.
Atores de Gateway Distribuídos
Um aspecto importante do DGA é que cada ator de gateway é efêmero, sendo instanciado apenas durante uma sessão de API (ou seja, um cliente fazendo uma chamada de API).
Um agente de gateway distribuído pode ser mais flexível, escalável e econômico do que o gateway de API tradicional. Em vez de depender de vários gateways de API monolíticos de diferentes fornecedores para agregar e manipular o tráfego de API, o gateway player permite que os desenvolvedores especifiquem e implantem instâncias de gateway individuais para cada API mais próxima da borda da rede. As próprias APIs podem fornecer maior controle e personalização para suas necessidades específicas.
Essa nova abordagem também permite maior escalabilidade, pois os desenvolvedores podem facilmente ativar as instâncias do ator de gateway conforme necessário para lidar com o aumento de tráfego sem se preocupar com a sobrecarga de gerenciar um gateway grande e centralizado.
Além dos benefícios técnicos, o gateway actor também oferece economia de custos em relação ao gateway de API tradicional, permitindo que as empresas paguem apenas pelas instâncias efêmeras do gateway actor que usam. Este modelo de implantação pode abrir oportunidades para modelos de receita adicionais.
Posicionamento do Ator Gateway
Ao aproveitar uma camada de transporte de API, os DGAs essencialmente desacoplaram o local de entrada da API do gateway da API. Os DGAs podem ser movidos para a borda, ou seja, mais perto do cliente que faz a chamada de API. As APIs podem terminar nos DGAs e então ser transportadas por qualquer meio. Isso é diferente da Figura 3: Arquiteturas de gateway de API legadas nas quais o tráfego do cliente ingressa topologicamente adjacente aos gateways de API.
Conclusão
Nossa intenção, portanto, foi propor uma abordagem independente de fornecedor e implantação, já que diferentes fornecedores podem ter sua própria propriedade intelectual para criar esses componentes para atingir objetivos semelhantes aos descritos.
Neste artigo, resumimos nossos aprendizados de vários trimestres pesquisando a proliferação de APIs , arquiteturas Edge 2.0 , a economia de APIs e investigações sobre GraphQL. Embora o júri ainda não tenha se pronunciado sobre a infraestrutura de API legada, acreditamos que há necessidade de uma nova abordagem.
Só a promessa de desbloquear valor em cada dispositivo ou entidade individual globalmente já fornece um motivo forte o suficiente para explorar uma nova abordagem. Precisamos nos afastar da infraestrutura de API legada hoje, porque, embora pareça distribuída, ela é monolítica por dentro.
Propomos a abordagem de ator de gateway distribuído baseado em GraphQL como uma maneira independente de fornecedor para desbloquear todo o potencial da economia de API emergente.